Linux distro's and CPU/GPU rendering

[BlueMoony]

Hello everybody,

I ended up here asking my question as I am totally confused about the CPU vs GPU thingy with FPC and Lazarus.

First of all, if I compile a program in Lazarus that uses a form, what hardware component will actually 'draw' it? Will this be the GPU, or the CPU?
Second, does this matter on which OS I run it?

I got stuck with these questions as I am writing a program for the Raspberry Pi and displaying multiple windows and changing images, scrolling text,... isn't going very smooth though it has an amazing GPU (well, for such device ofc). That made me start thinking about what actually 'draws' the forms/images/...

Linux based, it is for example X11, the window manager. So, I guess that X will tell the GPU to draw windows because this are GPU related tasks or isn't it?
But that isn't the case for the Pi, as moving windows goes so laggy that the CPU has to do it! Is this also the case with for example Ubuntu on a normal system?

If it is not the fault of X, than it must be the component and lazarus (FPC) itself. I guess that he makes commands that are executed by the CPU, instead of the CPU for example of moving an image in a form. Is there any way to fix that on a normal system (Ubuntu) and on the Pi?

Sorry for my quite vague question, I just don't really understand the whole system of drawings on a screen from an application. I started looking on the net and found out about 2D and 3D acceleration which is supported by X, so I thought that that should fix the things but than why it doesn't...

Anybody that can help me a hand?

Thanks in advance!

[Leledumbo]

First of all, if I compile a program in Lazarus that uses a form, what hardware component will actually 'draw' it? Will this be the GPU, or the CPU?
Second, does this matter on which OS I run it?

CPU, unless you use GPU accelerated widgetset (if there's any, for instance somebody writes LCL interface to nVidia widgets). Anyway, OS is free to actually draw it with CPU / GPU. It's OS specific details.

RaspPI GPU supports OpenGL ES 2.0, so you can use that for highly dynamic and animated application instead of LCL.

[BlueMoony]

I am writing a program that opens up many windows at the same time which contain images, scrolling text,... And if I can't get it working on the GPU of the Pi, it is useless.

If it is OS dependent, if I buy another board with same GPU capabilities but a board that can run the a full version of Debian or Ubuntu, will the problem be fixed as the OS will now use the GPU to accelerate? I can't imagine that Ubuntu on a modern laptop uses CPU to render the windows and anything inside the windows if it is coded without GPU accelerated widgetsets. I can be wrong though

Little side question: OpenGL ES 2.0 is a Embedded System version of OpenGL. Can I just use OpenGL libraries to code?

[marcov]

Little side question: OpenGL ES 2.0 is a Embedded System version of OpenGL. Can I just use OpenGL libraries to code?

Yes and no. OpenGL ES does not support the backwards compatibility profile of opengl 3.1 and later, therefore much if not code on the net won't work. Moreover, the context creation and fonts (unless you draw them yourself) is always OS specific anyway.

So while it is possible to code opengl in a way that opengl es compatible, most code out there does not.

[BlueMoony]

For the moment, I think the only problem lays with the scrolling text which I hope is a basic function available in OpenGL ES.
I don't need advanced functionality (atm), just need to free up the CPU as it has to download stuff in the background (-> CPU) and render the screen. Screen is 'kinda' fine until my program updates files or starts downloading which, in a real time situation, it will always do.