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

[Darin Fisher]

On Mon, Apr 16, 2012 at 3:34 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>
>
Hi Maciej,

I was thinking that an asynchronous version of getImageData could be used
to fetch either the HD or non-HD backing.

At any rate, it seems like my motivation is clear.  Blocking getImageData
is a performance penalty for implementations that use deferred rendering.
 If not a penalty for the caller, then surely a penalty for other pages
that may share the same thread.  Making such an API return even larger
amounts of memory seems like it only increases the penalty.

I understand your desire to separate these concerns.  I'm just worried that
we are missing an opportunity to guide developers to a better place.

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120416/68daab0e/attachment-0001.html>