Summary: | Windows resized very large suffer poor performance | ||
---|---|---|---|
Product: | Wayland | Reporter: | Brian Lovin <brian.j.lovin> |
Component: | weston | Assignee: | Wayland bug list <wayland-bugs> |
Status: | VERIFIED NOTABUG | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Brian Lovin
2012-10-22 21:28:39 UTC
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.