[GRASS-dev] nviz python thoughts

Glynn Clements glynn at gclements.plus.com
Sun Dec 21 21:04:39 EST 2008


William Kyngesburye wrote:

> >> ... Some sample code from Apple - it's about using surface textures,
> >> but the window parts could be useful:
> >
> > Using OpenGL in a window should be taken care of by wxGLCanvas. It's
> > getting off-screen contexts which we (probably) have to do ourselves.
> >
> > The situation is the same with the existing nviz; Togl provides a
> > canvas on which OpenGL can be used. The only glX/wgl/agl functions
> > outside of Togl are the code in do_zoom.c to get an off-screen context
> > for saving output to files.
> 
> I guess I'm missing something here.  I understand about the offscreen  
> part, so where does the window come in in render.c?  Is it a hidden  
> window, just so we can get the context?

There's no inherent need for a window. In the X version, the windowId
field is actually a GLXPixmap. The only reference to an actual window
is to the root window (XCreatePixmap takes a window parameter which it
uses to determine the screen on which to create the pixmap).

> >> Looks like mac_win is just a placeholder here.  For now, comment this
> >> line and have Nviz_make_current_render_window return 0 for  
> >> OPENGL_AQUA?
> >
> > In that case, just:
> >
> >     /* TODO: mac_win */
> > -    aglMakeCurrent((AGLDrawable) mac_win, rwin->contextId);
> > +    aglMakeCurrent((AGLDrawable) 0, rwin->contextId);
> >
> > should get it to compile (which is all we're after for now).
> 
> 
> Should it return 0, just to be nice?  presumably, nviz_cmd would fail  
> gracefully if the render.c functions return a failure, but would it do  
> so on success but with a nonexistent context?

Who knows? nviz_cmd won't work unless you can figure out how to create
something to render into. Failing with a segfault probably isn't any
worse than failing to compile.

> Anyways, the online API docs that we found way back when to get the  
> function names seems to have been wrong.  Strangely, render.c compiles  
> with the wrong names, but doesn't link:
> 
> Undefined symbols:
>    "_aglChoosePixelFmt", referenced from:
>        _Nviz_create_render_window in render.o
>    "_aglCreateAGLPixmap", referenced from:
>        _Nviz_create_render_window in render.o
>    "_aglMakeCurrent", referenced from:
>        _Nviz_make_current_render_window in render.o
>    "_aglDestroyAGLPixmap", referenced from:
>        _Nviz_destroy_render_window in render.o
> 
> Indeed, these are not in the AGL headers.  What I can find is:
> 
> extern AGLPixelFormat aglChoosePixelFormat(const AGLDevice *gdevs,  
> GLint ndev, const GLint *attribs);
> 
> extern GLboolean aglSetCurrentContext(AGLContext ctx);
> (I didn't see any form of "make current", with a context AND display/ 
> window parameters)
> 
> There don't appear to be any pixmap functions, but there are pbuffer  
> functions.
> 
> Looks like nviz.h has the right names for types in the render_window  
> struct.

Odd. I thought that it might have been a classic-vs-OSX issue, but
none of those names appear in togl.c (which supports both) either.

A bit more Googling produces results which include the minutes of an
OpenGL ARB meeting in 1995, Brian Paul's course from SIGGRAPH '97, and
references to the red book (which I have, dated 1997, and which lists
the non-existent functions in Appendix C).

Oh, I also found a reference which indicated that Maple used to ship
Mesa (with aglChoosePixelFmt) with the Mac version, and a CVS-web page
for Mesa where aglChoosePixelFormat() uses "aglChoosePixelFmt" in an
error message.

My guess is that the agl API was still provisional back when the red
book got printed, and that's what Mesa used, and between them they
comprised the de facto standard which persisted until Macs started
getting 3D hardware. At which point, it would have been necessary for
Apple to formalise the API, which may have required changes in order
to fully integrate with the windowing system.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list