Composite redraw speedup?

[Egil Möller]

> hint: don't glXCreatePixmap() every time you render. do it only when you first
> start compositing a window (i.e. on map) and if the window resizes. ...
I tried this at first, but couldn't get it to work under Xephyr., i.e.
the image in the texture didn't update when the window changed. Any ideas?
> also... don't handle every damage event as a draw. accumulate them for some
> time (until the next frame tick/draw) and then draw it all in one go.

I do this, sort of. When I get a new damage event, I check if I'm
already drawing every frame, and if so, just wait till next frame. If
not, I start drawing every frame for a while...

> follow the model of "i shadow copy/store all the server state locally whenever i
> can and use what i have stored locally on my side until i am told it has changed
> or circumstances are that what i have is invalid and needs to be thrown out or
> updated". 

Already do this (this is what the property* files in the sources are
for). But since I control animations by another program updating e.g. a
coordinate/size/transform matrix properties on windows to animate, I end
up having to read some select properties fairly often.


> just an aside. you want to make a "minimal compositing wm" and also want it
> fast and efficient and also want to do smooth animation and so on. this is why
> toolkits exist that have already solved these problems for you. :) they have
> gone and implemented these select based main loops and have glued in xlib for
> you and have implemented all the pixmap compositing glue to do it efficiently
> and have handled "only redraw the regions that update" and glued in vsync if
> available (or otherwise use the clock-based select timeouts) for animation. as
> you do more and more you will re-implement more and more of this. you might want
> to look at how toolkits do this or just use one. :)

Which toolkits for making compositors are there? I haven't even heard of
one... I've tried to collect the blog posts and documentation I've found
on the subject here:
https://github.com/redhog/InfiniteGlass/blob/master/docs/REFERENCES.md -
it hasn't exactly been the easiest info to find compared to other API:s
and problem spaces in Linux userland development....

I did think about using the Gtk/GObject mainloop for a while, since I
already drag in rsvg, but decided so far that the overhead in
assumptions compared to smaller code wouldn't be worth it. But it
doesn't do the composition stuff from what I know, just ordinary window
event management, timeouts etc.

Well... minimal and minimal. I guess I've given up a bit on the code
being so minimal :( I have however tried as much as possible to not put
any policy stuff in the renderer, but instead separate that all out to a
python program that handles keyboard/mouse bindings, since that's much
lower bandwidth, but is nice if it's easier to change for me/users.

/ Egil


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20200212/b2740f6e/attachment.sig>