Hello everybody,

I would like to ask a question about the way different distro's handle the rendering of the screen in different applications. I know this is a vague question, but let me get a little bit more specific.

As I was working with a Raspberry Pi lately, I figured that the desktop and all applications are rendered (displayed, don't really know the correct term) by the CPU when using Raspbian. For example, when opening a window with an image, the CPU spikes. However, the Pi has a decent GPU (for such device) and video's being played on it run smooth.

The problem lays in the first as I am writing software that should display images and scrolling text,... I hoped I could do this using the GPU but in Free Pascal but couldn't find any way to do so (if somebody knows, please let me know).

So I figured the problem lays with X, the display manager thing.
Now is my question: when does the x-server uses the GPU to do these tasks and when the CPU? Is this different on all distributions? For example, Compiz is used in Ubuntu (that is right?), does that uses the CPU or GPU or is this a totally different thing? (I am running X there too right?)

Anyways, I was looking for a solution as the Pi can't handle any smoothness like this. Not even close when he should be copying files in the background...

I hope my question was clear. Hoping for an answer and if you need some more info, just let me know!

Thanks in advance,

BlueMoony

Well CPU is used to run most of the application code. For display GPU is used. For some 2D acceleartion in addition to CPU, GPU can also be used. Same for 3D.

If your GPU doesn't supports acceleration then CPU would be used.

In linux X is used to display gui and also supports 2D acceleration. Mesa3D is used for 3D ( be it cpu or GPU based) together with drm.

For GUI you use GUI Toolkits like GTK+, QT, SDL, Fltk, Enlightenment, etc.

I think freepascal has support for gui programming with fpGUI, but you should do web search. Most toolkits support C.

Some GPU also support Video Acceleration which helps faster video playback.

Alright, I get most of it but not all.

What are the requirements to, for example, make a scrolling text be 'rendered' by the GPU and not the CPU?
I know for the Raspberry Pi (Raspbian), it does use the CPU when I just use a textbox and make it move by performing a loop over x or y position.
This behavior is because the way I do it isn't the correct way or is it because the PI's X is not able to talk with the GPU for rendering that?

Video's (1080p) run smooth on it, while moving a window or make a scrolling text in Lazarus spikes the CPU and lags like hell. I read on different forums/sites that Raspbian is a spin-off of Debian and has less features because the Pi can't cope with it. Could that be the problem? So, if I buy another board, the same code will perform smooth by using the full debian distro or another one like for example Ubuntu?

Sorry for my maybe 'vague' questions, I am just kinda stuck

I think you should use OpenGL for doing that.

Find out about opengl programming in linux by web search.

There is now open source 3d(opengl) driver available for RPi.

Ok, so I think I am starting to get this.

Whenever I write a program, the CPU will always be used to do anything I write except when the library I use, uses specific public interfaces to talk to hardware. An example of the interface is OpenGL.
Using those libraries will not always use the GPU as the OS has to have a driver that can 'talk' to that specific hardware and the hardware should be able to handle the requests for example, it should support OpenGL when I use a library that uses OpenGL functionality. If the OS hasn't got any driver, it will use it's CPU to do the rendering.

Is this a correct view of how these things work?

Little extra question about RPi: media players like MPlayer can use the GPU functionality to display video's while the OS, Raspbian, has 'no' access to the GPU for smoother rendering of the windows. Where is the difference?

Yes, you are more or less right. But unfortunately there are several layers. The low level is the so-called driver, that will access the hardware. OpenGL or different codecs are another layer, they offer a much simpler way (and higher level) to drive that device. These are usually installed as libraries. Using an app you can use either the low level or any other layer, it really depends on your needs. Sometimes these libraries (like OpenGL) are is installed, but sometimes (like some codecs) are not available. In such cases the application you want to use can have statically linked libraries (that means the libs and app are put together into one single file) and therefore it does not depend on the configuration of the target host. That's why MPlayer works and that's why other things cannot....

That was the missing piece! But, not done yet
That means that X, the display manager, does not use the lower lever access nor the available libraries. I guess that is because X is installed on so many systems it has to be as dynamic as possible. Even if this is the case, it should be possible to let X make use of those libraries/low level access on any system, even the Pi. Is this the case? I found some info about that, X has support for 2D and 3D hardware acceleration. I guess this has to do something with it?

yes, X has support for the general ati and nvidia chips, that means the low level driver is built in. But of course on Pi you will find another kind of drivers.

So, if I install this driver found here, my X should perform better even though I did not use any OpenGL libraries in my own program. To have even more free CPU time, I can use OpenGL libraries for rendering anything inside my window.

Hm. Hard to say anything, but probably yes. Actually it looks like a good choice. You can definitely test it.

For RPi there was a open prize competition about whoever develops a opensource 3D driver which would run OpenArena Single player shooter game will get ones. This was announced after RPI 3d/2d video specs were opened by Broadcom company. At the start RPi had only closed source video drivers.