[webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Maciej Stachowiak]

On Apr 16, 2012, at 1:44 PM, Darin Fisher wrote:

> On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt <oliver at apple.com> wrote:
> 
> On Apr 16, 2012, at 1:00 PM, Darin Fisher <darin at chromium.org> wrote:
> 
>> On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak <mjs at apple.com> 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.
>> 
>> In addition, the whatwg thread revealed that there are many hidden complexities in the design of get/putImageData, in particular designing how they work in the face of sychronous drawing operations to the same canvas. The HiDPI problem is much more straightforward and does not need to be gated on resolving the async design issues.
>> 
>> 
>> I think you are giving up a good opportunity.  The barriers to an async API are more readily overcome when there are extra benefits to developers.  HiDPI could be a great way to attract developers to a better API.
>> 
>> I've addressed those other concerns on the WhatWG thread.
> 
> No, gating HiDPI on rewriting your code into a more complex, and generally slower model seems like a great way to encourage developers to ignore high dpi.
> 
> --Oliver
> 
> 
> I'm not sure why developers would choose to ignore HiDPI.  It seems like it helps their apps/pages look better!
> 
> You really feel like you need to "kowtow" to developers to get them to adopt HiDPI?

Different developers will have different priorities. HD image data and async readback both have potential benefits in image quality and nonblocking responsiveness respectively. Here is an example of an application using getImageData which would clearly benefit from HD, but it's not obvious that async would be useful:

http://mudcu.be/sketchpad/

Here is another where HD helps but benefits of async are unclear, since it does a pixel read-write-modify cycle:

http://nerget.com/pressure/pressure.html

Tying HD to async may hurt the adoption of both by requiring developers to take two different code change hits when they only care about one. In particular, the async change is likely to be more invasive to code structure.  If developers are discouraged, they may end up using neither. Thus, in my opinion, these two enhancements to ImageData should stand and fall on their own merits.

Regards,
Maciej



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120416/2f80b4d9/attachment.html>