I have 2 images on top of each other.
When the top one moves to a different spot, both of them become kind of distorted/blurry. After a second, the images return to normal.
How do I stop this from happening?
http://jsfiddle.net/jenga/W59c4/
The image has an actual size of 140 x 198. You are shrinking and expanding it to a different size. Because of the way raster images work, this causes blurriness and/or distortion. Use a bigger source image, higher DPI, or don't expand it beyond the base size of your source image.
Otherwise, the perceived "smoothness" of any javascript animation is very dependent on the client computer's resources. If your browser thread is running high on memory (Firefox+Firebug can balloon up to 1gb of resident RAM consumption after a few hours of work!), or if your system doesn't have a lot of available resource to start with, animations can be jerky and screen rendering can be slow or glitchy.
Other than the distortion caused by the scaling, your animation runs smoothly on my own computer (I have a lot of resources to work with :P)
Documentation
Raster Graphics on Wikipedia - http://en.wikipedia.org/wiki/Raster_graphics
Resize the black card down to the desired dimensions. You're working with an original that's 600px wide and shrinking it to 75px wide; that's the cause of the distortion.
My guess would be that the browser doesn't anti-alias the black card because it's not in view. During the animation the browser is rapidly updating position and scale of the blue card. As a performance measure, anti-aliasing might be put off until there's room for the browser to breath beyond what the tight setTimeout looping provides.
Related
I was having a hard time figuring out how to phrase this. Sorry if this is a noob question, I'm new to responsive design and mobile web design in general.
My phone (Galaxy s10e) will render my webpage as if it's 360 pixels wide, with all elements positioned appropriately based on this width. I have several image tags on the site that are the same width. I was using src images that are 360px wide, and this looks fine on desktop because it is actually rendering my images at 360px, but on mobile the images alone appear to be rendering at a much higher resolution, causing it to look terrible due to upscaling.
If someone could explain to me what is happening here it would really help, since I can't find information on this specific behavior. Some questions I have:
Is the browser choosing to position the elements based on a 360px width while rendering the actual content at the screen's resolution?
How do I account for this in my design? I considered rendering the images at the higher resolution and then having the page dynamically scale those images down (so even though the actual div is 360px, the browser can use the 'extra space' allotted by max-width to render the image at a higher resolution), but I want the images to remain 360px wide on desktop, not the higher max-width for mobile rendering.
Where can I learn all about this behavior so I know how to tackle responsive image scaling in the future?
Thank you for your time. Let me know if you have any other questions. I'm using ReactJS to develop the site.
OK so in a nutshell pixels are relative sizes. One pixel is not literally one pixel on your phone.
What happens is PPI kicks in and basically zooms in to make things readable.
Because if you actually tried to view 360px on a phone with that pixel density you'd see nothing really.
So lets look at some phone specs:
6.1 INCH
5.90 x 2.77 x 0.31 INCH
Resolution 1440 x 3040 PX ~ 550 PIXELS PER INCH
Viewport 360 x 760 PX 138 PIXELS PER INCH
Now the viewport is what you actually see on screen. in this case it give you a pixel ratio of like 4. So that means your phone has a resolution 4 times that of it's viewport.
so for a web app where a div is set to 200px wide it will display 200px as you'd expect it based on the viewport but this div is actually 800px wide relative to your phones resolution.
Now pictures don't need this limitation. Whats the point in a high res display if your pictures only display 200px with a pixel density one fourth of your screens capability.
So a picture lives in a dual reality on your phone. It has a box size which is the size of the image relative to your viewport but the image itself inside the box lives within your resolution relative to your devices total screen pixels.
So when you have and image that's 200px in the viewport its display resolution is actually 800px. So when you put a picture that's only 200px and have it on a screen that does viewport scaling which nowadays is pretty much everything you're effectively stretching that image to four times its actual size. or what ever the screen pixel density ratio to viewport is. AKA it looks like crap.
And to answer your needs on this I'm just going to direct you here to MOZ who will go over the whys and how's as well as show you what to do to combat this.
Moz on Viewports
Combating element position is pretty easy you just use :
<meta name="viewport" content="width=device-width, initial-scale=1" />
In your <head>,
Moz on Image Scaling
the situation is as follows: there is an HTML5 game. The game is quite heavy in terms of the javascript code, graphics and sounds – approximately 30 MB. All the animation is created by means of createjs. In the game I use 2 canvases one over the other; the control buttons are between the canvases (the buttons are created by means of the standard button elements).
One canvas is the main one and most of the animation is implemented on this canvas; the second canvas is used when it is necessary to show the animation over the control buttons. Initially, the size of each canvas was 970px x 740px. All the animation worked perfectly in desktop browsers as well as in Chrome and FireFox in Android. However, in the mobile Safari browser the animation worked very slowly.
Then I reduced the size of the canvases by 30 % (accordingly to the graph on the sprite sheets). As a result, Safari started working more efficiently on an ipad. The animation of the lower canvas stopped hanging but only unless the extra animation was launched on the upper canvas. Then everything got slow again. I don’t apply WebGL because I have to use both bitmap and the vector graphics. Who knows how to improve the situation in this case so as to prevent the FPS from falling, could you help me, please?
There is another funny thing: if you minimize the browser and then maximize it again, the game starts working faster from time to time.
We have a web based LOB application and currently we are shrinking the content of the app when it goes onto a smaller resolution browser i.e. IPad, using the viewport. using javascript:
document.querySelector("meta[name=viewport]").setAttribute(
'content',
'width=device-width, initial-scale=0.8');
This works fine asthecially but it seems to produce a performance hit when the browser has to scale everything down, especially with our kendo controls (the grid takes a massive hit).
Just wondering if anyone can advice a better was to scale down the viewport without hitting any performance issues?
I'd be surprised if you're getting a performance hit from scaling the page since that happens on the GPU and is expected to be very fast.
Additionally, your viewport descriptor as-is wont scale the page unless you have content that's explicitly wider than your layout size (for example, a very wide image). The browser will automatically zoom out to show all the content on load so your best bet is to pick a good layout width for your page (e.g. width=1200) and not set an initial-scale. width=device-width will attempt to lay your page out into the size of the device's screen, which is not what you want if you're trying to scale your page down.
I am working on an application with a large number of animated images.
The main negative factor affecting frame rate is images being decoded while the animations are occurring.
To prevent this problem, I am inserting clones of images into the DOM, before they are expected to be animated into view. The clones have low opacity and tiny size in order to be visible enough to trigger decoding without affecting the page's appearance.
As revealed by chome's dev tools timeline, this effectively causes the images to be loaded from server and decoded in the client before they are animated, with positive effects on frame-rate.
I am trying to figure out if there may be adverse effects to this solution. For example, is there a risk of overloading the GPU memory limits for decoded images, and thereby slow rather than improve performance?
In the current implementation, the cloned images are constantly added and removed from the screen in anticipation of the user's expected viewing pattern of the content. If I could be certain that there is no harm in keeping more clones on the screen at once, the percentage of images that would be successfully pre-loaded and decoded would increase.
I've got a image... and if the image's height is greater than maxHeight, or the width is greater than maxWidth, I'd like to proportionally resize the image so that it fits in maxWidth X maxHeight.
While this can be done, what happens when the user's screen is much bigger than the native size of the image? Do you stretch it to the point of it degrading into pixels?
What happens with people with smaller screens - do they have to waste time and bandwidth downloading an image that is much larger than they're capable if displaying, then depending on the browser to scale the image down?
In many browsers, especially older ones, scaling images degrades them, whether making them bigger or smaller. It's best to scale them on the server, based on a large image and deliver the "right" sized image to the client. This is much more complicated.
While all of this is possible, one must ask whether this really adds much value to the user experience in the first place and whether all this effort is worth it.
You can set the attributes of the image tag using JavaScript.
The properties you may like to set are height, width.