What is the current state of sub-pixel accuracy in the major browsers?

Question

I'm working on a drawing application which requires high levels of accuracy, and I'm wondering which of the major browser platforms (including the HTML Canvas element, and Flash) give the best sub-pixel layout accuracy, both for drawn elements (rectangles in the Canvas or Flash, absolutely positioned DIVs in the browser), and for text.

There are a number of posts related to this, both on this site and others, (see list at bottom), but many are quite old, and none summarises the current situation.

My understanding is that Flash has native support for sub-pixel positioning, using twips to position objects to one twentieth of a pixel, and that when the TextLayoutFramework is used, this accuracy also extends to text. There is at least one report, however, that this doesn't work properly in Chrome. Can anyone confirm this?

My understanding of the situation in the browsers is that Firefox 14+ supports sub-pixel positioning for text and drawn elements, both in page layout and within the Canvas, but I haven't been able to ascertain how accurate this is.

I understand Chrome (as of v21) does not support sub-pixel positioning at all.

I understand IE9 doesn't support sub-pixel positioning, but it appears from the MS blog post linked below that IE10 will.

I don't know if there's any Mac/PC variance in this, and I don't know also if the accuracy of Flash varies between platforms and/or browsers.

I understand a summary question like this may provoke some debate, but I believe this is specific enough for people to provide useful answers, and hope that this thread can be a reference for the state of positioning accuracy up to now.

Some references:

http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx

Sub-pixel rendering in Chrome Canvas

http://johnblackburne.blogspot.co.uk/2011/11/twips.html

http://ejohn.org/blog/sub-pixel-problems-in-css/

Sub Pixel CSS positioning

https://productforums.google.com/forum/?fromgroups=#!topic/chrome/pRt3tiVIkSI

Answer 1

Currently, you can expect the best rounding and sub-pixel support to come from Mozilla with IE as the runner up. IE might end up being more fine tuned, but their release cycles are so long that Mozilla is likely to stay ahead of them.

As far as doing sub-pixel layout, you may be chasing a wisp, because the sub-pixel advantage improves anti-aliasing issues, not screen location accuracy. Your image will never be more accurate than 1 pixel from the true position, regardless of sub-pixel support.

The reason why some browsers don't zoom properly has nothing to do with sub-pixel support, it is because they are not remembering the exact position and rounding correctly. In other words, they are prematurely rounding the position and that causes the image to be mis-aligned.

Answer 2

Short answer:
No. It is NOT possible/documented.
And even if determined experimentally, it is NOT guaranteed to remain the same in future.

Long answer:
At sub-pixel accuracies, there is a lot of variance among Browsers/OS/HW about how the input is captured/rendered. With h/w acceleration being enabled on most modern browsers, there are a large number variations in rendering across different PCs running different browsers on different operating systems. So much so that, it is possible to even identify every unique user by the slightly different variations in the rendered output of a common sample.

Rather than worrying about the discrepancies in the underlying frameworks, How about designing the UI of your drawing application to be independent of those problems. Couple of methods i can think of right now are:

1. Allow editing the image at zoomed/magnified levels.

2. Design a snap-to-grid method for elements.

Update:
The "zoom" operation would your custom implementation and NOT a feature of the underlying frameworks. So if you need sub-pixel accuracy to the order of 1/10th of a pixel, one would need to have a 10x_zoom() implemented as part of you web-app which would render the data from

1st pixel --> 10x10pixels at (0,0),
2nd pixel --> 10x10pixels starting from (11,11).

This way one would have a very magnified view of the data, but the framework is blissfully unaware of all this and renders accurate to the onscreen-pixel(which in our case now is 1/10th of the image pixel).

Also an important thing to note that this operation would consume a lot of memory if done for the entire image at once. Hence doing this for ONLY the visible part of the image in a "zoom-window" would be faster and a less memory intensive process.

Once implemented in your drawing web-app the sub-pixel inaccuracies in the frameworks might not turn out to be a problem for the user as he can always switch into these modes and provide accurate input.