On Tue, Mar 8, 2011 at 4:13 PM, Soeren Sandmann <[email protected]> wrote: > James Jones <[email protected]> writes: > >> Interesting. I'm not really sold on the switch to InputOnly windows though. >> It sounds very elegant in theory, but I don't like the idea of apps needing >> to >> use a separate codepath depending on whether a composite manager is running, >> and I'm not convinced it doesn't have other side effects. I'll definitely >> have to give it some more thought though. > > It will require changes to the applications, yes. For GTK+ I think the > main complication is the fact applications can create subwindows, and > then ask for an XID for those subwindows. These applications will expect > that XID to be an InputOutput window, which would be impossible if the > toplevel was an InputOnly. > > This issue is not insurmountable though, since getting the XID for a > GTK+ window is a rarely-used feature and increasingly considered > somewhat deprecated. > > > Soren
I think you are trying to create way too complex solution to simple problem. Problem has been already solved in 80s by using double buffering and swapping the buffers. Actually GL way of defining that everything should look to application that swap buffers happened immediately even tough it might take many milliseconds to complete the swap. This kind of pipelining of all operations will make it a lot easier to make everything flicker and tear free if driver is just written correctly. Then all modifications to windows, mode etc should be defined to take effect on the next swap buffers. To make think easier in some cases some operations might be defined to cause implicit swap buffers. For example good definition for XCompositeUnredirectWindow(window client_window, pixmap root/scanout, int mode) would be "causes <pixmap> to swap to <window> front buffer and any subsequent swap buffers to <window> will swap <window> back buffer to <pixmap>" To support legacy applications they would have to render to back buffer or "fake front". Buffer swap would be then implementation detail that can happen based on timer or damaged area or what ever heuristics makes legacy application look fairly good. Pauli _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
