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

Reply via email to