On 4/16/2012 12:55 PM, Maciej Stachowiak wrote:
On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
Could this be an opportunity to design an asynchronous API for
fetching the pixel buffer? It seems like many implementations are
GPU backed now, and fetching the pixel buffer is an expensive
(blocking) operation. Had you considered making such a change?
Adding async support was suggested on the whatwg thread about this. I
think async support is useful, but should not be tied to high DPI
support. In particular, we shouldn't, in my opinion, require authors
to rewrite their existing sync code to an async model just to properly
support higher resolutions.
TL;DR: Canvas authors will largely be using web workers (thus async)
regardless of this proposal.
Oliver Hunt is suggests that an async fetch would be of "significant
additional complexity for content authors"; Maciej, you're also saying
that "authors [would have] to rewrite their existing sync code".
ImageData operations are very much a niche, a very small niche, inside
of yet another very small niche. Canvas is an expensive low-level API to
work with. Cheaper than SVG support, but still expensive.
Authors working with Canvas have taken on complexity already.
All authors working with Canvas ImageData are looking at it from an
async perspective because they'd like to offload the work to another thread.
We've had to wait awhile for it but webkitPostMessage and
Uint8ClampedArray are coming along. Those are already an async pairing.
Further, we can do little optimizations to treat the typed array as a
Float32. Once we're knee-deep in ImageData, everything is on the table.
The "code complexity" of async vs sync on ImageData is minor. Authors
are looking at using async anyway so that they have the option to move
the heavy lifting off-thread so as not to block the UI.
I just have to disagree with Oliver and Maciej here on the "complexity"
and "rewrite" portions. 1) It's already being done as common practice so
as not to block the UI, 2) It's not complex nor a rewrite, it's just a
simple layer
of code, and 3) we're already looking at far more complex things in
Canvas such as simply supporting requestAnimationFrame.
-Charles
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
