--- Brian Paul <[EMAIL PROTECTED]> wrote:
there's no guarantee that any of them will give you a root window with particular GLX attributes. Sometimes you might get lucky.
[I've lost count of how many times this has come up over the years, BTW.]
Hmm, makes me wonder if they were xscreensaver users too ...
I think they were. I don't recall any other OpenGL applications that render into the root window.
If you'd have changed cards in your system and found this problem would you be as upset?
I would probably blame the card. However, in this case I haven't changed the card and it used to work fine. I therefore know that there is no technical reason why it shouldn't work now.
That's correct. Evidently something changed in the software somewhere - but I have no idea what. I really don't have time to investigate, much less keep replying to your messages (this may be the last time).
Or, suppose you started running your X server at a different default resolution and the GLX visuals changed.
In this case, there would at least be something in the config files or on the command line to get things working again. I actually had this with a 3Dfx Voodoo3 (16 MB) when I upgraded to XFree86 4.2. I had to reduce my screen resolution from 1280x1024 to 1024x768 to enable DRI, and yes, I was annoyed. However, now it's more like finger-pointing between the xscreensaver author and the DRI developers over whose bug it is and I'm stuck in the middle with a broken screensaver.
Well, from my point of view I've been dealing with this issue on and off for over three years. I've explained it more than enough times. I'm tired of hearing of it.
If something changes, but the new behaviour is still within specificied operational parameters, I guess I don't consider that a regression.
A concrete example of a similar user experience
happened a while back when I changed the default maximum 3D texture size in Mesa.
It was unrealistically large (I don't remember the value, maybe
1024x1024x1024) and I reduced it to a reasonable size (128x128x128 now). A user
complained that his app stopped working. It turned out he wasn't querying
GL_MAX_3D_TEXTURE_SIZE or using a proxy texture to be sure what he was trying to do
was legal.
In which case the app writer was doing something illegal. However, can you point to anything illegal or even undesirable about trying to enable DRI on the root window, *given the fact that the hardware has no problem here*?
You're mis-directing my example. The point is that in both cases, the *application* was making assumptions about the OpenGL implementation that it shouldn't.
There's nothing _illegal_ about setting up the default root window to be double-bufferd, with Z buffer, stencil, buffer, etc (i.e. "enable DRI" in your words).
However, there is something _undesirable_ about having all GLX implementations support double-buffering, Z, stencil, etc on the root window: memory utilization. Suppose when you started the X server that the root window always was double-buffered, had a Z buffer, stencil buffer, alpha channel and accumulation buffers and doing so left you with a reduced amount of texture memory, thus causing poor performance due to texture memory swapping. In that case someone would be complaining that the root window should not be configured in that manner. (Damned if we do, damned if we don't)
On some systems doing this may have no cost, on others the cost might be objectionable.
Looks like the only difference between visual 0x23
(the root visual) and 0x25 (what xscreensaver wants) is the addition of a
stencil buffer in the later. I wonder if the GL screensavers really need stencil.
I showed the definitions of both visual 0x23 and 0x25 to the screensaver author and he could not think of a reason (off the top of his head) why the stencil buffer would matter. So on the assumption that glxinfo has described both visuals fully, I am now going to dissect the xscreensaver-gl-helper application to try and discover what all the fuss is about ...
That would be helpful.
-Brian
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
