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