On Wed, Jun 04, 2003 at 05:35:55PM +0100, Matt Sealey wrote: | > The point is that people *almost always* call glViewport when they get a | > window resize event. That gives the driver a chance to ask the system | > what the window size is. | | Aiiee.. I already said I don't know what the window size is at all. There | is no point where Mesa CAN be told what the window size is. It never talks | to find out either. Back to Square One!
Just following up Ian's comment: That's what I was trying to explain in a previous message -- glViewport just defines a transformation, not the boundaries of the rendering region. The actual region that can be drawn depends on all the ways in which clipping can occur (view volume, user clip, scissor, pixel ownership, etc.) as well as the transformations. An application can specify glViewport dimensions that are smaller than the window (this is fairly common) or larger than the window (this is rare, but not unheard-of -- it usually happens when an application is trying to preserve a fixed image aspect ratio but allow the user to resize windows arbitrarily). | > If the size is different than the last time, it can resize its internal | > buffers. It doesn't just use the values supplied by glViewport. | | So what values DOES it use? In systems that don't have hardware support or a low-level software synchronization mechanism like DRI provides, it needs to query some other entity that knows the values. Usually the window system. | Someone explain to me why something as supposedly abstract as OpenGL | needs to be so deeply embedded into the host's windowing system? That depends on the window system implementation. Some of them are designed to support direct renderers, and others aren't. Allen ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
