Created attachment 59232 [details] look at the run/pause/stop buttons When images are loading the aliasing becomes ugly for some seconds. You can find a test case website at the following URL http://antoinemercadal.fr/archipelalpha and video that illustrates this bug (attached)
Also can be reproduced on http://googlewavedev.blogspot.com/2010/06/running-contest-in-wave-behind-scenes.html just scroll up and down and watch the images.
It appears that scaled images that are not being presented at their original size are being drawn aliased and then are anti-aliased afterward. It doesn't matter if the picture is embedded in a web page or viewed directly. For example, resize your browser window to small and load the following link. http://development.rhubarbproductions.com/scale/The+Losties+HD.jpg When Safari scales it you see the issue. Click out of the window and back again and you'll see the aliasing happen again. This started occurring between r61173-r61351. It's also occurring for me with 10.5.8 PPC.
You should add the keyword Regression and rename the summary to something like: REGRESSION: r61173-r61351 - Aliasing of scaled images on load and repaint This would get more attention and you could loosen the platform settings to apply to either intel or PPC and 10.5 and later.
Latest webkit seems to resolve the initial loading aliasing and the repaint issue for html embedded images, but with the Losties image I provided a direct link to, I still get aliasing when resizing the window which didn't occur before. It also loads well and doesn't repaint with aliasing. It just does it on resizing the window now.
Last update seems to correct the embeded image bug and the losties image given by Kevin works for me.
Note that this is not entirely fixed, because I still see aliasing when resizing a directly linked image that didn't occur before the original bug.
Ok so I reopen it.
*** This bug has been marked as a duplicate of bug 41036 ***
Kevin, the behavior you mention in comment #4 is now expected. An image that is rapidly resizing will use a lower quality interpolation setting until it finishes resizing, at which point it will use a higher quality interpolation. Performing high-quality interpolation on a resizing image hurts performance.
I should also note that if you’re not fond of that change then you should file a different bug. This bug was quite clearly about the change in interpolation quality during load and repaints. Changes during resizing are separate from that.
Shouldn't the low-quality interpolation only kick in when it's on a low performance device and not for everyone even it they're on a well performing computer? Firefox doesn't do it, and Safari didn't used to do it. It just seems a step back in quality. It also seems to affect javascript based resizing where it didn't before. Also it doesn't seem to matter whether it's a rapid resize or not. I can barely move the mouse and it still looks bad for no reason. Go to http://shadowbox-js.com/ and scroll down and click on the Tiger image and the resize your browser to smaller than the tiger picture. Before it was a beautiful thing, scaling smoothly and cleanly. Now it's just a chunky uglier version of itself, when performance-wise there was no problem before. Just a step back in quality in my opinion. It just seems as we're moving further into an era where javascript and css manipulations of graphics are becoming more prevalent to throw out quality that was already in place and feature-matched at least some of the other browsers. The reason I included the resize method here is because all the aliasing issues happened during the same timeframe so I figured they were all related and all needed fixing.
As I said: if you consider that to be a problem, please file a new bug report.
OK, spun off to Bug 41233 It just didn't sound like it was going to be considered a bug and may just be ignored... but there it is anyway.