Fwd: Re: [PATCH 0/2] Add New XWayland API

[Axel Davy]

I suggest putting the XWayland API in a separate library.

There's still many things to fix (handling of the cursor for example),
and if we keep XWayland outside of the Xserver, I believe it's going
to be easier to update the API, and eventually break it when
  it is needed.

I've looked closer at dri3 and Present extension, and I think we
should implement in the XWayland API our own Present extension
implementation. The implementation in the Xserver doesn't seem
to fit well to an XWayland model, but the specifications give me
the hope that we could do an implementation specially designed
for XWayland, that will be easier to deal with than the current one.

I like in the Present extension that the client sets a fence to know
when a buffer is free (it corresponds to our buffer release semantic),
  and the options PresentOptionAsync and PresentOptionCopy,
which allows us to know if the client wants a copy, or if we can
send the buffer directly to the Wayland compositor.


Given that we still need some features to support the Present
extension well (get the time at which buffers hit the screen,
cancel a scheduled pageflip, ask for a buffer to hit the screen
at a specific time, etc), I think we should start with my new API
proposal, and replace it (and dri2 support in the DDX), when
we have the materials Wayland side to implement the Present
extension.

Axel Davy

>
> Given the recent discussion on the xorg-devel mailing list,
> I think this new API shouldn't be merged within the X server.
>
> The clear goal of the xorg team is toward dri3, and I was told
> no patch enabling AsyncSwap for dri2 would be merged.
>
> To implement the Present extension and composite efficiently,
> the XWayland API would have to be rewritten anyway. And since
> Present redirection shouldn't make it for X 1.15, but 1.16, it's
> probably better waiting X 1.16 for a XWayland API rewrite.
>
> I will include this API proposal with wlglamor, and add options to use
> AsyncSwap even when vsync is enabled. (and we'll have the choice to
> cap to frame rate or not)
>
> I've tried benchmarking AsyncSwap with the phoronix-test-suite,
> and I was surprised to see a regression with Openarena and Xonotic.
> According to dri devs, it is because, since I do an exchange, the
> application
> is fullscreen and then Weston uses the buffer as scanout buffer, when
> the buffer is
> released and we render again in the buffer, L3 caching is disabled.
> I don't know if there's similar issues with other drivers, but I think
> this is a problem that should be solved, since the problem will occur
> for any fullscreen Wayland applications when bypassing
> compositing is enabled.
>
> It makes more sense in this case to have AsyncSwap support only as an
> option:
> Tearings will go away anyway with it, but for some applications you'll
> have a gain, and
> some others not. When drivers fix this behaviour, it should always be a
> gain.
>
> And since Gnome 3.10 doesn't bypass compositing yet, if I have well
> understood, then
> for them it'll always be a performance benefit.
>
> Axel Davy
>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>