Hi,
first of all, thanks for your work on this.
On 10/12/21 18:56, Alexandros Frantzis wrote:
The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
Could you expand a little bit on what is the problem here? My (admittedly, limited) understanding of Wayland's general philosophy is that it doesn't care about how the process computes what should appear in a window. It just expects a buffer with the pixel data in it, and it has some efficient way to move that buffer from the client to the compositor, which then does compositing and brings the result to the screen. But if you can efficiently move a buffer from a client to a compositor, it doesn't sound that much harder to move it from a client to another client and then to a compositor, thus basically allowing a process to draw on another process' window. What am I missing?
One problem commonly mentioned about windowing drivers is that they are hard to test. My understanding of the reason is that they have to interact with external systems (X11, Wayland, native Windows, ...) that are hard to mock (especially, hard to mock in a way that preserves all the quirks we have to care about) and hard to configure so that their behavior is predictable and testable. Does a Wayland driver has a hope to make things any easier here?
Thanks, Giovanni.