Re: [whatwg] High-density canvases

On Wed, Jun 18, 2014 at 8:30 AM, Justin Novosad <junov@google.com> wrote:

> 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.
>

This should be an explicit opt-in, otherwise applications that call
'getImageData', will suddenly get a different rendition.
Also, they might *want* to see the pixels in which case upscaling is
undesired.

To make this work, you might have to store potentially an infinite amount
of commands which is problematic.


> 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 Thursday, 19 June 2014 03:43:50 UTC