Re: [whatwg] Canvas size and double buffering.
On Fri, Feb 5, 2010 at 3:25 AM, Brian Campbell wrote: > On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote: > > > On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell > wrote: > > I think the most reasonable approach would be to say that the > getBoundingClientRect().width or height is rounded to the nearest pixel. > Boxes are displayed rounded to the nearest pixel, with no fractional pixels > being drawn, right? > > > > No. > > In what cases are fractional pixels drawn? I see fractional widths being > returned here, but it seems to be drawing rounded to the nearest pixel: > > http://ephemera.continuation.org/percentage-width.html > Box edges are (usually) snapped to the nearest *device pixel* boundary. That is not the same as rounding the CSS pixel width or height to the nearest integer. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Canvas size and double buffering.
On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote: > On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell > wrote: > I think the most reasonable approach would be to say that the > getBoundingClientRect().width or height is rounded to the nearest pixel. > Boxes are displayed rounded to the nearest pixel, with no fractional pixels > being drawn, right? > > No. In what cases are fractional pixels drawn? I see fractional widths being returned here, but it seems to be drawing rounded to the nearest pixel: http://ephemera.continuation.org/percentage-width.html > Why would they report a width or height that is different than how they are > displayed? All browsers that I've tested (the ones listed above, so not IE) > report integral values for getBoundingClientRect().width and height (or for > left and right in the case of Opera, which doesn't support width and height). > > Firefox often returns non-integral values for getBoundingClientRect().width > or height. Sorry, I meant to write "but Firefox", but somehow missed that. Safari, Chrome, and Opera all return values rounded to the nearest pixel. -- Brian
Re: [whatwg] Canvas size and double buffering.
I tried to solve the aliasing problem in Firefox and found out, that it really isn't possible to get it right, if you set the width and height in CSS: If you leave the css-width/height as it is when resizing the canvas, it will get blurred in Firefox. If you change it to 'auto' it won't resize correctly next time. So the only possibility is to get sharp lines and correct sizing is to first set the css-width/height procentually in JavaScript, then set the canvas.width/height using getBoundingClientRect and than setting css-width/height to 'auto'. (Everything on every resize). Furthermore you have to add one Pixel to the width if it isn't dividable by 2, because Chrome would add a strange white line otherwise. So here is how it looks: http://nikic.lima-city.de/canvastest2.html Works in Firefox and Google Chrome. Sorry for double post.
Re: [whatwg] Canvas size and double buffering.
Am 04.02.2010 01:00, schrieb Tim Hutt: On 3 February 2010 23:16, Boris Zbarsky wrote: On 2/3/10 6:12 PM, Tim Hutt wrote: Ah yes that works nicely Hmm maybe I spoke too soon. The interaction of the CSS size and the canvas.width/height is confounding! It seems if you set a CSS width of, say 80% then that is that and you are stuck with it. Unfortunately it doesn't round to the nearest pixel! I have created a test case here: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) If anyone can get it to work as described on that page, then thank you! Otherwise I think things need to be changed to make it possible. http://nikic.lima-city.de/canvastest.html This one satisfies at least the styling conditions (in Firefox and Chrome): * The canvas has 80% width * The canvas has 50% height (This one worked in Firefox only after setting height 100% on body and html. Strange...) * Resizes when the browser resizes * Is centered I only couldn't figure out the "Always draw a non-aliased pattern of lines" part in Firefox. I tried some stuff, but it didn't work.
Re: [whatwg] Canvas size and double buffering.
In general, keeping the canvas buffer size matching its rendered size so that no resampling occurs requires clearing and repainting the canvas during browser zoom changes as well as layout changes (and possibly during other changes such as changes to the transforms of ancestors). It also requires more than just getBoundingClientRect(). Authors can't do this without some new feature(s). Perhaps something like an attribute "autoresize" which automatically sets the buffer size, clears the canvas and fires a "redraw" event at the canvas element whenever the ideal canvas buffer size changes? Sounds like a v2 feature to me though. In the meantime, use SVG if you can. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Canvas size and double buffering.
On Thu, Feb 4, 2010 at 1:00 PM, Tim Hutt wrote: > http://concentriclivers.com/canvas.html (the source is nicely > formatted and very short) > canvas.style.width = ww; canvas.style.height = hh; Perhaps you meant ww + "px" and hh + "px"? Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Canvas size and double buffering.
On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell wrote: > I think the most reasonable approach would be to say that the > getBoundingClientRect().width or height is rounded to the nearest pixel. > Boxes are displayed rounded to the nearest pixel, with no fractional pixels > being drawn, right? > No. > Why would they report a width or height that is different than how they are > displayed? All browsers that I've tested (the ones listed above, so not IE) > report integral values for getBoundingClientRect().width and height (or for > left and right in the case of Opera, which doesn't support width and > height). > Firefox often returns non-integral values for getBoundingClientRect().width or height. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 7:00 PM, Tim Hutt wrote: > On 3 February 2010 23:16, Boris Zbarsky wrote: >> On 2/3/10 6:12 PM, Tim Hutt wrote: >>> >>> Ah yes that works nicely > > Hmm maybe I spoke too soon. The interaction of the CSS size and the > canvas.width/height is confounding! It seems if you set a CSS width > of, say 80% then that is that and you are stuck with it. Unfortunately > it doesn't round to the nearest pixel! > > I have created a test case here: > > http://concentriclivers.com/canvas.html (the source is nicely > formatted and very short) > > If anyone can get it to work as described on that page, then thank > you! Otherwise I think things need to be changed to make it possible. That example: * Works for me in Chrome (5.0.307.1 dev, all browsers listed are on Mac OS X 10.6.2). * Works in Safari (WebKit nightly 6531.21.10, r54122) except for when you cause a scroll bar to appear or disappear by resizing; then you get a moiré pattern in the vertical stripes until you resize again. It appears that you get the resize event before the scrollbar appears, so the scrollbar appearing causes the canvas to scale down without sending a resize event allowing the canvas to redraw. * Doesn't work in Firefox (3.6). At most sizes, you get grey lines, due to the non-integral width; only occasionally does it look correct. Also, the canvas always resizes to a square; does Firefox try to preserve the aspect ratio when scaling a canvas in one dimension only? * Fails badly in Opera (10.10). It fails to redraw because "width" and "height" aren't defined on the BoundingClientRect; just left, right, top, and bottom. For some reason it also ignores the 500px height of the canvas given in the HTML, instead using the default of 300x150, with the width overridden to 80%. I think the most reasonable approach would be to say that the getBoundingClientRect().width or height is rounded to the nearest pixel. Boxes are displayed rounded to the nearest pixel, with no fractional pixels being drawn, right? Why would they report a width or height that is different than how they are displayed? All browsers that I've tested (the ones listed above, so not IE) report integral values for getBoundingClientRect().width and height (or for left and right in the case of Opera, which doesn't support width and height). -- Brian
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 7:00 PM, Tim Hutt wrote: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) So you want a canvas that "takes 80% of the horizontal space" but has an integer width in pixels? Which of those constraints do you really want to relax? Presumably the 80% one? -Boris
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 23:16, Boris Zbarsky wrote: > On 2/3/10 6:12 PM, Tim Hutt wrote: >> >> Ah yes that works nicely Hmm maybe I spoke too soon. The interaction of the CSS size and the canvas.width/height is confounding! It seems if you set a CSS width of, say 80% then that is that and you are stuck with it. Unfortunately it doesn't round to the nearest pixel! I have created a test case here: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) If anyone can get it to work as described on that page, then thank you! Otherwise I think things need to be changed to make it possible.
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 6:12 PM, Tim Hutt wrote: Ah yes that works nicely, with one minor caveat: it seems to include the width of the border if there is one, so you have to take that into account. You're right, this is a better solution. Ah, yes. Padding too. You could instead ask for the computed style width, but I'm not sure whether that does what it does in Gecko (return the actual used width) in all browsers. It might be good to create some APIs to query these sorts of box properties. Anne, are you on this list, by chance? ;) -Boris
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 20:14, Boris Zbarsky wrote: > Yep. canvas.width = canvas.getBoundingClientRect().width; Ah yes that works nicely, with one minor caveat: it seems to include the width of the border if there is one, so you have to take that into account. You're right, this is a better solution. Cheers.
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 5:27 PM, Brian Campbell wrote: I'm curious; where is this being worked on? Discussed here on this list? On another list? I believe it's been discussed on public-webapps. It's also implemented in IE, to some extent. -Boris
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 3:14 PM, Boris Zbarsky wrote: > On 2/3/10 2:54 PM, Tim Hutt wrote: > >> Well, yes it would be good to have onresize for all elements. > > Which is why it's being worked on anyway. I'm curious; where is this being worked on? Discussed here on this list? On another list? Or is it just being implemented by some browser vendors independently? I don't see discussion of it recently on this list, so I'm curious as to where the discussion would be; there seem to be a lot of lists in a lot of places these days for discussing various bits of browser standards, and it's hard to figure out what goes where. For core HTML & the DOM, there's this group, public-html at the W3C, and public-webapps at the W3C; am I missing any? There's also the Device API groups which seems to overlap the domain of the webapps group quite a bit. There are of course the more clearly delineated groups, such as es-discuss, www-style, SVG, MathML, and the like, but I sometimes find it a bit hard to figure out where I should look for discussion about HTML and the HTML DOM because it's spread out over several lists which don't seem like they have clear boundaries. Has anyone written up an explanation of where to look for what? -- Brian
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote: > On 3 February 2010 19:23, Oliver Hunt wrote: >>> 1. Support more length specifiers for the width and height of a >>> canvas(%, em, etc.). >> >> This doesn't really make sense for the backing buffer as it is logically >> defined in terms of pixel. > > The layout engine would decide how many pixels big it is, in exactly > the same way that it decides how big to draw a image that has width > specified in non-pixel units. But that's css scaling the image, which is what currently happens with canvas: the natural width/height of the canvas is specified and is used as the default css size. >> >>> 3. CSS size specifiers resize rather than scale the canvas. I.e. it >>> should always be that 1 unit = 1 pixel initially. >> This would break content > > On 3 February 2010 18:07, Boris Zbarsky wrote: >> #3 would break existing canvas content. > > True, but: > > a) Otherwise width:100% in CSS and width="100%" in HTML would have > different meanings. Confusing! width="100%" makes no sense for canvas as it means you're no longer specifying the size of the backing buffer, which is inherently pixel based. > b) Nobody uses it currently anyway - there's no content to break! I'm > not exaggerating - look through canvasdemos.com and I bet you won't Because canvasdemos.com is the only site in the world that uses canvas. > find a single case where the canvas is sized using CSS, for the very > reasons I have given, specifically: > c) It's slow, and looks rubbish. This sounds like you want SVG not canvas -- by definition canvas is a bitmap, scaling behaviour is identical to scaling of an image. > > I suppose an alternative might be to have some way of retrieving the > true size of the canvas, then you could do something like: > >canvas.width = canvas.trueWidthInPixels; > >> #2 would work if all elements supported onresize (as has been proposed), >> right? >> >> Given that, a resize handler could simply reset the canvas width/height >> attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? >> >> Hence my question: what use cases here would not be covered simply by having >> a general resize event on all elements? > > Well, yes it would be good to have onresize for all elements. But you > still need to add width="...%" support to the canvas tag otherwise it > will never *be* resized, so you couldn't achieve #1 with #2. I may > have misunderstood you here. The onresize event would fire on the css size changing, not the canvas resolution changing -- size != resolution. --Oliver
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote: > On 3 February 2010 19:23, Oliver Hunt wrote: >>> 1. Support more length specifiers for the width and height of a >>> canvas(%, em, etc.). >> >> This doesn't really make sense for the backing buffer as it is logically >> defined in terms of pixel. > > The layout engine would decide how many pixels big it is, in exactly > the same way that it decides how big to draw a image that has width > specified in non-pixel units. But that's css scaling the image, which is what currently happens with canvas: the natural width/height of the canvas is specified and is used as the default css size. >> >>> 3. CSS size specifiers resize rather than scale the canvas. I.e. it >>> should always be that 1 unit = 1 pixel initially. >> This would break content > > On 3 February 2010 18:07, Boris Zbarsky wrote: >> #3 would break existing canvas content. > > True, but: > > a) Otherwise width:100% in CSS and width="100%" in HTML would have > different meanings. Confusing! width="100%" makes no sense for canvas as it means you're no longer specifying the size of the backing buffer, which is inherently pixel based. > b) Nobody uses it currently anyway - there's no content to break! I'm > not exaggerating - look through canvasdemos.com and I bet you won't Because canvasdemos.com is the only site in the world that uses canvas. > find a single case where the canvas is sized using CSS, for the very > reasons I have given, specifically: > c) It's slow, and looks rubbish. This sounds like you want SVG not canvas -- by definition canvas is a bitmap, scaling behaviour is identical to scaling of an image. > > I suppose an alternative might be to have some way of retrieving the > true size of the canvas, then you could do something like: > >canvas.width = canvas.trueWidthInPixels; > >> #2 would work if all elements supported onresize (as has been proposed), >> right? >> >> Given that, a resize handler could simply reset the canvas width/height >> attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? >> >> Hence my question: what use cases here would not be covered simply by having >> a general resize event on all elements? > > Well, yes it would be good to have onresize for all elements. But you > still need to add width="...%" support to the canvas tag otherwise it > will never *be* resized, so you couldn't achieve #1 with #2. I may > have misunderstood you here. The onresize event would fire on the css size changing, not the canvas resolution changing -- size != resolution. --Oliver
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 2:54 PM, Tim Hutt wrote: a) Otherwise width:100% in CSS and width="100%" in HTML would have different meanings. Confusing! I'm not suggesting that. I'm saying we keep supporting only integers in the width attribute and if you put width:100% in your CSS and the canvas resizes you can do whatever you want (change the width attribute or not, whatever you want). b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't find a single case where the canvas is sized using CSS And no UA stylesheets? No user stylesheets? No non-demo things actually using canvas for something? I actually have a hard time believing this, honestly. c) It's slow, and looks rubbish. While true, repainting the whole canvas from scratch on resize is not likely to be faster. And will look like rubbish by default (as in, look blank) unless the author writes script to make it otherwise. If the author is writing such script it's two extra line to set the canvas size too. I suppose an alternative might be to have some way of retrieving the true size of the canvas Like getBoundingClientRect()? canvas.width = canvas.trueWidthInPixels; Yep. canvas.width = canvas.getBoundingClientRect().width; Well, yes it would be good to have onresize for all elements. Which is why it's being worked on anyway. But you still need to add width="...%" support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here. You put the % sizing in your CSS and reset the canvas width/height attributes if you want to. -Boris
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 19:23, Oliver Hunt wrote: >> 1. Support more length specifiers for the width and height of a >> canvas(%, em, etc.). > > This doesn't really make sense for the backing buffer as it is logically > defined in terms of pixel. The layout engine would decide how many pixels big it is, in exactly the same way that it decides how big to draw a image that has width specified in non-pixel units. >> 2. Add an onresize event to the canvas tag. When the canvas is resized >> it is reset and this event is fired. > We actually need this for webgl as well. > >> 3. CSS size specifiers resize rather than scale the canvas. I.e. it >> should always be that 1 unit = 1 pixel initially. > This would break content On 3 February 2010 18:07, Boris Zbarsky wrote: > #3 would break existing canvas content. True, but: a) Otherwise width:100% in CSS and width="100%" in HTML would have different meanings. Confusing! b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't find a single case where the canvas is sized using CSS, for the very reasons I have given, specifically: c) It's slow, and looks rubbish. I suppose an alternative might be to have some way of retrieving the true size of the canvas, then you could do something like: canvas.width = canvas.trueWidthInPixels; > #2 would work if all elements supported onresize (as has been proposed), > right? > > Given that, a resize handler could simply reset the canvas width/height > attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? > > Hence my question: what use cases here would not be covered simply by having > a general resize event on all elements? Well, yes it would be good to have onresize for all elements. But you still need to add width="...%" support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here.
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 10:01 AM, Tim Hutt wrote: > On 3 February 2010 17:45, Boris Zbarsky wrote: >> On 2/3/10 12:22 PM, Tim Hutt wrote: >>> >>> Yes it should be cleared and there should be a oncanvasresize() callback. >> >> What uses cases does this cover that are not covered by a general resize >> event? > > Good point, it would be better to call it 'onresize' for consistency. > So my revised suggestion is: > > 1. Support more length specifiers for the width and height of a > canvas(%, em, etc.). This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel. > 2. Add an onresize event to the canvas tag. When the canvas is resized > it is reset and this event is fired. We actually need this for webgl as well. > 3. CSS size specifiers resize rather than scale the canvas. I.e. it > should always be that 1 unit = 1 pixel initially. This would break content
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 17:45, Boris Zbarsky wrote: > On 2/3/10 12:22 PM, Tim Hutt wrote: >> >> Yes it should be cleared and there should be a oncanvasresize() callback. > > What uses cases does this cover that are not covered by a general resize > event? Good point, it would be better to call it 'onresize' for consistency. So my revised suggestion is: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). 2. Add an onresize event to the canvas tag. When the canvas is resized it is reset and this event is fired. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially.
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 1:01 PM, Tim Hutt wrote: Good point, it would be better to call it 'onresize' for consistency. So my revised suggestion is: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). 2. Add an onresize event to the canvas tag. When the canvas is resized it is reset and this event is fired. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially. #3 would break existing canvas content. #2 would work if all elements supported onresize (as has been proposed), right? Given that, a resize handler could simply reset the canvas width/height attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? Hence my question: what use cases here would not be covered simply by having a general resize event on all elements? -Boris
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 12:22 PM, Tim Hutt wrote: Yes it should be cleared and there should be a oncanvasresize() callback. What uses cases does this cover that are not covered by a general resize event? -Boris
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 16:50, Simon Fraser 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
Re: [whatwg] Canvas size and double buffering.
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. >> 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? At least in Gecko, run-to-completion > means that while you script is running the canvas won't be painted. What UAs > are you seeing flicker in, and under what circumstances? Same with WebKit. As long as you clear and redraw at the same time, there should not be flicker. Simon
Re: [whatwg] Canvas size and double buffering.
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? 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? At least in Gecko, run-to-completion means that while you script is running the canvas won't be painted. What UAs are you seeing flicker in, and under what circumstances? -Boris
