[GRASS-dev] [SoC Report] 2.5/3D visualization tool for wxPython GRASS GUI

[Martin Landa]

Hi,

2008/6/15 Glynn Clements <glynn at gclements.plus.com>:

> 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 <glynn at gclements.plus.com>
>



-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *