[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?





On Tue, Sep 21, 2010 at 8:10 PM, Steve Baker <steve@sjbaker.org> wrote:
Gregg Tavares (wrk) wrote:
>
>
> On Tue, Sep 21, 2010 at 6:49 PM, Steve Baker <steve@sjbaker.org
> <mailto:steve@sjbaker.org>> wrote:
>
>     Chris Marrin wrote:
>     > On Sep 21, 2010, at 11:53 AM, Gregg Tavares (wrk) wrote:
>     >
>     >
>     >> Re thinking about this, getting a lost context for trying to
>     set the canvas too large seems bad because there is no easy
>     recovery from lost context.
>     >>
>     >> In other words, if we had some kind of error (say, an
>     exception?) I could do this
>     >>
>     >> try {
>     >>   canvas.width = largeWidth;
>     >>   canvas.height = largeHeight;
>     >> } catch (e) {
>     >>   canvas.width = smallWidthOrPreviousWidth;
>     >>   canvas.height = smallHeightOrPreviousHeight;
>     >> }
>     >>
>     >> But as it is, if I get lost context I now have to reload all my
>     resources. That doesn't seem desirable
>     >>
>     >
>     > Yeah, I think we really need a WebGL way of knowing the maximum
>     dimensions of the canvas. Alternatively, we could always allow the
>     setting of width and height to succeed, but internally use a
>     smaller size. We could adjust the setViewport params to account
>     for this size difference. So an author would never have to do
>     anything. Their image might just be more pixelated on some
>     hardware than on others. We'd still need provide actual size attrs
>     from the WebGL context and maybe even max size, so the author has
>     all the tools to make the right decisions. But doing it this way
>     makes it so authors never have to worry about it.
>     >
>     That's a bit worrysome though - there are quite a few post-effect type
>     algorithms that need to know the actual pixel resolution.  What about
>     programs that read pixels back from the frame buffer?   Hiding the
>     true
>     rez behind the scenes might be a major problem.
>
>     If you're going to magically "make it work" for the common cases,
>     there
>     still needs to be a way to query what you've actually got.
>
>
> It seems easy to query what you actually have if you always use
> canvas.width and canvas.height. I pretty much do that everywhere now.
>
> I suppose programs that don't do this would break but fortunately the
> fix is easy where if instead you get lost context the fix is quite a
> lot of work, possibly refactoring all your code if you haven't already
> planned for it.
I'd have no problem with a solution that simply gave you the best it
could manage - and allowed you to set things up accordingly (my current
code uses canvas.width/height to allow a dynamically resized canvas).
What concerns me about Chris' suggestion above is that "We could adjust
the setViewport params to account for this size difference."   Wouldn't
that break programs that check canvas.width/height and set their
viewport accordingly?

The implication is that WebGL would try to disguise the fact that you
have lower resolution than you asked for...but perhaps I misunderstand
what is being proposed.

Agreed. WebGL can not set the viewport for you because it doesn't know what you're using it for. You could be currently bound to a FBO when you change the canvas. We went over this before with gl.viewport

so yea, I think the canvas should just pick the largest size it can up to the size you ask for. You then check canvas.width and canvas.height to see what size you actually got.  

If you don't check it's no worse than now where most likely something bad would happen. If you forget to check and someone reports a bug in your app it will be super easy to fix your app.




 

 -- Steve