Re: opengl and gephex

Martin Bayer wrote:

>Why do we need a single gl_core interface?
>
>+ portability by hiding the glx, wgl, agl subsystem
>+ state cache optimization
>+ resource management
>  
>
Don't forget that this also enables a central extension management (the 
core can query all extensions and try to offer fallback solution if 
certain extensions are not supported by the graphics card and such a 
fallback solution exists - all being hidden from the actual core user). 
This is just convenience though but for the actual work with such a core 
it could simplify things a lot for the plugin coder (doesn't have to 
query extensions, the library can offer a clean handling of fallbacks 
and/or assemble a minimum subset of extensions that have to be 
supported). This is another +.

>- existing gl code must be changed to redirect gl* calls
>  
>
This - weighs the least IMHO (the least +weighing is state cache 
optimization probably). The core interface should closely match the gl.h 
one thus making it easy to do a simple query/replace on most of the 
code. Also: Not all gl functions are being wrapped - only those that 
"leave a state changed" on the card (in the broadest sense :) ).

>- lots of delegation code needs to be written
>  
>
I say this is not too big of a deal also - the code is straight forward 
and easy to write.

>[...]
>I favour (3) for gephex 0.4 and (4) for gephex 0.5. The call syntax in
>the unit code is the same and the gl_core stuff can be reused without
>changes.
>  
>
I agree. (3) seems to be the most easy solution to implement in 0.4 and 
(4) the cleanest overall solution.

There's one final problem with (3) though...initialization of the core 
requires a window handle (at least on windows) so it's dependent to an 
output window to some extent. The easiest solution i can think of for 
this is to just make the frboutmodule link to that library too....meaning:
- if there's no output, the first module to use the core will call 
initialize (ctor). This initializing function will create a (hidden) 
window to work with. The frboutmodule will just take the window handle 
from there once initialized the first time.
- if there's an output, it will call initialize itself thus creating a 
renderwindow and setting up the core with this.

I'm not familiar with the linux/mac side...are there any similar 
requirements?

regards,
-coma


--
------------------------ [ SECURITY NOTICE ] ------------------------
To: [email protected].
For your security, [email protected]
digitally signed this message on 13 June 2005 at 15:30:29 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQB4BwAAfAB8AAAAAQAAAJWmrUJ4BwAAJgMAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MY7VCtB7Y/zngzuzKgyZmTbj/5HlCnzX0GHXxZWUfFgxWo3DU2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------