> <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.