On Mon, Apr 16, 2012 at 3:34 PM, Maciej Stachowiak <m...@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 <oli...@apple.com> wrote: > >> >> On Apr 16, 2012, at 1:00 PM, Darin Fisher <da...@chromium.org> wrote: >> >> On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak <m...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev