Hi James, On 3 May 2016 at 17:29, James Jones <[email protected]> wrote: > Given Wayland is designed such that clients drive buffer allocation
I'd just note that this isn't strictly true. I've personally implemented Wayland support for platforms (media playback on an extremely idiosyncratic platform) where server-side buffer allocation was required for optimal performance, and that's what was done. wl_drm is not exemplary for these platforms as it does not have a protocol concept of a swapchain, but you can add one to your own private protocol implementation (analagous to wl_eglstream) and it works with no changes required to external clients or compositors. > , and I > tend to agree that the compositor (along with its access to drivers like > KMS) is the component uniquely able to optimize the scene, I think the best > that can be achieved is a system that gravitates toward the optimal solution > in the steady state. Therefore, it seems that KMS should optimize display > engine resources assuming the Wayland compositor and its clients will adjust > to meet KMS' suggestions over time, where "time" would hopefully be only a > small number of additional frames. Streams will perform quite well in such a > design. It is unfortunate that you seem to discuss 'Streams' as an abstract concept of a cross-process swapchain which can be infinitely adjusted to achieve perfection, and yet 'GBM' gets discussed as a singular fixed-in-time thing which has all the flaws of just one of its particular platform implementations. I don't see how GBM could really perform any worse in such a design. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
