On Sat, Apr 28, 2012 at 22:37, No Idea <[email protected]> wrote: >> The impact of using point stars was not very important but there was >> one on small devices like the Nokia N900. > > I'd like to refactor with a minimal set of features first, and only then look > into that. Any such slowdown might be caused by 2 triangles being drawn > on the GPU instead of a point sprite, but just as likely might be caused > by the code that generates the triangles, which could be optimizable, > or a part of it could be moved onto the GPU. Either way, I'd like to > consult a profiler before doing any of that. > > Also, if only mobile devices are affected, it might be possible to make > any needed optimizations for the GLES backend, if that will make sense.
I think the GL2 renderer should be also GLES compatible. GLES is just a subset of GL2 (which is an abusive name for all GL implementation which supports shaders) >> If understand well, you plan to replace the useShader boolean by a >> mechanism of inheritance. Although this is fine for generic rendering >> operations currently in StelPainter, I am a bit wondering what you >> plan to do with the shader code which in some case is very specialized >> (like rendering stars). Do you also plan to move it in a generic class >> like StelQGL2Renderer and an equivalent method using GL1 in >> StelQGL2Renderer? >> >> If you do that the StelXRenderer classes will end up containing a >> bunch of unrelated rendering routines like rendering of stars, >> atmosphere etc.. which more naturally fit into the dedicated >> StelSkyDrawer and StelAtmosphere classes. I know it's a bit a pain but >> I think it's cleaner to keep those in their respective files. >> >> > > I definitely don't plan to move that into Renderer implementations. > > Initially, I'd like to keep most of that code outside Renderer but move its > GL-related parts into Renderer, which would require Renderer interface to > be flexible enough to handle it. Good. I think that is somehow what Qt people spent years of coding efforts on with the Qt3D stuff. You should really have a very detailed look at it before going very far in your own implementation. There is a good chance that most of the tedious work is already done there. Don't be afraid to use it if necessary. > If that doesn't work, it can be implemented in classes _used_ by Renderer > that would have their own implementations for each Renderer backend. > > Renderer also might end up having specialized functions for very > specific drawing > tasks if that is unavoidable, but I'd like to keep as much of that > code as possible > outside, and whatever must be done inside would be done in separate classes > used by Renderer. I don't want 2000-line classes. > > Basically, I'd like to create a clean separation between > Graphics classes here - Main Stellarium code here. > > (i.e. StelGL2SkyDrawer, etc.). OK. > I'm not yet sure which way I'll do it. That's why I'm experimenting with it, > to get a better idea (I still don't have a complete idea about > Stellarium codebase). Feel free to ask me questions! Fab > FM > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
