Code review comment for lp:~dandrader/mir/switchingBundle_lp1270964
Revision history for this message
| Alan Griffiths (alan-griffiths) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> > Fortunately I just realized and remembered Mir presently has 0% chance of
> > experiencing the bug. Because our real compositor starts at frame #1.
>
> For what it's worth, I consistently get it with the prototype qml compositor.
Then it could be argued that the prototype qml compositor is buggy - as we now realize know it should not start with frameno = 0.
I'm now tending to the view that 0 is a bad initial value (as it is otherwise reasonable for a compositor to start with this value) and that there ought to be better way to manage frame numbers (e.g. a generator class or just a constant "initial_frameno").
I don't like the proposed test (as discussed above) and the proposed solution feels complex for what is really a poor interface relying on an undocumented convention.