[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 8, 2010, at 8:17 PM, Mark Callow wrote:

> I, for one, am not prepared to sign off on something like this based on what feels like a very sketchy description and no explanation of how an application is supposed to handle this situation. Furthermore I share Cedric's concern that most authors will not handle it.
> In native GL app's I let my resize event handler deal with resizing things to whatever size the window system or user has permitted. If I understand correctly, in the WebGL case the resize events are based on the canvas size, therefore special handling is needed for this error condition. How exactly does the application handle the condition.

There is no resize event for Canvas because sizing it is synchronous. You set the width and height and the canvas is created with those dimensions. For complete handling the author would then have to make the getDrawingBufferDimensions() call and use that for viewport settings, etc.

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.

> I am already having a hard time achieving what I'd like to do regarding canvas size due to having to specify the size in pixels - an insane idea given the wide variety of displays we have to deal with.

Huh? This is the way the web works. Mobile devices have had to deal with it from day 1. There are really several choices (from an iOS perspective): 

1) The author does nothing and the scaling logic in the web browser kicks in to show the entire page scaled down or zoomed in. In this case you design like you would for a desktop browser and count on the device to scale appropriately.

2) The author specifies the page size in meta tags and writes specifically for the resolution of the device being used. This is less useful nowadays that there are at least 3 screen resolutions of iOS devices.

3) Use media queries and design several layouts in CSS for a variety of sizes. You can also use media queries from JS to change behavior based on various possible layouts.

4) Use window.innerWidth/window.innerHeight to find the current window size. On iOS devices, they are always "full-screen", so this gives you the screen size. It is actually the size inside the chrome. You can get the real screen size with window.outerWidth/window.outerHeight.

So there are plenty of tools to deal with the wide variety of mobile devices. Everything but (2) above are also viable design tools for desktop browsers.


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: