> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
