The Wakefield committers may hold off-line discussions from time-to-time. Since these meetings are just for the committers and invited wayland experts, summary minutes will be recorded here as time permits
Online Zoom Meeting 9am PDT 25th May 2023
Attendees: Victor D'yakov, Alexey Ushakov, Phil Race, Kevin Rushforth, Maxim Kartashev, Olivier Fourdan, Jonas Adahl, Alexander Zvegintsev
we have pushed several changes related to the X11 compatibility :
JDK-8307779 - Relax the java.awt.Robot specification
JDK-8280993 - [XWayland] Popup is not closed on click outside of area controlled by XWayland
CSR JDK-8307456 approved for the java.awt.Robot taking screenshots issue wth Screencast. This fix is also targeted to JDK 21.
Drag and Drop does not work in java -> wayland app direction: while this DND fix has been released on the system side(1, 2), changes are still required on the JDK side.
Our code it quite picky for the drop target, and requires it to be a toplevel with WM_STATE property, whereas the Wayland server uses dummy windows without this property set.
I already have a fix for this on the JDK side that I want to put in 21, but first I want to make sure I didn't break anything. In any case, it will be active when the Wayland session is active.
We still have test failures, some of them are tests that really was not so stable, and the timing thing on Wayland vs Xorg makes them fail.
Interesting categories of failures are number of crashed that seem to be in pipewire code.
It is a mixture on the thread that attached to the JDK where we actually calling something and occasionally some threads that pipewire kick of on its own.
We have seen at least one that says "stack smash", terminating.
And there is one that is not a crash, with one particular test on particular systems, which we still need to analyze, related to be not able to get the screen data.
Some of the crashes are in tests that do a lot of captures in a loop.
There is one test which repeatedly moves a mouse cursor and taking a pixel color at mouse position. It makes around ~11000 of getPixelColor requests, which takes no time on Xorg, but can time out with the new API. Alexander said that one request can be 3000x slower on his machine comparing to X11 implementation. So anything that captures pixels in a loop over and over again is a potential problem.
Sometimes when a test fails, test harness makes its own screencapture from another VM, so we wondering about the concurrency of all these libraries we are using now.
It could be a mixture of bugs in our code, bugs in pipewire that are fixed in a later version, or bugs are not yet fixed.
Some comments about threads, I would first check that you have handled the processes callback from pipewire, and also check that you have not enabled the real time pipewire thread(It is normally not enabled, as you should explicitly enable it).
Regarding performance, you are using the screencasting not for screencasting, not the way it is intended, so it is not strange that it takes so much longer time, due to security checks, sessions processing, streams and all that stuff.
The workaround for this particular test case is to keep this stream open, reducing the number of re-negotiation, permission checking, etc.
It reminds me one optimization, that we did for metal pipeline, we have display sync thread which started and stopped on each redraw request.
So the optimization was to have a keepalive counter that allows us to keep at alive enought to catch subsequent requests.
Probably this approach can be used here.
I do not want to overblow this, there are few tests/use cases which really suffers from this, most cases do screen capture a couple of times. So this enhancement could be done later, I don't think that we should rush on that and redone all of that in JDK 21.
All of the TCK tests pass, it is a good step that we pass all the conformance tests. It is the some of functional tests failing.
The plan is to ship this screencast code in 21, and if somebody happens to run on Wayland it should work modular this crashes. We are not gonna say it is supported, we hoping it should practically for most cases.
XTest will be wired to libei, which will actually move your mouse pointer using the Wayland compositor.
The good news is that libei 1.0.0rc1 was released a couple of days ago so we are working hard to try get everything in place, and it is moving nicely.
I fixed a few bugs in our implementation of Wayland toolkit regarding scaling multiscreen environment with different scaling.
What I did was that I tried to keep the buffer associated with a window in sync with the scaling of the window of the output where the window is on(use maximum). So if I move window from an output with 200% scale to an output with 100% scale, the buffer actually shrinks, but now I am not sure that I really have to do this, because the window to my does not change at all.
Wayland seems to scale the buffer correctly. Do I really need to go through the hassle of adjusting the buffer size and have the buffer scaled to the highest available scale of outputs and leave all work to Wayland?
I would suggest changing the buffer whenever it makes sense. If you don't do this, there are two issues:
- when the compositor scales down fonts will look slightly more blurry and will be less sharp
- If you're working on two monitors (say, 100% and 200%) on a battery-powered machine, and your main program is always on a lower-scaled monitor, all that drawing at 200% and scaling down work will increase power consumption and decrease battery life.
Right now it means that you always check at what outputs you are actually on, an take the maximum scale.
There is an extension for the fractional scaling that give you preferred scaling. (Gnome 44+)
We are in progress of implementing Vulkan rendering for pure Wayland prototype
I recall that there was a HiDPI fix for X11 compatibily mode on Wakefield mainling list.
Is there any chance that it could be targeted for 21?
It depends on a fix I merged yesterday, so there is no chance that it will go to 21.
Online Zoom Meeting 9am PDT 27th Apr 2023
Attendees: Victor D'yakov, Alexander Zvegintsev, Olivier Fourdan, Niels de Graef, Phil Race, Maxim Kartashev, Kevin Rushforth