[Mesa-dev] [RFC] Haiku viewport / framebuffer invalidation
brianp at vmware.com
Tue Nov 12 09:41:38 PST 2013
On 11/11/2013 10:29 AM, Alexander von Gluck IV wrote:
> I've been banging my head against a wall for a while now on this.
> So the Haiku applications that call glViewport(.. for window
> resizes,etc never actually execute the Driver's Viewport call.
> (aka ctx->Driver.Viewport:
> I found "void GLAPIENTRY _mesa_Viewport" in viewport.c, however I
> have a feeling this never gets called as softpipe is a Gallium
> driver not a Mesa driver.
> I know there are stamp's in the st_context and st_framebuffer, however
> ++'ing them on a window resize doesn't seem to solve the issue.
> Our libGL actually is aware of window resizes, so I have a fix in that
> manually calls the viewport calls on resize.. however I don't think
> this is a good long term fix as the viewport is always forced to the
> size of the window (which isn't correct was far as I know)
The whole point of drivers hooking into glViewport is to try to detect
window resizes so that the driver can reallocate
back/depth/stencil/accum buffers to match the window size.
This goes back to the original Xlib driver. There, we have no
event-receiving mechanism so the Xlib driver never saw X's
ConfigureNotify messages. So we didn't know when to reallocate the
The solution was to hook into glViewport, which *most* GL applications
wind up calling when the window size changes. We could have also hooked
into glClear, but that would have meant more calls to XGetGeometry().
Anyway, if the Haiku driver is aware of window resizes, as you said,
maybe you don't need to worry about glViewport at all.
The viewport should be initialized to the size of the window once when
the context is bound to a surface for the first time. Thereafter, it's
up to the app to call glViewport as needed.
More information about the mesa-dev