[whatwg] High-density canvases

Stephen White senorblanco at chromium.org
Wed Oct 2 07:48:25 PDT 2013

On Fri, Sep 27, 2013 at 5:51 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 10 Sep 2013, Stephen White wrote:
> >
> > For posterity, here were our objections to the original high-DPI canvas
> > spec:
> >>    - It doesn't scale well to non-integer devicePixelRatios
> Can you elaborate on this? I don't see why the new proposal would have
> this problem, but I also don't see why the old one would, so I don't know
> if it's because I don't understand the problem or if it's because I'm
> missing something from the old proposal.

IIRC, the concern was that calling getImageData() would return surprising
results when resampling by non-integer ratios, where the returned result
very much depends on the resampling mode, and the border treatment. At any
rate, since getImageData() doesn't resample in the new proposal, this won't
be a problem.


> One question: now that some browsers are including browser zoom (page
> > zoom) in window.devicePixelRatio, will/should the new proposal
> > automatically cause a resize callback on page zoom, in order to preserve
> > 1:1 device pixels?
> My intent was to do so, yes. In practice I presume it'd be up to the
> browser to decide how often to actually do this (e.g. if page zoom is
> being smoothly animated, you may wish to only do it every few frames).
> > (Note that I think this is a problem with current JS-based
> > implementations of canvas auto-scale as well, although perhaps there's a
> > DOM event for this that you can listen to; I might just be showing my
> > ignorance here.)
> Currently page zoom should trigger a 'resize' event, but I expect few
> pages check.
> On Tue, 10 Sep 2013, Justin Novosad wrote:
> >
> > There is another closely related issue that's been discussed before:
> > adding a redraw callback to 2d canvas.  In the past we discussed this
> > for solving the problem of recoverring from a gpu context loss, but it
> > seems there may be better reasons to consider adding a redraw callback
> > such as freeing memory consumed by canvas backing stores that are in
> > background tabs, and re-building the content when needed. This
> > discussion was revived in the past few days on the chromium graphics-dev
> > mailing list:
> >
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/graphics-dev/CQJXpXxO6dk
> >
> > The idea is still embryonic and we're brainstorming in this chromium
> > issue: crbug.com/287823
> >
> > I think that discussion should be merged with this thread because a
> > resize event is another case where one may want to redraw. It would be
> > great to solve all of these issues together.
> I think it would make eminent sense to also fire the event ('resize', I
> guess) if the context was lost or if the canvas was about to be made
> visible again after the browser dropped the rendering, yes.
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list