- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 10 Sep 2013 20:24:20 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: Stephen White <senorblanco@chromium.org>, Dean Jackson <dino@apple.com>, Rik Cabanier <cabanier@gmail.com>, WHAT Working Group <whatwg@whatwg.org>
On Mon, Sep 9, 2013 at 7:31 PM, Ian Hickson <ian@hixie.ch> wrote: > Right, resetting the context would definitely be part of the deal. This > mode would be specifically defined as a mode where you had to listen to > onresize or your canvas would almost certainly get cleared sooner or > later. In fact, we could go further, and say that canvases that aren't > getting rendered at all (e.g. display:none, off-screen, background tab) > can get cleared, with the deal being that next time you need to show the > canvas you immediately get an onresize. > It would be better if the resize didn't happen until the page is actually ready to re-render. That way, the canvas doesn't flicker if it's rendered before the page actually does render (eg. it may need to reload resources to render). Rendering a blurry canvas briefly is better than rendering a blank canvas. For example, add a method "resizeToCurrentDPI()", and don't do it automatically at all. Fire an event when calling the method *would* cause a change of canvas size. The page can then load resources asynchronously as needed, and call the method when it's ready to redraw, avoiding any period where a blank canvas might be composited. > Yeah, my suggestion, if we do this, would be to not do it until high > density displays are even more widely available than now. This is mostly a > convenience and performance-improving API, not a critical feature add. > High-DPI displays are already widespread in mobile (all Apple devices except for the iPad Mini; the Kindle Fire HD), and by contrast there's no sign of them for desktops, so I think we're either there now or we won't be for a long time. -- Glenn Maynard
Received on Wednesday, 11 September 2013 01:24:46 UTC