Created attachment 210250 [details] Test case 1: translate3d When using something that triggers hardware acceleration, such as translate3d or transitions, translating by a non-whole number of pixels makes the contents blurry. I've attached a test case and screenshots of how it renders in the latest WebKit and Firefox nightlies. Try it on a non-retina display, as retina displays will show the translations by "half pixels" correctly.
Created attachment 210251 [details] Result on Safari with latest WebKit nightly
Created attachment 210252 [details] Result on latest Firefox/Gecko nightly
CC-ing a couple of people to whom this might be of interest. Also confirming.
This is just a side-effect of the underlying framework used to render 3D transforms on Mac. Not much we can do about it.
Created attachment 210392 [details] Result on Chrome 29 on Windows Are you sure about that Mac thing?
Created attachment 210395 [details] Test case 2: transition Also, another test case here. While transitioning, the second line is blurry, while the first one isn't.
This is the difference in rendering between asking the underling text subsystem to render at fractional pixel offsets, and rendering at a pixel boundary into a texture, then compositing that texture at a fractional-pixel offset.
How does Gecko get this right? Just from looking at the result, it seems to me like they just round beforehand. Didn't dig into the code though.
Still present in latest nightly on OS X. Probably on other platforms too.
If it is a non rotating or 3d transform, the content can be rounded to whole pixels and the subpixel part put in the subpixel accumulation. That is what we do for accelerated composited layers with subpixel precision position.
I'm attaching a Test case 3 which is a simple 2D translate but includes an iframe to a Vimeo video, however the symptom appears in a very specific case. I have a Macbook Pro with Retina display and an attached Thunderbolt Display. When I view the page on my Macbook Pro's LCD screen, it actually looks fine and crisp. However, when I view it on the Thunderbolt Display, it shows up blurry. I've attached an image comparison of the test page when you load it without the iframe vs when you load it with the iframe; both involve translate() of the DIV element. If Simon Fraser is correct and this is a subsystem issue of Mac OS X, then I can only theorize that that framework is not correctly handling externally attached monitors. But what about the mere act of adding the iframe to the DIV container?
Created attachment 245483 [details] Test case 3 - Video iframe inside a translate() DIV
Created attachment 245484 [details] Result of Test case 3 on latest Webkit Nightly (OSX) Comparing the loading of the page first without the video iframe, and then with the video iframe.