A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

On Wed, Jun 20, 2018 at 8:19 AM Adam Jackson <ajax at nwnk.net> wrote:

> On Tue, 2018-06-19 at 17:35 -0700, Jasper St. Pierre wrote:
>
> > First off, there's a super high latency cost here.
>
> There is a latency cost, but I think it's worth being honest about it.
> I'm on whatever iteration of the Dell XPS laptop was a Skylake, and:
>
>     2000000 trep @   0.0131 msec ( 76100.0/sec): QueryPointer
>
> You get 70k round trips a second? That... might actually be enough. You
> have sixty frames, so that's like a thousand per frame, and then the
> USB interrupt rate is only like 1kHz so you only need to service 16
> per frame anyway. Okay, this is a 3GHz machine; at 300MHz - assuming it
> scales linearly - your round trip budget is a hundred per frame, you'd
> still have like 80% of the CPU left.
>

I remember trying to do this at one point for gnome-shell's magnifier mode,
and found some severe performance issues. I never dug deeper, because of
the other issues I saw, but I was seeing actual latency with my eyes. It's
probably just a bug, though.


> > Second, actually filling in the correct event is unobvious and
> > tricky, especially when dealing with XInput2. It would require
> > building the equivalent of an X server inside your CM to send.
>
> It turns out there does already exist a library of code that implements
> these state transitions the way an X server would. It is: the X server.
> One of my "never got enough around to" projects was making the server
> code sufficiently library-like that you could embed an X server the way
> libssh means you can embed an ssh server. It's honestly not far off.
>

Yep. GDK's client-side windows also attempts to emulate an X server given
that GdkWindow is modeled after an X window, or at least it was in the GTK+
2.0 era. It would be wonderful to have the code to Enter/Leave correctly
and all that fun stuff in a library for people to reuse, so that they can
set up a window tree and "be as X11".

To be clear about the full list of issues I encountered, at a basic level:

* Active grabs obviously break your COW trick. GTK+ menus broke. I hacked
around this by taking an active grab on my COW from start and letting the
fallback path of GTK+ take over.
* XSendEvent skips passive grabs, which some clients did not like. I forget
which app was using passive grabs a lot, but when it saw a ButtonPress
event it then tried to call XChangeActivePointerGrab to convert it into an
active grab, and when that failed it crashed. I forget if I fixed this.
* Clients can call XQueryPointer when receiving a FocusNotify to figure out
where their pointer is. Most of the time, this isn't an issue, but the
regression is that if you hover over a button in GTK+, Alt-Tab away, then
Alt-Tab back, it would highlight the wrong part of the window. I fixed this
by sending a fake MotionNotify after focusing the client which mostly got
it on the right track.
* Similarly, some application set MotionNotifyHint and then called
GetMotionEvents. I was unable to fix this.
* Java's AWT filters out some synthetic events for some unimaginable reason.

Also, similar problems, but now do it all over again for XI2. And touch
input. I never even bothered to start with that.


> > To be honest, this problem was one of the original problems that
> > Wayland tried to solve. In the Wayland architecture, the display
> > server and compositing manager are combined into a single process,
>
> This is not an essential feature of the Wayland model. The compositing
> manager could, like an X compositing manager, be a separate client,
> interacting with an essentially separate set of protocols, and the
> display server would merely be a broker of handles to surfaces, some of
> which happen to be bound to hardware that displays pixels.
>
> No extant wayland server _does_ this, as far as I know. But it has some
> appeal.
>

Yeah, but this is a compositor implementation detail. Similarly, an X11
window manager could choose to talk some private protocol to other
components and help manage windows. gnome-shell certainly does, even on X11.

The distinction is that it is *possible* for a compositor to be in charge
of the event tree and sending events to clients. It is not possible, at a
general sense, to do the same in X11 without severe hacks. Maybe if the
RedirectCoordinate and TransformCoordinate parts of Composite were finished
and implemented, things would be different today. I don't have any context
into why those never got in, though.


> - ajax
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180620/10adb14e/attachment.html>