[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Behavior of WebGL canvas when it can't make abackbuffer of the requested size?

On Wed, Sep 22, 2010 at 10:51 AM, Rémi Arnaud <jsremi@gmail.com> wrote:
This reminds me of a feature we used in Performer to provide load management when rendering was limited by the pixel fill. We dynamically changed the resolution of the rendering, and change the image scaling at each frame, so the final image was always full screen while the size of the image generated by OpenGL would be adjusted to maintain real-time frame rate.
I don't not know if changing the scale dynamically on the canvas is possible but that would be useful for maintaining an interractive frame rate regardless of the capabilities of the graphic hardware and the final resolution (provided the hardware has built-in scaling)

That's possible but it should be up to the app, not WebGL.

I've been thinking about adding that to some of the WebGL demos created recently. They are currently hardcoded to render at 1024x1024 but I can check the frame rate and increase the resolution if the display size is larger.  I set the resolution to 4096x1024 for this


- Remi

-----Original Message-----
From: Vladimir Vukicevic <vladimir@mozilla.com>
Sender: owner-public_webgl@khronos.org
Date: Wed, 22 Sep 2010 00:43:56
To: Gregg Tavares (wrk)<gman@google.com>
Cc: Chris Marrin<cmarrin@apple.com>; Kenneth Russell<kbr@google.com>; public webgl<public_webgl@khronos.org>; Steve Baker<steve@sjbaker.org>
Subject: Re: [Public WebGL] Behavior of WebGL canvas when it can't make a
 backbuffer of the requested size?

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

Interesting.  I agree with this idea, but we should get this into the canvas spec as well then -- the notion that a context might set lower width/height than what was requested, but scale it up for final display.  Or would it scale it up?  Or just use a smaller than requested canvas?  If we add the the scale piece, then we'd just need to add something like actualWidth/actualHeight (or perhaps pixelWidth/pixelHeight).  At one point there was a desire to have canvas be resolution agnostic, so that, for example, the browser would be allowed to create a 2x resolution canvas for a high dpi display, managing the extra scale factor under the hood.  WebGL could just as easily create an 0.5x resolution canvas, as long as we allow the author a way to query the actual pixel dimensions.  I think that's better than just modifying the actual size of the canvas, because that's likely to mess up the page's layout as well.

At the same time, we really, really should add a setSize() call on canvas that allows setting width and height at the same time.  The current way is pretty silly if you're doing frequent resizes.

   - Vlad
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: