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

Darin Fisher darin at chromium.org
Mon Apr 16 13:44:59 PDT 2012


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?

-Darin



>
> -Darin
>
>
>
>>
>> Regards,
>> -Darin
>>
>>
>>
>> On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein <mitz at apple.com> wrote:
>>
>>> [This is actually an enhancement announcement to an existing feature]
>>>
>>> Over at <
>>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html>,
>>> Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to
>>> allow authors to take full advantage of high-resolution backing stores,
>>> when available (whereas the existing API hides the fact that the backing
>>> store resolution is not CSS pixel resolution, for compatibility with
>>> existing content). The enhancements include a backingStorePixelRatio
>>> attribute and {get,put}ImageDataHD functions on CanvasRenderingContext2D.
>>>
>>> Through <https://bugs.webkit.org/show_bug.cgi?id=83619> and <
>>> https://bugs.webkit.org/show_bug.cgi?id=83836>, I am making these
>>> enhancements, with the names prefixed with “webkit”.
>>>
>>> There is no build-time option to disable these enhancements. Ports that
>>> don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version
>>> of the additional API. Ports that opt into high-DPI canvas need to enhance
>>> their ImageBuffer implementation to fully support the resolutionScale and
>>> CoordinateSystem parameters.
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120416/9a6f1a41/attachment.html>


More information about the webkit-dev mailing list