[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 22 Jan 2008 20:53:57 +0100
Thunderbird 22.214.171.124 (X11/20071022)
It's barely a rework, I didn't change the structure of the code, I just
tried to fix some issues so that it would work for me. I tried to get
some idea how the gnustep-backends work, but didn't come really far. So
I still fear I screwed up something without knowing.
thank you for that rework.
I just submitted these changes to SVN, with a
slight bit of rework and reformatting.
What I don't like about the current code (not just your changes) is that
it is still unclear to me, whether the difference between the minor
releases of GLX is a compile time or run time difference.
It's a run time difference since it depends on the driver.
The new functions fo glx 1.3 are just those using GLXFBConfig
Are all the
new functions really present in a GLX version < 1.3? If not, then we
should protect these calls in the code with #ifdefs.
Also the usage of the union in pixel format looks strange, we need to
read what was set, not what suits the current GLX version.
Could you explain in detail, please?
versions wont change during the runtime of the program, still it looks
wrong. This is why I moved all of the reference to the union into the
separate file. A next step would be to clean up the usage here.
As you are now creating a separate drawable, isn't the deallocation of
that drawable needed? I put in a FIXME, where I think this call is
I'm not sure about that. I did all this work because I wasn't able to
get an opengl pixelformat and context with an alpha channel, stencil
buffer, and so on. I looks like the cause was the X Window's colormap
not being able to support the pixelformat. Maybe we have to allocate a
separate drawable for older glx versions too, to be able to support all
Again it is only needed for the newer GLX release.
Yeah, all of this stuff looks like it was done rather hasty back in
2002, and I think the X-Server opengl drivers weren't rather cooperative
at that time ( that doesn't mean they are cooperative today). I still
need to add some pixelformat stuff (multisample support) and will
continue to work on this code. I'm using GNUstep for my diploma thesis,
and I have written a lot of code already, but I didn't the test
GNUstep's opengl support really well until recently. Basically I HAD to
fix this, otherwise I would have lost more than 2 month of work :)
To me all these files look like work in progress, hopefully you keep on
working on them.
Keep up your good work on GNUstep :)
Thomas Gamper wrote:
Recently I was using NSOpenGLView and fixed a couple of bugs in
gnustep-back 0.12.0 ( I believe newer versions have the same issues):
- XGGLPixelFormat handling was confusing glx parameters, since glx 1.3
has some different parameters than earlier versions of glx
- XGGLContext did not create the rendering context, the x window, and
the glx window with the same Visual
- XGGLContext did not create a colormap for the x window (which has to
use the same Visual too)
The attached files fix this issues. I tried to follow the gnustep
coding style but I am not sure if I succeeded :)
Please let me know if there are any change requests.
I am not subscribed to the list, so please CC me.
- NSOpenGL, Thomas Gamper, 2008/01/19
- Re: NSOpenGL, Fred Kiefer, 2008/01/21
- Re: NSOpenGL,
Thomas Gamper <=