[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 <firstname.lastname@example.org
<mailto:email@example.com>> wrote: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.
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?
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
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...)
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.
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.
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.
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
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
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
Do you know why your users do this?
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: