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

Re: [Public WebGL] Buffer size and viewport



On Mon, Jun 7, 2010 at 10:18 AM, Alan Chaney <alan@mechnicality.com> wrote:
> 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.

I assume you were using JOGL's GLJPanel. The issue you were likely
running into with that component was that during some resizing
operations the OpenGL context was destroyed and re-created, which
generally forced the entire application to re-initialize. WebGL
specifies that the OpenGL context is preserved during resizing
operations, though it is necessary for the application to redraw.
Resizing operations will therefore be much cheaper with WebGL so you
will probably see no issue.

Note also that the HTML Canvas element only resizes in response to
explicit setting of its width and height properties in JavaScript. If
you use a CSS style to set its width to for example "100%" then the
result will be a stretched version of the fixed-size back buffer.

-Ken

> 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?
>
> Alan
>
> -----------------------------------------------------------
> 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:
>
>

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