Description
Wayland shm buffer management logic is partially implemented. Conky is currently only allocating a single buffer from shm_pool and mutating it instead of managing two separate buffers and just swapping them after Wayland commit call.
This shouldn't be guarded by a compile flag - it's a requirement from Wayland. It's a bug currently because after commit the compositors expect they can use the shared memory freely as a static image and conky instead just clears the buffer and starts drawing the new one.
Next - wl_buffer release listener is missing. Wayland compositors send a wl_buffer.release event when they're done reading a buffer. This is the signal that it's safe to continue drawing on the buffer that was previously committed.
Lastly, we're not using frame callback (wl_surface.frame). Without a frame callback, there's no synchronization with compositor vsync. Rendering happens independently of the compositor's frame cycle, meaning we can be drawing frames far more frequently than compositor is able to present. This part is less of an issue given that conky doesn't draw eagerly and usually the update cycle is far slower than what compositor is able to present, but ideal code should wait for frame callback.
- A good example where this might matter is multiple desktops: if conky window is hidden on a separate desktop, compositor will stop issuing
framecallbacks, and then we can save resources by stopping all system monitoring until it's actually needed. This part requires some larger changes though and addressing just the first two parts of this issue would be a large overall improvement.
Brought up by @tmineno in #2369.