On 4/16/2012 11:07 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiak<m...@apple.com> wrote:
On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are currently difficult or impossible.
I hear you on the benefits of async calls, but I think it would be better
to sell authors on their benefits separately.
Aren't we missing an opportunity here? By giving web developers this easy
migration path, you're also giving up the opportunity to encourage them to
use a better API. Asynchronous APIs are harder to use, and that's why we
need to encourage their adoption. If you just give people a synchronous
...
GPU readback of a HD buffer is going to suck. Any use of this new API is
going to suck.
The vibe I got from the discussion over at WHATWG is that developers and
vendors would like to see an async getImageDataHD.
"put" isn't so much of an issue, but "get" is.
As developers, we're going to be using async more-and-more with Canvas;
from the toBlob semantic to postMessage transfer semantics.
As a Canvas developer, I'd be inclined to use the HD buffer even if it's
the same backing size as the standard buffer, if it supported async
semantics.
...
Separately, I'm hoping to see this issue sorted out:
https://lists.webkit.org/pipermail/webkit-dev/2011-April/016428.html
IE9+: magicNumber = window.screen.deviceXDPI / window.screen.logicalXDPI;
WebKit: magicNumber = (window.outerWidth / window.innerWidth) *
(window.devicePixelRatio||1) ; 'with a small margin of error';
Canvas developers today need to use that nasty webkit hack to get their
magic number. It's not fun, and I wish we could move off it.
IE9 on the desktop works appropriately. I can use browser zoom and
re-render with a crisp/sharp Canvas bitmap using the window.screen
extensions.
-Charles
