I've been looking around and experimenting with the Stellarium code base a bit.
I've succeeded in separating some of the GL initialization code, results can be seen on this branch: https://code.launchpad.net/~kiithsacmp/stellarium/glexperiment (I'm aware that all code is in headers - most of it will be thrown away before it's separated into .cpp files) The changes are in the following revisions: http://bazaar.launchpad.net/~kiithsacmp/stellarium/glexperiment/revision/5275 http://bazaar.launchpad.net/~kiithsacmp/stellarium/glexperiment/revision/5274 Originally I tried to separate GL from the rest of Stellarium as well as Qt code, but I noticed that it's very tightly bound with Qt. Basically the only ways to separate Qt and GL code would be to a) use a hacky implementation completely avoiding QGL or b) wrapping most QGL classes. So I've concluded it's not a good idea. (As a side note, some of the QGL functionality is quite useful - although I'm wary of them keeping up with new GL versions and not removing support for old ones (as GL1 in Qt5)) What I'm proposing now is a few API-independent base interfaces (Renderer, VertexBuffer, etc - whatever turns out to be needed) with implementations, based on Qt-with-GL. E.g. QGLRenderer (shared code) extended by QGL1Renderer, QGL2Renderer, etc. The interfaces themselves would be completely independent of GL, and, if possible, Qt. I.e. there would still be space for a SWRenderer or HackyGLButNotUsingQGLRenderer. An important benefit compared to the current implementation would be ability to choose a backend at runtime (maybe even fallback? E.g. GL2 fails - try GL1 - fails - try SW) Also, no global state (except on the side of Qt/GL themselves), and especially no direct usage of GL anywhere, which should make it both easier to debug and to optimize. The vertex data would be managed by the backend (passed to it by the user code that can generate/load it). User code would only use flyweight objects to reference the data. Added bonus to that would be that the backend could control draw order of transparent objects (I'm not proposing to do that - not sure if I can in time - but it'd be manageable in future). Various small vertex data like single points and lines could be batched and drawn together. (Again, not proposing to do that - but can be implemented in backend once refactored). Ferdinand Majerech ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
