Created by Brandon Schaefer on 2013-02-27 and last modified on 2013-02-27
Get this branch:
bzr branch lp:~brandontschaefer/compiz/lp.1034616-fix
Only Brandon Schaefer can upload to this branch. If you are Brandon Schaefer please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Brandon Schaefer

Recent revisions

3624. By Brandon Schaefer on 2013-02-27

* Use serverWindows instead of windows to get a more up-to-date stacking order.

3623. By Sam Spilsbury on 2013-02-26

Allow plugins to throttle delivery of ConfigureWindow requests within reason (LP: #1027211)

(LP: #1027211) seems to be caused by vsync in the nvidia driver and posting lots of ConfigureWindow requests to the server. The driver really chokes on these for some reason. As a result, two things were happening:

1. The driver slows down quite significantly
2. We get more time to post more ConfigureWindow requests to the driver, which just slows it down even more until it grinds to a halt.

This branch does three things:
1. Introduces infrastructure for plugins to hold a "lock" on delivering ConfigureWindow requests until they choose to release it later (eg, on paint, or on ungrab), while still allowing core to override the plugin's decisions in cases where we actually need to post a ConfigureWindow request to the server in order to continue (eg, some other request is dependent on it). That code was TDD'ed into existence and has test coverage.
2. Optimizes reconfigureXWindow to only configure the frame window if the only thing that happened was that we moved the window. This means that we only buffer up one ConfigureWindow instead of three per call to reconfigureXWindow
3. Implements ConfigureRequestBuffer in both opengl and move. The default implementation in "opengl" is the "safe" version and releases its lock every time the window paints. That means that dragging around opengl rendered windows goes from a complete halt to a steady 12fps. In the move plugin, I've revived "lazy positioning" - off by default as it might be more unsafe, but this prevents all ConfigureWindow requests from being posted until the window is ungrabbed. That goes brings us from 12fps to 60fps.

Approved by Brandon Schaefer.

3622. By PS Jenkins bot on 2013-02-26

Releasing 1:0.9.9~daily13.02.26-0ubuntu1 to ubuntu.

Approved by PS Jenkins bot.

3621. By serveralex on 2013-02-26

Fixed infinite loop in InotifyScreen::processEvents ().
wIter needs to be increased here.
Credits and thanks for this patch go to serveralex !

(LP: #773564). Fixes: https://bugs.launchpad.net/bugs/773564.

Approved by Sam Spilsbury.

3620. By danilo on 2013-02-25

Fixed missing icons and text in CCSM main screen.
Credits for this fix go to danilo, thanks a lot !

(LP: #1130941). Fixes: https://bugs.launchpad.net/bugs/1130941.

Approved by Sam Spilsbury.

3619. By Sam Spilsbury on 2013-02-22

Fix startup issues

Amalgamated changes:

0. Re-set the setting parents correctly after an upgrade
1. Move the backend loading and config file handling code into separate objects, we need to inject them by interface in order to isolate CCSContextDefaultImpl for testing
2. Add the ccp plugin to "initialPlugins" rather than setting the option directly, that never worked.
3. Added some framework to force-import any profile available in the system config dirs and not reported as existing by the backing. This is so that we have a guaruntee that we will get its values
4. Bail out correctly when a schema couldn't be found

(LP: #1130679). Fixes: https://bugs.launchpad.net/bugs/1130679.

Approved by Brandon Schaefer, PS Jenkins bot, Łukasz Zemczak.

3618. By Sam Spilsbury on 2013-02-21

Redesign the optional pixmap deletion protocol to make the consumer responsible for deleting the pixmaps.

The previous optional protocol had the consumer send a message back to the producer when a pixmap was ready to be deleted, and then the producer would take it from its pool of pixmaps marked for deletion and delete it there. That protocol did not really work out in practise though, because of a race condition where the consumer would never become aware of a new pixmap (because the new pixmap value was read synchronously instead of delivered asynchronously) and then that pixmap would just sit there in the consumer's memory and never be deleted. The new optional protocol makes the consumer responsible for freeing the pixmap once the producer has marked it ready for deletion. That way the consumer can keep on using the pixmap until it needs to delete it. This is important on drivers that use loose binding, because the texture contents are undefined as soon as the pixmap is freed on the server side.

In order to represent that, there were a few new objects added. The first is a "communicator" object which handles all of the requests that come from the decorator through ClientMessage events and dispatch to the right place. The next are the individual message handlers, which determine whether or not the pixmap can be deleted immediately or if it should go into the pixmap release pool. The final is the release pool, which stores in-use pixmaps in a list which can then be marked for deletion when the texture they are bound to goes away.

Unit and Integration tests were added to demonstrate the code and protocol behaviour.

(LP: #1119608). Fixes: https://bugs.launchpad.net/bugs/1119608.

Approved by Brandon Schaefer, PS Jenkins bot.

3617. By Sam Spilsbury on 2013-02-19

Enable copytex by default and stick the upgrades in the right place

(LP: #1130160). Fixes: https://bugs.launchpad.net/bugs/1130160.

Approved by Michael Terry.

3616. By Sam Spilsbury on 2013-02-19

Make sure to update the frame extents when clients ask us to (LP: #1110138). Fixes: https://bugs.launchpad.net/bugs/1110138.

Approved by Andrea Azzarone, PS Jenkins bot, MC Return.

3615. By Michael Terry on 2013-02-19

Fix order of some manually-entered changelog entries.

Approved by Didier Roche.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
This branch contains Public information 
Everyone can see this information.