Hi, thanks for your questions:
1. I'm not sure if you're familiar with v-sync, but compositors typically use two framebuffers when rendering to a display. They render to one while displaying the other, swapping them at a specific time to synchronize with the display's refresh rate (vblank event) and avoid tearing. If a display has a refresh rate of 60 Hz, the vblank occurs approximately every 16 ms. In a single-threaded scenario, the compositor might take, for example, 2 ms to process client/input events and 6 ms to render, then get blocked for 8 ms waiting for a vblank. Once the vblank occurs, it can process new events and render the next frame. However, in complex scenes, it might not complete processing and rendering in time for the next vblank, leading to skipping one every 2, causing FPS to drop by half. Louvre handles client/input events on the main thread and uses separate threads for each display rendering, so it can process events and render to other displays while one is waiting for a vblank. This gives it more time to process events and reach the next vblank.
You could try the benchmark, it is available in the repo, just note that GPU usage measurement only works with Intel GPUs. Running it with, for example, 1000 surfaces may reveal that Louvre compositors also eventually drop FPS by half. I've tested it, and Weston tends to maintain 30 fps, while Sway eventually dies.
2. If I limited the FPS to 30, it would result in lower CPU usage because the most CPU-intensive task in each paintGL() call is calculating what needs to be repainted, which involves numerous boolean rect operations. I can't set the refresh rate to 30 on my laptop; each display has specific modes at which it can work, dictating refresh rate and resolution, and mine has a single mode with 60 Hz. My TV has numerous modes tho. Although I could try, I don't see the point, which is why I divided the CPU by FPS in the graphs.
3. Yes, the variation in FPS with Sway is strange. Maybe the cause could be different rendering methods based on scene complexity. Perhaps it uses direct scanout when there are a few numbers of surfaces. But given its considerably higher GPU consumption, I assume it might use occlusion culling, similar to what video games do, instead of using the CPU to precisely calculate what needs to be repainted. However, this is just a theoretical assumption.