Performance #3634
Performance #3634
Conversation
|
Some things that I had in mind that could be added (just a rough draft), feel free to use/ignore/edit them as you see fit. Mir splits into multiple threads at some point. One for rendering/compositing, one for input, one for XWayland events, one for Wayland events, etc... (as far as I understand). Focusing on the compositing and input threads, this improves performance (response time) by letting the two threads work independently. For example, the compositing thread might sleep until an application or another thing triggers an update. The input thread on the other hand, sleeps until an event arrives on the socket it listens to, and immediately calls the appropriate handler. This results in updates being delivered as soon as they are requested, and inputs being handled immediately. In the case where two threads might overlap, critical sections are kept as small as possible with attention given to reduce locking overhead and time. Almost all drawing/compositing (except for built-in decorations) is done via GPU if available to reduce CPU load and take advantage of GPUs' better efficiency and speed. |
The performance trade-offs of threading is a vast, contentious, subject and a level of detail I don't think appropriate. |
|
I wouldn't be averse to merging Performance and Energy efficiency into one page, as there's only so much that is different between them… |
AlanGriffiths
force-pushed
the
MIRENG-504-Draft-the-performance-document
branch
from
598130c to
c3c0298
Compare
I presume that's |
Strange, I don't see there being much in common between them 🤷♂️ |
No description provided.