[fpc-pascal] fpGUI powered by OpenGL

Reimar Grabowski reimgrab at web.de
Mon Dec 20 16:47:35 CET 2010


On Mon, 20 Dec 2010 15:50:52 +0100
<dhkblaszyk at zeelandnet.nl> wrote:

> > But why is it not possible to integrate this with the regular fpGUI ?
> > Can you explain in a couple of sentences ?
> 
>  Thats not all however, there are minusses. By using glut, you limit 
>  yourself to the supported platforms/targets. So if new platforms/targets 
>  come along then there is no way (unless you supply patches to the 
>  project) to add them. With the current approach you're free to do it 
>  yourself. Also the API is plain rigid. This means you'll have to adapt 
>  to that and live with it (notice it's a plus and minus depending on how 
>  you look at it). (That is why I would like to see a fpGlut some day ;) 
>  and believe me it will come to that eventually!)
First of all good work, but I hope to never see any abominations like fpGlut around. Glut is just a major PITA and should not be used by anybody for anything serious. It was developed to make it easy to write SIMPLE OpenGL DEMOS in a cross plattform way. Since then it has been used for all kinds of stuff although it has some big limitations namely its mainloop and the callback shenanigans. Both interfere with the nature of a GUI framework and therefor I don't really understand why you based your work on glut. OpenGL is a graphics lib and glut includes window creation, mouse and key handling, etc which should be separate.
You don't need glut to use OpenGL you just need a valid context. I don't know anything about the inner workings of fpGUI but if you think that a fpGlut would help you then I am sure a fpOpenGLContext would help even more and perhaps make it possible to merge the code back to regular fpGUI.
Benefits of custom context generation are that you have more control over its options (ColorBuffer-, DepthBuffer-, OtherKindOfBuffers-Resolution, double-, triple-, quadbuffering, etc.), no mainloop or callbacks (the TOpenGLContext of the LCL works with the standard LCL event system and application mainloop) and no need for glut support on the target platform (every OpenGL capable platform exposes a way to create a context).
The drawback is that context generation is a little more complex than using glut and that it is platform dependend. I haven't looked into the new OpenGL stuff > 3.0 but I know there was talk about simplifying context generation and to try to make it more similar on the different platforms.
So IMHO getting rid of glut and integrating an OpenGL context into fpGUI should make it possible to just use OpenGL as a standard backend for fpGUI. I am not really interested in doing this myself but if you need help I will do what I can.

hih
R.
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



More information about the fpc-pascal mailing list