Request for feedback for my GSoC project to improve Present support in Xwayland

[Pekka Paalanen]

On Mon, 24 Jul 2017 04:07:11 +0200
Roman Gilg <subdiff at gmail.com> wrote:

> Hi,
> 
> I'm working for my GSoC project on a better Present integration in
> Xwayland. This should improve performance as well as minimize tearing. My
> mentor is Daniel Stone and the starting point was my work on KWin and this
> bug report: https://bugs.freedesktop.org/show_bug.cgi?id=99702.
> 
> I'm writing this mail in order to get some feedback from the X.Org
> community regarding my current approach and the progress I've made so far.
> You can find my main working branch at
> https://github.com/subdiff/xserver/tree/presentInXwayland
> 
> I've tried to limit the changes to the Present code to a minimum. At the
> moment it should be able to flip Glamor/GBM Pixmaps of Present supporting
> clients to a Wayland surface for one full screen window without copies. The
> restriction of only one window, which is full screen, is in line with what
> is possible with the currently available functionality by the Present code
> in the Xserver.
> 
> I have tried to queue events on msc timings, but it's not really
> straightforward, since I think we need to read out some sort of Vblank
> counter from the Wayland server instead of the kernel. The frame callback
> is a candidate for that, but it needs at least in my KWin testing
> environment always a previous buffer commit to signal back. I create
> therefore dummy buffer commits, which then trigger the callback after every
> frame if there are events in the queue. This seems to work most of the
> times, but I've problems on window resizing. Apparently in these situations
> it's difficult to pick the right Pixmap and the associated Wayland buffer
> for the dummy commit. So for now I don't allow queuing events, which means
> that Pixmap flips are applied always immediately. What's your opinion? Is
> the construction with the frame callback as a msc counter and the dummy
> commits a bad idea in general or do you maybe know the answer why the
> window resizing is problematic in this context?

Hi,

the frame callback was never intended for "counting vblanks".
Compositors are encouraged to throttle down or completely stop frame
callbacks when the window cannot be seen. Also the definition of the
frame callback is "a good time to start drawing the next frame", which
intends for clients to have the maximum possible time available for
hitting the next deadline for screen. This is an arbitrary point in the
monitor refresh cycle depending on how the Wayland compositor is
scheduling its compositing.

Btw. I would advise against using the frame callback's argument for
anything serious. It is a timestamp in an undefined base and poorly
defined what it might correspond to, and may suffer from wraparound
issues.

Wayland Presentation-time is the extension intended for timing
feedback, and it allows to predict the future presentation times for a
few frames in advance if you can assume a constant frame rate.

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time

I believe there are still some gaps in how to reliably submit frames at
a rate lower than the output refresh rate.

Wayland Presentation-queue was an early companion to Presentation-time,
but did not make it in the protocol due to difficulties in defining it
and existing open issues. That extension would have allowed queueing
frames in the Wayland compositor based on target timestamp.

Another idea talked about a long time ago in relation to
Presentation-time was a vblank feedback stream, where every vblank (at
least the ones the compositor processed) would be signalled to
subscribed clients regardless of wl_surface updates, and without
explicit request for every event. It didn't raise enough interest at
the time.

In any case, Wayland aims for timestamp based presentation, not vblank
counting, because of outputs changing their frequencies (mode switch,
variable refresh rate monitors, ...). The feedback in Presentation-time
is ok for that, but using it for prediction is not guaranteed.
Presentation-queue would have improved the functionality a lot by
helping the Wayland compositor's frame scheduling.

Presentation-time does provide the MSC value though, if it exists.

I think we may need to clarify how Presentation-time should work with
wl_surface.commits that do not change the buffer nor apply damage. If
committed feedback request was guaranteed to deliver feedback
regardless of damage (I recall Weston might already work like this),
that would allow an easy way for a client to sync to the output refresh
cycle. The frame callback OTOH definitely should not be used for this.

Could you maybe start a discussion on wayland-devel@ about clarifying
Presentation-time on commits that do not cause a need to repaint in the
compositor?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170724/33b5f24e/attachment.sig>