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 > > -Darin > > >> >> Regards, >> -Darin >> >> >> >> On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein <m...@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@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
