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

Re: [Public WebGL] Buffer size and viewport

Joshua Bell wrote:
Apologies in advance for the pedantic reply.

No problem, it was a pedantic question!

On Mon, Jun 7, 2010 at 8:14 AM, Alan Chaney <alan@mechnicality.com <mailto:alan@mechnicality.com>> wrote:

    Desktop GL programming frequently requires that the user sets the
    window size as part of the game/application setup. This means that
    normally the viewport can be set to (0, 0, displaybufferwidth,
    displaybufferheight). However, in a WebGL application it is likely
    to be very common that the window size will change due to use input.

The default with WebGL is to set the buffer size to that of the
canvas element and the viewport to that as well. This means that
if the window is resized to greater dimensions than the original
canvas size the display buffer must be discarded and a new buffer
initialized - this takes time.

How frequently will this occur in practice, during a user session? Is it unacceptable for your application to pause briefly responding to the resize? (e.g. due to inducing latency issues, etc?)
Are you optimizing prematurely, or do you have performance data - and if so, can you share it?
I'm raising it because I encountered problems with a OpenGL player written using JOGL. Similarly to WebGL, JOGL allocates a drawing buffer and by default makes it a power of 2 size that encloses the specified viewport. When the window was resized we were encountering problems in the application stalling whilst the (GL) buffers were reloaded. When you dealing with a desktop application it is easier to get around this by exploiting techniques such as memory mapped files. I'm evaluating similar options by using the various storage APIs that are being proposed.

As far as the "premature optimization" goes, I'm actually at this point considering options - this is a problem which I've hit before, so I think its valid to do some early investigation. Ironically, in the example I gave I had to do quite a lot of reorganization of the code after I discovered the problem, which is part of the reason why I'm considering it in this case.

As an aside, this blog (which is nothing to do with WebGL, its about MS FSX/Dx10) has some interesting points on the strategy of "make it work, then make it fast" in connection with drawing high vertex-count content - http://blogs.technet.com/b/torgo3000/archive/2007/06/01/performance-art.aspx .

Note that the underlying canvas will have a fixed buffer size as well; it may be stretched to match the window size via CSS, but changing the buffer's pixel dimensions dynamically will require script.

    One option that I can see is to make the display buffer
    considerably bigger than the canvas element - perhaps by doing
    some calculation based upon my UI layout and the underlying screen
    size and setting this value when creating the context.
    Then as the canvas is resized  I simply set the viewport size to
    match the size of the canvas element, until, of course, it exceeds
    the underlying buffer size.

Multiple monitors will make this tricky - the answer given by the window.screen.width/height will change if I move my window, and is inadequate if I stretch my window to span two monitors.
Agreed. As it happens, my focus at the moment is on "lower end" systems where multiple monitors are rare (although I'm writing this to you on a dual monitor machine...)

    Does anyone have any feel to the relationship between viewport
    size and buffer size and performance? In other words, if I
    allocate a larger buffer than I actually display in the view port,
    is this likely to cause a significant performance issue?

Despite the skepticism, I'm interested in the answers as well. My gut would be that allocating extra space would not be worth it, but I'd love to hear from implementers if it would be a performance problem.

Yes, part of the problem with "just trying it out" is that I only have a very limited set of browser/graphics card combinations at the moment, and I was hoping that the implementors might have some insight into the more general issues and likely performance trends (eg. mobile) I think WebGL has the opportunity to play a significant part in mobile devices if/when mobile WebGL compatible browsers become available. I was going to raise this issue in a separate thread. I realize that the issue of resizing is not likely to be so relevant on a mobile platforms.

On a related note: games often run full-screen at a resolution lower than the "native" resolution of the device/monitor (and/or what the OS is normally set to) to find the sweet spot between visual fidelity and frame rate.

Agreed however I think that WebGL will be used for a lot more things than traditional games and such apps. may well need/use resizeable canvas elements.
With WebGL, the JS engine will be a limiting factor for now at least - more so than the pixel pipeline. I would naively expect, going full-screen (possibly via an HTML5-or-later API as discussed here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024872.html) at "native" resolution would not incur a frame rate hit. I'm curious if this has been explored, and/or if approaches have been discussed. Anyone have any data or pointers to previous discussions?

At the moment I'm seeing the biggest issues of JS connected with its inability to manipulate arrays of non-JS types efficiently. At least for the applications that I'm the most interested in, once the VBOs and FBOs have been created there is little direct JS activity. I understand that there are plans afoot to propose new standards to address problems connected with array manipulation.

It's an issue my company runs into even with desktop GL; we have extremely high poly user-generated content but typically run in a window that users maximize, rather than running full-screen at reduced resolution, which induces a significant frame rate hit on lower end (CPU+GPU) hardware.

Do you know why your users do this?


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: