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? -Darin > > -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
