XGL (formerly WholeGL)

OpenGL OpenGL: Advanced Coding
1

Version 0.5-dev is out, if anyone could test it on Win32, it would be great

Changes since 0.4 include a transparent OpenGL states manager: you use glEnable, glDisable, glIsEnabled, but behind your back XGL functions are used to avoid redundant states changes…

Thanks,
Julien.

2

Originally posted by deepmind:
Version 0.5-dev is out, if anyone could test it on Win32, it would be great

Changes since 0.4 include a transparent OpenGL states manager: you use glEnable, glDisable, glIsEnabled, but behind your back XGL functions are used to avoid redundant states changes…

What if the driver already does that? Sounds like a valid optimization but then again, it may be implemented in most drivers already ???

3

Originally posted by zeckensack:
What if the driver already does that? Sounds like a valid optimization but then again, it may be implemented in most drivers already ???

I think I will introduce XGLHint() in the final 0.5 release, so it will be more flexible…

e.g.: XGLHint(XGL_STATES_MANAGER);

Thanks,
Julien.

4

Originally posted by zeckensack:
What if the driver already does that? Sounds like a valid optimization but then again, it may be implemented in most drivers already ???

Nope.

[This message has been edited by richardve (edited 03-15-2002).]

5

Regarding the caching of OpenGL states, I suppose you’ll have the same problem than me with the use of display list. Say I have a display list that disables culling (uiList):

glEnable(GL_CULL_FACE);
glCallList(uiList);
glEnable(GL_CULL_FACE);

Your code has no way to know that calling uiList will disable culling. Hence when you call glEnable the second time, your routine will not actually change the state because it thinks that the culling is already enabled.

That kind of problem can be avoided by carefully planning your rendering loop but I thought I’d mention the problem anyway: chances are people will send you bug report on the caching not working properly while it is just a “logic” problem in their app.

You should probably have a note about that in your docs (sorry if it is already there, I am going to check !).

Regards.

Eric

6

Originally posted by Eric:
You should probably have a note about that in your docs (sorry if it is already there, I am going to check !).

There is virtually no doc at all for the moment

Thanks, I think it would be the only case where XGLSynchronizeStates() will be useful. I do not use display lists at all, so I would not have find this by myself…

Julien.

7

Originally posted by richardve:
Nope.

Ohh, pity

8

Actually, while thinking about it: you could intercept the glNewList command and keep track of all state changes in the display list. Then when glCallList is used, you actually have the necessary information to update the states kept by your manager.

Might not be very easy when using nested display lists… Might also be a lot of work for nothing !

Regards.

Eric