System Environment: -------------------------- Distro: Ubuntu 12.04 Arch: x86_64 cairo master db488a1703d4ef3bcbd54138b51c01600a2f4d3a dri2proto master 4eeacce4c4a300b938b7e3fb78a8e443c491780b drm master 844d75e5a0b3b8f3466a24256955e886275fb298 glproto master ec1eec4355ee4a6c5134f2178192f10b6d28a87a kbproto master 391a1f6de6315fc0196d407d800597488315cccb libX11 master d45b3fc19fbe95c41afc4e51d768df6d42332010 libxkbcommon master 3477d9e4480f4f2607d371345cc1c09bb8a35c78 macros master 0890e4003aacfa7113ab3f4e3ad7c5636f8e922a mesa master df3721fd2e10ef27ce12a0c1025c9770137fa8f7 pixman master 2e17b6dd4ee7c32684fb7ffc70d3ad3ebf7cb2ef wayland master 0371668dcca5aa29c0fc4b59b974e40bcf073563 weston master 4e07236e8702ff22e2398214a15f7d1e7561caf6 Detailed Description: ----------------------------- This bug is more future proofing than anything else, and I know there is a lot to performance, but this bug is easy to observe. I started weston with a resolution of 2880x1800 (Apple Retina resolution) - specified in weston.ini. I then launched clickdot and resized the window to near max, at the end of this resize performance was noticeably degraded and resizing was choppy. I did this under X11 because I don't have a screen capable of these resolutions. Maybe someone with an ultra high resolution monitor can help out here? Steps to Reproduce: ---------------------------- 0. Modify weston.ini to high resolution (2880x1800 for me) 1. start weston under X11 2. ./clickdot 3. Resize to almost maximum of Weston window, observe that resize performance and clickdot performance is poor.
Oh right, this is most likely due to the resize optimization failing in the toytoolkit (weston's client/window.c). It has a hardcoded "huge buffer size", which is used during resizes to avoid reallocating buffers all the time, which increases performance. However, when you exceed this huge size, it falls back to constantly reallocating buffers, since they do not fit in the huge size. This could also waste memory, if the huge buffer if not released when it's useless, IIRC. A fix would be to implement better heuristics than a hardcoded huge size. Or maybe we could resize (enlarge) an existing buffer to avoid allocating a totally new one?
I'm going to close this a NOTABUG. Rendering window contents efficiently is the job of the toolkit (GTK+, Qt, EFL etc) and rendering library (GL, cairo, pixman, libva etc). The weston sample clients are not written or optimized for performance. Finally, doing this under X also drags X and then X compositor into the picture and at that point it's not clear what we're measuring anymore.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.