This is a RFC on a follow-up patch to my recently posted patch series on the xorg-devel mailing list to enable per window flips of Present Pixmaps to Wayland surfaces: https://lists.freedesktop.org/archives/xorg-devel/2018-January/055674.html
With the attached patch queuing events should be possible. This works with the changed timer interval reasonable well, but I don't fully understand the logic of queuing, that's why I decided on excluding the patch from the above patch series. The problem with the old timer interval was, that this was too slow. For example VLC would send new Pixmaps too slow and the video would stutter. So changing it to a larger value makes sense. But the question is if this needs to take into account the refresh rate of the display as well. I would then go over to analyzing the current position of the window and the refresh rate of the xwl_output the window covers the most (this is similar to how the xfree86 modesetting driver does it). Anyways I don't fully understand the logic behind this queuing mechanism. The client would need to know the refresh rate it can accept to predict the upcomping MSC counter its next presentation is supposed to be depicted on. I don't see such logic in the Present extension. Or is the client supposed to calculate the refresh rate from the returned UST values? _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
