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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
