Comment 12 for bug 1418081

I do think the new problem brought up in this bug needs addressing, just as the lingering frames also needed addressing.

I would be okay with Alexandros's 'smarter and richer' scene, however, its a bit tricky to limit when we shove the final list of renderables over to the compositors. (eg, we don't want a flurry of renderables being sent to the compositors to sort out when something damages the scene).

I think that the concept of "producing damage in the scene" and "consuming damage in the compositors" clears this up nicely. I also think that we don't have, and haven't had the concept of damage in the proper location in the codebase. (and, prior to and after fix-buffers-ready-for-compositor). We previously had the surfacestack try to track damage without the input of the BufferQueues, and now we're trying to have the surface stack wake up the compositors, and the BufferQueues determine when the compositor goes to sleep.

So, the scene (via the observers, in the current architecture), notifies the compositors that it has been damaged ("produces damage"). The compositor wakes up and calls scene_elements_for(), and "consumes a damage". This has a nicer "produce/consume" model than a "wakeup-and-run-until" that we currently have. The scene can keep producing more damage as it sees fit, and the compositor has to consume all the produced damage before it goes to sleep. (obviously, the damage is a per-display concept, but we already have the concept of registering and deregistering compositors with the scene, so this is okay)