Hi, 2008/6/15 Glynn Clements <[EMAIL PROTECTED]>:
> BTW, are you planning on cleaning up the OGSF library at all? yes, I would like also to clean up the OGSF library. I don't know the library well enough at this time. I will appreciate any notes and suggestions... Thanks for them. Martin > One of its main structural problems is that it has a fair amount of > "private" state (e.g. lighting), and the management of that state > (including synchronisation with OpenGL's state) is, to put it mildly, > rather "ad hoc". > > This can be a significant problem in two areas: > > 1. If you want to deal with multiple views, there is only one set of > state variables, so you would need to explicitly re-initialise > everything when switching between views. > > 2. If you want to replicate a view onto a different GLX (etc) context, > there's no convenient way to do so. > > IOW, for anything other than a single view and a single context, the > application must keep its own copy of the state, in addition to the > copies held by OGSF and OpenGL itself. > > One option is to just rip out all of OGSF's internal state, so the > code would render with the current OpenGL settings. Applications would > either call OpenGL functions directly, or call OGSF wrappers which > pass the data directly to OpenGL *without* keeping a private copy > around. > > Another option would be to formalise the state management, ensuring > that every "set" function has a corresponding "get" function, and with > clear mechanisms for switching between different contexts, and pushing > the internal state out to OpenGL. > > -- > Glynn Clements <[EMAIL PROTECTED]> > -- Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa * _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
