© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
GOOD IN THEORY:
* Most of the description sounds like steps in the right direction.
* Simplified: Replacing 559 lines of code with 247.
UNSURE ABOUT THE THEORY:
* "composite and opengl now use the geometry last sent to the server"
This should give maximum performance, sure, but what if (for some reason) the server rejects the configure request as being somehow invalid? Would you ever encounter that, like moving a window to an invalid location?
For stability and correctness (which should be the primary goal right now) don't we want "composite and opengl now use the geometry last received from the server"?
* Caveat #1 is not really a caveat. It's the right (intended) design. But if you want to see a (buggy) example of how to solve the chattiness look at the timer code here:
https:/
This was slightly buggy though as it broke keyboatrd-initiated moves (incorrect pointer warp). Simple to fix, probably.
* Still no XFlush's to ensure XConfigureWindow happens immediately. Or are there adequate XSyncs already?
BAD IN THEORY:
* The diff is too big for a mere mortal (who hasn't worked on all the code before) to fully load into their mental interpreter and evaluate its theoretical correctness. Please read that sentence again; it's important.
GOOD IN PRACTICE:
* Window movement is smooth and predictable, but not really better than in oneiric.
BAD IN PRACTICE:
* The bug introduced is worse than the bug being fixed; Window contents offset from the frame/decorations whenever a window is created or maximized.
* All that code, but we still haven't reduced the lag below oneiric-levels. Still not as good as Gnome Shell.
CONCLUSION:
The theory is mostly good but there is at least one serious bug that needs fixing. We probably shouldn't risk 0.9.7.0 any more with large changes like this. We should aim to get this code into a later release when it's more stable, not 0.9.7.0.