columbarius
commented
2 years ago Analyzing our current situation:
With #184 we are most of the time saved by the framerate limiter. If we would go directly from _finish to _start, we often reach the buffer_done event before the PipeWire loop (the actual pipewire loop not our events cicle) has not enough time to provide a new pw_buffer. The most time is spend between buffer_done requesting a buffer copy and the frame_ready/failed events.
So if we want the option to run without a frame limiter we have to either spend more time between enqueuing the buffer in _finish and dequeuing a new one while the buffer_done event (the dequeueing in _start will always fail since we didn't idle inbetween).
Another solution could be to use N+1 buffers with N buffers in the PipeWire queue and one for wlroots to render in and at an event we just exchange the fd of the pw_buffer. This has the drawback that clients can't optimize the importing/mapping which comes with fixed fd tied to the pw_buffer (if it is even possible to import a image and convert it into a texture (referencing the underlying memory), which a client can reuse everytime it recieves the same fd from us.) Note: PipeWire has a flag to signal that.
This split causes a weird achitecture, with these two files appearing as completely separate black-box "modules". This causes an extra complexity which could be avoided by unifying the data structures and better organizing the code.