Re: [whatwg] Canvas size and double buffering.

2010-02-04 Thread Robert O'Callahan
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.

2010-02-04 Thread Brian Campbell
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.

2010-02-04 Thread Nikita Popov
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.

2010-02-04 Thread Nikita Popov

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.

2010-02-03 Thread Robert O'Callahan
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.

2010-02-03 Thread Robert O'Callahan
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.

2010-02-03 Thread Robert O'Callahan
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.

2010-02-03 Thread Brian Campbell
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.

2010-02-03 Thread Boris Zbarsky

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.

2010-02-03 Thread 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.


Re: [whatwg] Canvas size and double buffering.

2010-02-03 Thread Boris Zbarsky

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.

2010-02-03 Thread Tim Hutt
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.

2010-02-03 Thread Boris Zbarsky

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.

2010-02-03 Thread Brian Campbell
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.

2010-02-03 Thread Oliver Hunt

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.

2010-02-03 Thread Oliver Hunt

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.

2010-02-03 Thread Boris Zbarsky

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.

2010-02-03 Thread Tim Hutt
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.

2010-02-03 Thread Oliver Hunt

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.

2010-02-03 Thread Tim Hutt
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.

2010-02-03 Thread Boris Zbarsky

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.

2010-02-03 Thread Boris Zbarsky

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.

2010-02-03 Thread Tim Hutt
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.

2010-02-03 Thread Simon Fraser
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.

2010-02-03 Thread Boris Zbarsky

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


[whatwg] Canvas size and double buffering.

2010-02-03 Thread Tim Hutt
Hi, I've been trying to use the HTML5 canvas to implement a slippy
map. It works ( http://concentriclivers.com/ ), but there were a
couple of issues I had for which there seems to be no good solution.

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.

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.

As for solutions I propose:

1. Allow width=20%, 3em, and so on. The pixel size is then decided by
the device, but it's very easy to query it in javascript (all the
examples I've seen do this anyway). CSS sizes should definitely resize
the canvas rather than scale it.

2. Add a .flipBuffers() method, and either make all canvases double
buffered, or add a 'doublebuffered' tag attribute (which would be more
backwards compatible).

Tim