[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size?
----- Original Message -----
> So, for simplicity it seems like preserving aspect ratio would more
> often give the author the desired results. I think most authors have a
> set aspect ratio in mind when they create a canvas. For the above
> simple sequence to be effective, it should have the same aspect ratio.
> I don't think that's a requirement, but it would make author code
> simpler, I think. Otherwise, if the author cares about aspect ratio,
> he will have to examine the actual sizes and try to come up with a
> size with the desired aspect ratio that is within the size limits.
> That might lead to another resizing by the implementation, another
> examination of the resultant aspect ratio and another attempt at a
> different size. That is not only complicated, but could lead to an
> infinite loop if written poorly.
Yeah, they'd have to use getEffectiveDrawingSize()'s width/height as the aspect ratio, not canvas.width/canvas.height -- unless they did the above though, in which case they could use canvas.width/canvas.height.
> >> ...But you bring up a good point. If the author does "canvas.width
> >> =
> >> 1000; canvas.height = 500;" will the canvas get resized twice? In
> >> other words, what are our rules for when the canvas gets resized?
> >> Is
> >> there a way for us to optimize the sizing? Maybe we could delay
> >> resizing the canvas until either the size is queried, or a WebGL
> >> call
> >> is made.
> > The canvas unfortunately has to be resized twice. I've sent mail to
> > whatwg that this is really undesirable, and suggested that the
> > canvas element just get a setSize() method that would set both width
> > and height at the same time.
> I would think the implementation could optimize it as I described
> though, couldn't it? Seems like lazy resizing would not add a lot to
> each graphics call. Our implementation already has a prefix method on
> every graphics call to ensure that the GL context is set. Adding a
> check of a dirty flag seems like a reasonable addition to that logic.
Could be -- certainly possible in WebGL, much more easily than with Canvas 2D I think since the state-resetting is more complex for 2D canvas.
> > One related comment -- I think that we should clamp the canvas back
> > buffer dimensions, *but* for on-screen display we need to scale up
> > to the original requested canvas size, even if it's inefficient. I
> > think this is better than actually changing the physical layout
> > dimensions of the canvas element as well, but I could probably go
> > either way.
> Yes, of course. Gregg's 10000 x 1500 example (or whatever it was)
> would give the author a drawing buffer that was 2000 x 1500 (or 2000 x
> 300 if we maintain aspect ratio). But the drawing buffer would be
> stretched to fit a 10000 x 1500 space on the page.
This of course makes the aspect ratio computation even slightly more confusing... canvas.width/canvas.height needs to be the drawn aspect ratio, but the viewport must be set in terms of effective drawing size. No really good solution for all of this, but I think the getEffective() etc. is the simplest; now we should just decide about whether to preserve the aspect ratio or not. I don't think there's any reason *not* to, since again if someone has an explicit case they have all the tools to pick a specific exact size. We're just trying to come up with the simplest default, and preserving seems like it..
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: