RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions

[Maxim Kartashev]

On Fri, 7 Apr 2023 20:38:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Multiple seconds seems out of bounds (so to speak :-)), for network latency of an X11 round trip.

Most certainly. What I actually measured was the time (min, max, and average) the AWT lock was being held by a method.

In fact, the story began with [fakexrandr](https://github.com/phillipberndt/fakexrandr), a tool that divides one monitor into several for purposes beyond my comprehension (testing, perhaps?) When this tool is configured to fake many monitors (don't remember the exact number, but it was around 10 or more), it starts to introduce significant delays that [annoyed some users](https://github.com/phillipberndt/fakexrandr/issues/64#issuecomment-901877835).

Normally, `X11GraphicsDevice.pGetBounds()` holds the AWT lock for 1 ms on average with 11 ms max in one of the experiments.. `fakexrandr` managed to bring this number up to 34ms on average, which - together with `XToolkit.getScreenInsets()` - was the only difference between "fast" and "sluggish" GUI that users were reporting. Other operations took about the same amount of time.

But it wasn't just about `fakexrandr`: I also noticed that a remote X session has the same effect as `fakexrandr`. As an example, on a remote machine the call to `XToolkit.getScreenInsets()` holds the AWT lock for 69ms on average with a whopping 830ms peak. As is obvious from the average number, such a long delay doesn't happen frequently, so it's very hard to start profiling at exactly the right moment in order to try to find out the underlying cause.

In the end, I'm sure it's about the timing of *other* operations that take the AWT lock coupled with the delays introduced by `XineramaQueryScreens()` and friends. Perhaps the recent [commit](https://github.com/openjdk/jdk/commit/dc81603cbf223c3ac6b41396d1998a07524a0d54) for `8305666: Add system property for fair AWT lock` may also help with this, but it wouldn't be as effective as this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1501473318