W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] Canvas size and double buffering.

From: Tim Hutt <tdhutt@gmail.com>
Date: Wed, 3 Feb 2010 17:22:12 +0000
Message-ID: <c120886e1002030922h4569be7bt8c3b0194d3d523d9@mail.gmail.com>
On 3 February 2010 16:50, Simon Fraser <smfr at me.com> wrote:
> On Feb 3, 2010, at 7:59 AM, Boris Zbarsky wrote:
>
>> On 2/3/10 9:05 AM, Tim Hutt wrote:
>>> 1. You can only set the size exactly in pixels. It is very hard to get
>>> a resizable canvas that fills the page. You *can* set the size in CSS,
>>> but it doesn't work very well (e.g. using left,right-margin: auto; to
>>> centre the canvas doesn't work. Also it scales the canvas rather than
>>> resizes it.
>>
>> That's right, because resizing the canvas (as in, changing the number of pixels in the backing store) involves clearing it at the moment. ?Your proposal would mean that if the user changes the window size your canvas will immediately get cleared. ?Is that what you're after? ?If not, how do you envision the backing-store resize being performed?
>
> Canvas drawing should have been callback-based from the start. Maybe we can retrofit this by having a way the author can specify that the canvas backing store resizes with the element, and firing an event when the backing store size changes.

Yes it should be cleared and there should be a oncanvasresize() callback.

>>> 2. There doesn't appear to be any kind of double buffering capability.
>>> This is pretty critical for animations where you might need to clear
>>> the canvas and then draw stuff. You currently get flickering if you
>>> try.
>>
>> You do? ?Under what circumstances?

Ahem, I was sure I got flickering, but I just tested firefox 3.5 and
chrome 4 and actually they do behave as you describe.

Tim
Received on Wednesday, 3 February 2010 09:22:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:55 UTC