SYNC: how to hijack the hijacker

Steven J Abner pheonix.sja at att.net
Sun Feb 2 21:00:29 UTC 2025


On Sat, Feb 1 2025 at 11:51:48 PM +0000, Steven J Abner 
<pheonix.sja at att.net> wrote:
> I am having problems again using xcb because of those things called 
> window managers. I am still thinking of ways to even circumvent SYNC 
> since I want an application to use xcb without having to load every 
> os to figure out wm oddities workarounds. I am aware that gdk can 
> somehow beat the system, but a glance at their code looks like they 
> use SYNC, but how?.

Found a workaround, not 100% perfect but proof of concept worked.
Solution was a counter, and a surface as static variables. On configure 
event, when counter is 0, steal the last sent surface for output on 
expose event until counter reaches 4 then draw as normal expose event. 
The newly redrawn surface becomes last sent when entering configure, 
with counter always resetting on 4 count.
Configure always configures, just now from testing, actual expose event 
nearly matches my 60 fps of 'object' redraw on invalid objects.
Again was proof of concept, so probably only need a configure once, 
instead of 4 with
both configure/expose occurring on a 4 count.
This does leave small non-redrawn region on grow, but probably smaller, 
maybe same, as gdk's workaround and some window resize jitter but not 
on content.
Possible timer on a combo configure/expose might work?
 But if anyone knows how to intercept wm hijacking I think SYNC could 
be a solution.
May cause problem of receiving event after me though? But solution 
above I think solves the problem of multiple wm #if #else #endif and 
loading all of them onto disk to test.
Steve




More information about the Xcb mailing list