Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2010-12

fpGUI powered by OpenGL

18 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Darius Blaszyk

Today after tinkering a few hours I managed to get an fpGui hello world app running with OpenGL and GLut as back-end. It seemed even easier than anticipated to switch the back-end. I'm happy to share code, although due to implementation differences it will never be possible to have a clean solution which could be merged with the original source.

Cheers, Darius

PS. fonts are rendered using freetype, used font is Ubuntu-R

Michael Van Canneyt
to Darius Blaszyk
Darius Blaszyk wrote 5 lines
Today after tinkering a few hours I managed to get an fpGui hello world app running with OpenGL and GLut as back-end. It seemed even easier than anticipated to switch the back-end. I'm happy to share code, although due to implementation differences it will never be possible to have a clean solution which could be merged with the original source.

What does that mean ?

Michael.

Darius Blaszyk
to Michael Van Canneyt
Michael Van Canneyt wrote 10 lines
On Sun, 19 Dec 2010, Darius Blaszyk wrote: > Today after tinkering a few hours I managed to get an fpGui hello world > app running with OpenGL and GLut as back-end. It seemed even easier than > anticipated to switch the back-end. I'm happy to share code, although > due to implementation differences it will never be possible to have a > clean solution which could be merged with the original source. What does that mean ?

This means that a modified (fork?) FPGui could be made available on probably most platforms where FPC and OpenGL are available at (win/*nix/mac but also mobile targets/platforms like iPhone and other through OpenGL ES).

This could potentially be useful for game developers that would like to use a toolkit out of the box instead of developing one themselves from scratch.

Regards, Darius

Unknown author
to leledumbo
leledumbo wrote
Nice :) We could benefit from hardware accelerated OpenGL graphics with this. Have you implemented all the required low level backend?

No not yet. I have only done the absolute minimum sofar. Yesterday I got u bunch of widgets running, but the drawing was not correct. Also no events (apart from the drawing wich I hacked together) are fired correctly anymore. But al this is fixable, be it that it will most likely not fit the current implementation.

Regards, Darius

Michael Van Canneyt
to Darius Blaszyk: This means that a modified (fork?) FPGui could be made available on probably most…
Darius Blaszyk wrote 20 lines
On Sun, 2010-12-19 at 19:15 +0100, Michael Van Canneyt wrote: > > On Sun, 19 Dec 2010, Darius Blaszyk wrote: > >> Today after tinkering a few hours I managed to get an fpGui hello world >> app running with OpenGL and GLut as back-end. It seemed even easier than >> anticipated to switch the back-end. I'm happy to share code, although >> due to implementation differences it will never be possible to have a >> clean solution which could be merged with the original source. > > What does that mean ? This means that a modified (fork?) FPGui could be made available on probably most platforms where FPC and OpenGL are available at (win/*nix/mac but also mobile targets/platforms like iPhone and other through OpenGL ES). This could potentially be useful for game developers that would like to use a toolkit out of the box instead of developing one themselves from scratch.

But why is it not possible to integrate this with the regular fpGUI ? Can you explain in a couple of sentences ?

Michael.

Unknown author
to Michael Van Canneyt: But why is it not possible to integrate this with the regular fpGUI ? Can you explain in…
But why is it not possible to integrate this with the regular fpGUI ? Can you explain in a couple of sentences ?

Can't remember having said that it was impossible with the current approach. In fact it is perfectly doable. However (free)glut and opengl are already available on a large number of platforms/targets. So if fpGUI is built upon these libs then you immediately take the benefit of being able to support these platforms. Additionally you don't have to implement a "complex" interface between the different platforms this is handled already by glut and opengl for you. So in effect it could make fpGUI simpler. And the last plus is having a hardware accelerated gui. It just means it's lightning fast and that's a plus for UI's. 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!)

I probably forgot a few plusses and minusses, but that's about it as far as I'm concerned. Also I don't mean to say that using an opengl/glut backend is superior to the current ones. It just has other benefits I suppose.

Regards, Darius

Vincent Snijders
to Unknown author

2010/12/20 :

Show quoted text 24 lines
> But why is it not possible to integrate this with the regular fpGUI ? > Can you explain in a couple of sentences ? Can't remember having said that it was impossible with the current approach. In fact it is perfectly doable. However (free)glut and opengl are already available on a large number of platforms/targets. So if fpGUI is built upon these libs then you immediately take the benefit of being able to support these platforms. Additionally you don't have to implement a "complex" interface between the different platforms this is handled already by glut and opengl for you. So in effect it could make fpGUI simpler. And the last plus is having a hardware accelerated gui. It just means it's lightning fast and that's a plus for UI's. 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!) I probably forgot a few plusses and minusses, but that's about it as far as I'm concerned. Also I don't mean to say that using an opengl/glut backend is superior to the current ones. It just has other benefits I suppose.

The above explains why it is useful for an application developer to use an openGL backend.

It does not explain the following: Since fpGUI already has two backends (afaik, X and winap), why can't openGL a third one? Did you change the way fpGUI interfaces with its backend? Is this change so incompatible with the current backends, that they cannot be modified?

Vincent

Henry Vermaak
to Vincent Snijders
Vincent Snijders wrote 33 lines
2010/12/20  : >> But why is it not possible to integrate this with the regular fpGUI ? >> Can you explain in a couple of sentences ? > > Can't remember having said that it was impossible with the current approach. > In fact it is perfectly doable. However (free)glut and opengl are already > available on a large number of platforms/targets. So if fpGUI is built upon > these libs then you immediately take the benefit of being able to support > these platforms. Additionally you don't have to implement a "complex" > interface between the different platforms this is handled already by glut > and opengl for you. So in effect it could make fpGUI simpler. And the last > plus is having a hardware accelerated gui. It just means it's lightning fast > and that's a plus for UI's. > 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!) > > I probably forgot a few plusses and minusses, but that's about it as far as > I'm concerned. Also I don't mean to say that using an opengl/glut backend is > superior to the current ones. It just has other benefits I suppose. The above explains why it is useful for an application developer to use an openGL backend. It does not explain the following: Since fpGUI already has two backends (afaik, X and winap), why can't openGL a third one? Did you change the way fpGUI interfaces with its backend? Is this change so incompatible with the current backends, that they cannot be modified?

I'm sure Graeme would be very interested to provide guidance, too. Is he still subscribed to this list?

Henry

Jonas Maebe
to Henry Vermaak
Henry Vermaak wrote
I'm sure Graeme would be very interested to provide guidance, too. Is he still subscribed to this list?

No, he unsubscribed himself.

Jonas

Reimar Grabowski
to Unknown author: Can't remember having said that it was impossible with the current approach. In fact it…
Show quoted text 11 lines
> 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?
Darius Blaszyk
to Reimar Grabowski
Reimar Grabowski wrote 18 lines
On Mon, 20 Dec 2010 15:50:52 +0100 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

I wouldn't use the same words as you do, but I agree it's sub-optimal ;)

Show quoted text 17 lines
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

I should have chosen my words more carefully. With fpGlut I actually did not mean to port freeglut to pascal, but actually create a platform independent context handling library (as you describe).

context). The drawback is that context generation is a little more complex than using glut and that it is platform dependend. I haven't

This is the reason why I started using GLut. Just as proof of concept.

Show quoted text 5 lines
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

Totally agree

doing this myself but if you need help I will do what I can.

If I get enough help I could be interested in starting a new project.

Darius

Darius Blaszyk
to Vincent Snijders: 2010/12/20 : The above explains why it is useful for an application developer to use an…
Show quoted text 7 lines
The above explains why it is useful for an application developer to use an openGL backend. It does not explain the following: Since fpGUI already has two backends (afaik, X and winap), why can't openGL a third one? Did you change the way fpGUI interfaces with its backend? Is this change so incompatible with the current backends, that they cannot be modified?

The changes I think are pretty incompatible. This is because the GLut library also provides messaging, whereas in fpGUI the messages are implemented outside of the backend. Therefore hacks are needed to keep the drawing messages coming correctly. With a pascal context library everything could be merged seamless I suppose.

Darius

Darius Blaszyk
to Darius Blaszyk
Darius Blaszyk wrote 13 lines
> The above explains why it is useful for an application developer to > use an openGL backend. > > It does not explain the following: Since fpGUI already has two > backends (afaik, X and winap), why can't openGL a third one? Did you > change the way fpGUI interfaces with its backend? Is this change so > incompatible with the current backends, that they cannot be modified? The changes I think are pretty incompatible. This is because the GLut library also provides messaging, whereas in fpGUI the messages are implemented outside of the backend. Therefore hacks are needed to keep the drawing messages coming correctly. With a pascal context library everything could be merged seamless I suppose.

I've been badly mistaking. With some minor adjustments it will be possible to create an OpenGL back-end most probably. At least to a higher degree that I was proclaiming previously. I've now been able to hook most fpGUI messages to GLut.

Regards, Darius

Paul Nicholls
to Darius Blaszyk

"Darius Blaszyk" wrote
in message

Show quoted text 22 lines
On Mon, 2010-12-20 at 18:58 +0100, Darius Blaszyk wrote: > > The above explains why it is useful for an application developer to > > use an openGL backend. > > > > It does not explain the following: Since fpGUI already has two > > backends (afaik, X and winap), why can't openGL a third one? Did you > > change the way fpGUI interfaces with its backend? Is this change so > > incompatible with the current backends, that they cannot be modified? > > The changes I think are pretty incompatible. This is because the GLut > library also provides messaging, whereas in fpGUI the messages are > implemented outside of the backend. Therefore hacks are needed to keep > the drawing messages coming correctly. With a pascal context library > everything could be merged seamless I suppose. I've been badly mistaking. With some minor adjustments it will be possible to create an OpenGL back-end most probably. At least to a higher degree that I was proclaiming previously. I've now been able to hook most fpGUI messages to GLut. Regards, Darius

Hi Darius, nicely done :)

I for one, would be interested in the code :)

cheers,
Paul

Darius Blaszyk
to Paul Nicholls
Paul Nicholls wrote 28 lines
"Darius Blaszyk" wrote in message > On Mon, 2010-12-20 at 18:58 +0100, Darius Blaszyk wrote: >> > The above explains why it is useful for an application developer to >> > use an openGL backend. >> > >> > It does not explain the following: Since fpGUI already has two >> > backends (afaik, X and winap), why can't openGL a third one? Did you >> > change the way fpGUI interfaces with its backend? Is this change so >> > incompatible with the current backends, that they cannot be modified? >> >> The changes I think are pretty incompatible. This is because the GLut >> library also provides messaging, whereas in fpGUI the messages are >> implemented outside of the backend. Therefore hacks are needed to keep >> the drawing messages coming correctly. With a pascal context library >> everything could be merged seamless I suppose. > > I've been badly mistaking. With some minor adjustments it will be > possible to create an OpenGL back-end most probably. At least to a > higher degree that I was proclaiming previously. I've now been able to > hook most fpGUI messages to GLut. > > Regards, Darius > Hi Darius, nicely done :) I for one, would be interested in the code :)

Hi Paul,

I've cleaned up the code and integrated it more nicely with the existing implementation. It runs now on Linux and Win32. However still struggling with the message loop which is implemented differently in GLut. As for the code, perfectly happy to share although I don't know where to put it. I will ask Graeme if he can create a branch or something. Will let you know.

Regards, Darius

Paul Nicholls
to Darius Blaszyk

----- Original Message -----

Earlier message 53 lines
From: "Darius Blaszyk" To: "FPC-Pascal users discussions" Sent: Thursday, December 23, 2010 10:15 AM Subject: Re: [fpc-pascal] Re: fpGUI powered by OpenGL > On Thu, 2010-12-23 at 10:06 +1100, Paul Nicholls wrote: >> "Darius Blaszyk" wrote >> in message >> > On Mon, 2010-12-20 at 18:58 +0100, Darius Blaszyk wrote: >> >> > The above explains why it is useful for an application developer to >> >> > use an openGL backend. >> >> > >> >> > It does not explain the following: Since fpGUI already has two >> >> > backends (afaik, X and winap), why can't openGL a third one? Did you >> >> > change the way fpGUI interfaces with its backend? Is this change so >> >> > incompatible with the current backends, that they cannot be >> >> > modified? >> >> >> >> The changes I think are pretty incompatible. This is because the GLut >> >> library also provides messaging, whereas in fpGUI the messages are >> >> implemented outside of the backend. Therefore hacks are needed to keep >> >> the drawing messages coming correctly. With a pascal context library >> >> everything could be merged seamless I suppose. >> > >> > I've been badly mistaking. With some minor adjustments it will be >> > possible to create an OpenGL back-end most probably. At least to a >> > higher degree that I was proclaiming previously. I've now been able to >> > hook most fpGUI messages to GLut. >> > >> > Regards, Darius >> > >> >> Hi Darius, nicely done :) >> >> I for one, would be interested in the code :) > > Hi Paul, > > I've cleaned up the code and integrated it more nicely with the existing > implementation. It runs now on Linux and Win32. However still struggling > with the message loop which is implemented differently in GLut. > As for the code, perfectly happy to share although I don't know where to > put it. I will ask Graeme if he can create a branch or something. Will > let you know. > > Regards, Darius > Thanks Darius, keep up the excellent work :) cheers, Paul