[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 Nov 7, 2010, at 6:43 PM, Cedric Vivier wrote:

> On Sat, Nov 6, 2010 at 06:12,  <tomi.aarnio@nokia.com> wrote:
>> FWIW, I think I'd want canvas resizing to throw an exception if it fails. If there's no explicit error, it'll be easy to think that everything is fine, then later bump into some weird artifacts with no obvious cause.
>> 
>> If we let implementations clamp the canvas arbitrarily, then what if the app is trying to create a texture that's too large - would it be OK to clamp that, too? (Sure, that's about creating a new object vs. resizing an existing one, but it's a reasonable analogy nonetheless.)
> 
> If I understood correctly, the proposal is to also resize the back
> buffer at new context creation (provided the host canvas is large
> enough), which makes it a very reasonable analogy indeed.
> 
> I'm not sure how silently resizing a requested 10,000x500 canvas into
> a 2048x500 will help in most cases, the rendering could be look very
> different than what it was intended to be, nonwithstanding plenty of
> other issues that may arise with some calculations, especially in
> highly interactive WebGL content, because developer likely won't test
> such aspect ratios.
> For instance, outside of pure WebGL related issues, such a resize may
> significantly change how mouse controls work if not taken into account
> ... typically relative mouse motion/position is given related to
> canvas dimensions [manually or by libraries such as jQuery]. Even so,
> handling it might make the application unusable anyways because of the
> great loss in horizontal precision in rendering.

Such a scenario would require the author to realize that the buffer is not the requested size and adapt the code accordingly. I don't think that's a bad scenario.


-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: