component
Support eventual deprecation
As far as I understand it, the backing data for the canvas is slated to eventually be "auto-retinified" via the getImageDataHD etc methods (see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-getimagedatahd ).
Ideally this component should future-proof the canvas and not do the "scale by 2x" hack if the *HD() methods are present on the canvas. (It might also want to wrap getImageData and other methods so that the *HD version is called iff present.)
I don't really get what they're going for, I dont see how HDPI displays have anything to do with bitmaps really, seems odd but maybe im missing something
@visionmedia the question is how many actual pixels are in your bitmap. The web spec says that the dimensions of your canvas are "css pixels", which don't have a fixed relationship to real pixels any more in this brave new world of HDPI displays. So the idea is that the canvas will allocate as many "real pixels" as necessary to make your bitmap look good at the given size in CSS pixels. This makes most uses of canvas automagically appear sharper. But some users will need to get at the actual literal backing store...
yeah I suppose that would be more efficient than what we're doing here haha. interestingly Safari does not seem to define those but it does already go ahead with the rest