touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #61137
[Bug 1418081] Re: Compositing is triggered continously and needlessly when there are occluded surfaces with available buffers
** No longer affects: mir/0.11
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mir in Ubuntu.
https://bugs.launchpad.net/bugs/1418081
Title:
Compositing is triggered continously and needlessly when there are
occluded surfaces with available buffers
Status in Mir:
Fix Committed
Status in mir package in Ubuntu:
New
Bug description:
Because of recent changes in the way the MultiThreadedCompositor is
triggered (or rather retriggered) [1], when the
DisplayBufferCompositor doesn't render (e.g. because it's occluded) a
non-hidden surface that has available buffers, compositing is
retriggered continuously at full rate, even when nothing else changes
on screen.
To test this, run the proving server:
$ sudo bin/mir_proving_server --compositor-report log
then start a client and drag the client offscreen. The compositor log
should report that the compositor has a frame rate of max(client
frame, FDP) (FDP=value related to our frame droping policy). However,
you will see that it's instead rendering at 60FPS.
As an extreme (but not unusual) example of how problematic this
behavior can be, perform the following:
1. Change an example client to render at ~1 FPS (e.g. add sleep(1) in it's main loop).
2. Perform the previous experiment with that client
When the client surface is visible, the compositor is triggered at a
rate of 1FPS. The same should be true when the surface is dragged off
screen, but instead we get a full compositing rate of 60FPS.
[1] https://code.launchpad.net/~vanvugt/mir/fix-
buffers_ready_for_compositor/+merge/247124
To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1418081/+subscriptions