[fpc-pascal] FPC hardware accelerated GUI apps. Why?

[Marco van de Voort]

In our previous episode, Lars said:
> > Could be potential further discussion about FireMonkey moved to
> > fpc-other, please? I don't think that it's still related to FPC...
> Fine, let me put it this way to keep it 100 percent on topic.
> 
> If FPC was able to create hardware accelerated GUI apps (nothing to do
> with firemonkey... just in general if it was able to), is this useful?

Well, first, most GUI applications are already accelerated. So even if the
application has no explicit knowledge about it, it might use the GPU.

> What advantages do hardware accelerated GUI apps offer?

Aside from that, as an example, I implemented OpenGL support in my (work)
application simply to have smooth scrolling of large images without blocking
the main thread.  Low framerates (5-10, higher are rate limited), but large
images.  (2Mpx mono till 25mpx RGBA)

FM and some other seem to stress effects and control animations though, like 
the trend in GUI was before it got win8-10 flat again. Probably that is
because it is easier to fixate in the API and requires less enduser ability
and effort.

> If FPC was able to target hardware accelerated GUI (or if it already does)
> then what advantages would this offer people?  There must be some reason
> for hardware accelerated GUI apps.

The main reason is to have a widget set that feeds the "real" gui system in
a compositive way. IOW if the screen needs to be redrawn, the OS or X
environment must be able to render the next scene without additional CPU
cycles.

This is important on the desktop (which is compositing since Windows Vista,
OS X since (afaik) 10.4), but even more so on mobile, since it simply means
that rendering the next image will run on the lower clocked, parallel GPU
rather than the higher clock, not so parallel CPU.

But that is less about actually doing stuff in the GPU but having a GPU
friendly model/abstraction. You can do old school rendering as long as you
pass it to the OS/XServer in a way it can composite it easily without
additional events, read: a modern API.  If the desktop then creates a new
arrangement of windows it doesn't have to call back into the application to
render the image again (like e.g. Windows GDI does).

Of course anybody designing any new widgetset will stress this fact, just
like anything nowadays should tick CSS and javascript bullets.

But all that requires actual OS/Xserver support.

> But maybe it's to do with flash style animations, video game like
> interfaces for apps... 3D apps?

I think the core desirable principle is to support compositing, as in no
application involvement to render the same image, but slightly stretched
(e.g. resizing a window) etc. You can of course extend this slightly to
animation. Instead of the desktop calling the application to render every
new sequence in the application, you pass the animations frames at once, and
leave it to the desktop to render it optimally.

This leads too general more responsive GUI, with lower CPU usage (mobile
again), even if the elements are reletively hires and complex.

Of course the marketeers want to sell you some hyped up vision of it, but
the core concept is ok.