Re: [whatwg] High-density canvases

In the previous incarnation of High density canvases (i.e. getImageDataHD
and friends), we worked under the assumption that it was okay to have a
backing store with a pixel density that is higher than CSS pixel density.
And I think that was perfectly acceptable.

If I recall correctly, the feature failed because some websites were
already using CSS hacks to boost their pixel density, which led to 16x
(rather than 4x) memory consumption for canvas pixel buffers on devices
with a 2:1 device to CSS pixel ratio.  I think that failure could have been
avoided by making the feature smarter by dynamically adjusting the HD ratio
applied to the canvas to prevent canvas pixel density from being boosted
beyond the display's pixel density.

I am currently trying an experimental approach where canvases that are
drawn to, but never read from (no toDataURL or getImageData calls) have
their contents stored as a command buffer, rather than a pixel buffer. This
way, the contents can be painted at any resolution (à la SVG).  This
approach also allows canvases to be rasterized asynchronously, it allows
contents to change pixel density without redrawing in JS (in reaction to a
page zoom, for example), and it can support arbitrarily large canvas sizes.
In theory, it would be possible to inject this behavior without any changes
to the spec, but some side effects may be hard to resolve and/or live with.
 Having an experimental implementation will help us discover and iron-out
the issues. In the end, it may have to ship as opt-in behavior, but that
remains to be determined.

My main point is, there is potentially significant progress in terms of HD
canvas rendering that can be achieved without any changes to the spec
(other than perhaps an opt-in flag). If it works out well without an
explicit opt-in, legacy websites will benefit.

    -Justin


On Tue, Jun 17, 2014 at 11:06 PM, Mark Callow <callow.mark@artspark.co.jp>
wrote:

> On 13/06/2014 12:42, Robert O'Callahan wrote:
> > Here's an alternative proposal which I think is a bit simpler and more
> > flexible:
> > Expose two new DOM attributes on HTMLCanvasElement:
> >     readonly attribute long preferredWidth;
> >     readonly attribute long preferredHeight;
> > These attributes are the UA's suggested canvas size for optimizing output
> > quality. It's basically what Ian's proposal would have set as the
> automatic
> > size. We would also add a "preferredsizechange" event when those
> attributes
> > change.
> I like the functionality but these names really don't convey that
> functionality. The names you originally proposed over in *Bug 1024493*
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1024493> at mozilla.org,
> renderedPixelWidth/Height, while not perfect, convey it much better.
>
> Regards
>
>     -Mark
>
> --
> 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合
> が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情
> 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし
> たら削除を行い配信者にご連絡をお願いいたし ます.
>
> NOTE: This electronic mail message may contain confidential and
> privileged information from HI Corporation. If you are not the intended
> recipient, any disclosure, photocopying, distribution or use of the
> contents of the received information is prohibited. If you have received
> this e-mail in error, please notify the sender immediately and
> permanently delete this message and all related copies.
>
>

Received on Wednesday, 18 June 2014 15:30:41 UTC