Merge lp://staging/~sil2100/compiz-core/cherry_rev3137 into lp://staging/compiz-core

Proposed by Łukasz Zemczak
Status: Merged
Merged at revision: 3103
Proposed branch: lp://staging/~sil2100/compiz-core/cherry_rev3137
Merge into: lp://staging/compiz-core
Diff against target: 1474 lines (+856/-67)
15 files modified
gtk/window-decorator/decorator.c (+55/-25)
gtk/window-decorator/events.c (+12/-1)
gtk/window-decorator/gtk-window-decorator.c (+9/-0)
gtk/window-decorator/gtk-window-decorator.h (+8/-0)
gtk/window-decorator/wnck.c (+13/-11)
include/decoration.h (+18/-0)
libdecoration/decoration.c (+86/-0)
plugins/decor/CMakeLists.txt (+3/-1)
plugins/decor/src/decor.cpp (+99/-22)
plugins/decor/src/decor.h (+35/-7)
plugins/decor/src/pixmap-requests/CMakeLists.txt (+62/-0)
plugins/decor/src/pixmap-requests/include/pixmap-requests.h (+188/-0)
plugins/decor/src/pixmap-requests/src/pixmap-requests.cpp (+93/-0)
plugins/decor/src/pixmap-requests/tests/CMakeLists.txt (+15/-0)
plugins/decor/src/pixmap-requests/tests/pixmap-requests/src/test-decor-pixmap-requests.cpp (+160/-0)
To merge this branch: bzr merge lp://staging/~sil2100/compiz-core/cherry_rev3137
Reviewer Review Type Date Requested Status
Daniel van Vugt Approve
Review via email: mp+110572@code.staging.launchpad.net

Commit message

Cherry-picked from compiz trunk (rev 3137):
Add synchronization primitives to the decoration protocol so that there isn't a race where we bind a texture that's being freed. (LP: #454218) (LP: #929989)

Description of the change

Cherry picked from 0.9.8 branch:

Add synchronization primitives to the decoration protocol so that there isn't a race where we bind a texture that's being freed.

Things changed

 * update_window_decoration_size made semi-private, users should use request_update_window_decoration_size instead, which prepares for a pixmap update and sends a message to the decorated process that a new pixmap is waiting.
 * decor_post_pending : tells the decorated process that a new decoration is pending
 * decor_post_request : tells the decorator that a new pixmap can be drawn to
 * decor_post_delete_pixmap : tells the decorator that a pixmap is no longer in use by the decorated process and can be deleted by the server

I also did some necessary refactoring so we could get this under test, namely:

DecorPixmap class (implements DecorPixmapInterface): a simple RAII class which ensures that a DecorPixmapDeletionInterface is invoked to delete the server side pixmap when the DecorPixmap class is destructed

X11DecorPixmapReceiver class (implements DecorPixmapReceiverInterface): a per-decoration owned class which tracks the update state of the pixmap owned by the decoration from the decorator, calls through to appropriate methods on a DecorPixmapRequestorInterface to request new pixmaps (ensuring that chattyness is reduced to when a) the decorator tells us that a new pixmap is ready and b) when a new pixmap was already pending and we need to fetch the newest one)

X11DecorPixmapRequestor class (implements DecorPixmapRequestorInterface): a per-window owned class which handles dispatch to the decorator (eg decor_post_pending) and requests from the decorator in _COMPIZ_DECOR_PENDING messages to communicate when decorations should be redrawn at new sizes

X11PixmapDeletor class (implements DecorPixmapDeletionInterface): a per-pixmap class which sends decor_post_delete_pixmap to the decorator when a pixmap is no longer in use by the decor plugin

DecorationListFindMatchingInterface: an interface implemented by DecorationList to find a decoration matching a specified criteria

DecorationInterface: an interface implemented by Decoration to get the receiver and properties about that decoration.

Tests included (Google Mock)

Resubmitted to cover a potential race condition in LP#996901

To post a comment you must log in.
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I assume the ABI changes here don't affect Unity builds?... Better to ask a silly question now than later :)

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Good question, it seems they actually might. So hm, this cherry-pick might not be entirely safe. Daniel - could you somehow mark bug-fixes in bug reports which break the ABI? This would make picking changes for SRUs much easier.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes, we're meant to update abiversion.h so it should be easy to tell. But people often forget :(

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It works and the bugs appear fixed.

I can't run the test cases for some reason, but that's not caused by this proposal in particular. See bug 1014957.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches