Composite redraw speedup?

[Carsten Haitzler]

On Wed, 12 Feb 2020 14:53:54 +0100 Egil Möller <egil at innovationgarage.no> said:

> 
> > EFL does. Evas (the canvas) does all the rendering (either in software or
> > GL) and handles "native surfaces" which are its term of adopting things like
> > pixmaps into the scene graph as objects. It glues in the EGL or GLX pixmaps
> > for you, partial update (buffer age...) etc. It may not be your cup of tea,
> > but it does these kinds of things.
> Well... I need to do my own shader code. In particular, I do nearly all
> the layouting in the geometry shader, and I send "all" window properties
> in as uniforms/arrays/textures (depending on type, and what the shaders
> have defined as inputs). Does it handle that kind of super generic GL
> usage?

GL is hidden from you - you just deal with objects in a scene graph - place
them size them, apply mapping transforms... That is what allows it to be
portable between software or GL or any other rendering mechanism as it's taken
care of in the library layers below. The scene graph acts as the
abstraction. What it does behind the scenes is up to the rendering engine
implementation. As it does obscure clipping on the fly to avoid overdraw it
doesn't use geometry shaders for this as an implementation detail, but it
happily could if the rendering backend went that path.

> > Unfortunately it's big and the sample of "how do I write a WM/compositor
> > using it" is "look at Enlightenment" which is absolutely not small or simple
> 
> :( That seems to be the state of documentation of all things compositor...

Indeed. :)

> > You've accepted reality at least :) You're getting into a rabbit-hole of
> > "It'll grow and grow and the more you try and polish it up the more it will
> > grow". :)
> >
> As is the case with most software. And so too already with this project.
> Mostly, I wanted to experiment with some new UX ideas (see the video).
> It took me a long time to get around to start developing on this,
> exactly because of how hairy it is...

You have some nasties - your input is going to have trouble due to zooming. the
standard x input will be 1:1 where the windows are relative to the root window
etc. :)

> > My suggestion above - have that not drive animation in detail but at a
> > higher level with source/destination geometry/state info and timelines and
> > some kind of transition/interpolation path (linear, ease in/out or just
> > provide a parameterized curve etc.) then let the compositor "run it" once
> > told what it needs to do. Of course allow that to be interrupted and some
> > new change initiated as needed by input etc.
> The problem is how to handle sequences of that / other events, e.g. "do
> this when this animation is done". It becomes a bit of a convoluted API...

but it is how you get to be efficient with less hiccups :)

You could also try running python within the compositor - use python as a
binding engine then the compositor calls the python code. you can stuff it into
a thread of its own and "ipc" between compositor loop and python thread. you
then have a tight binding with the ability to share data in memory (assuming
you put locks around accessing it) etc. :)


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com