#1
I don't like mg::Renderables::buffers_ready_for_compositor(), and am happy to see it going away, but it is a bit entrenched in qtmir, so we should have a way to transition the downstream.
#2
This does circumvent the observer architecture by requiring feedback from the BufferQueues. I see how the arch is wrong in the case described, but before we were telling the compositors to composite so many times, but now we're telling them to composite so many times, and then asking if they really meant it. The BufferQueue doesn't have all the information about how many compositions are needed to drain because of things like position-only-updates, and the BasicSurface cant give the information that is needed to drain the queue completely. Maybe we should improve our concept of 'damage' of the stack, and then have every composition reduce the scheduled damage by one.
#1 ::buffers_ ready_for_ compositor( ), and am happy to see it going away, but it is a bit entrenched in qtmir, so we should have a way to transition the downstream.
I don't like mg::Renderables
http:// bazaar. launchpad. net/~mir- team/qtmir/ trunk/view/ head:/src/ modules/ Unity/Applicati on/mirsurfaceit em.cpp# L446
#2 only-updates, and the BasicSurface cant give the information that is needed to drain the queue completely. Maybe we should improve our concept of 'damage' of the stack, and then have every composition reduce the scheduled damage by one.
This does circumvent the observer architecture by requiring feedback from the BufferQueues. I see how the arch is wrong in the case described, but before we were telling the compositors to composite so many times, but now we're telling them to composite so many times, and then asking if they really meant it. The BufferQueue doesn't have all the information about how many compositions are needed to drain because of things like position-