Commits on Source (31)
-
Daniel Stone authoredI don't know when this stopped being used, but it's obviously not any more. Signed-off-by:Daniel Stone <daniels@collabora.com>
e9c67aed -
Daniel Stone authored
The only time we need to go through recalculating the surface size is when either the buffer dimensions or the surface transforms have changed. Now that we have dirty flags, use them to avoid a calculation where required. Signed-off-by:160f91b8 -
Daniel Stone authored
Instead of having a bool for whether or not a buffer has been attached in this commit cycle, use a status bitmask. Signed-off-by:8255274a -
Daniel Stone authored
Instead of having an individual bool, reuse the surface state's dirty status for viewport changes. Signed-off-by:6526346b -
Daniel Stone authored
Explain what each member implies. Signed-off-by:3c1e2e5c -
Daniel Stone authored
This is used when a surface is repositioned via offsets. Signed-off-by:d8669679 -
Daniel Stone authored
Both wl_surface.damage and wl_surface.damage_buffer explicitly refer to the 'pending buffer'. wl_surface.attach states that there is no pending buffer after the commit is processed, so it follows that a commit which includes damage but no attach will not process any damage. Change surface-commit processing to ignore all damage unless a buffer was attached in the same commit cycle. (Thanks to @pH5 for his spec analysis which I've just paraphrased here.) Signed-off-by:
eb6d5118 -
Daniel Stone authored
This function is now only ever executed conditionally, so flatten it with an early return. Signed-off-by:63f67f8a -
Daniel Stone authored
This indicates that more than just the content changing, the form of the buffer has changed in a way which may not be like-for-like to the previous buffer but require significant reinterpretation. Examples include the format, opacity, colour state, etc. Signed-off-by:3bba9076 -
Daniel Stone authored
Used when the input region changes. Signed-off-by:0f99e081 -
Daniel Stone authored
This is heading towards being able to materialise subsurface views closer to the source. weston_view_create() - being used only by window-management code - will ultimately create all required subsurface views as well. The internal variant will be used by this and also by the subsurface code as required. Signed-off-by:94a9cc1b -
Daniel Stone authored
View transform parents can be set by anyone. parent_view, on the other hand, is only set for subsurfaces. Signed-off-by:3af596a8 -
Daniel Stone authored
Quoth the spec: A sub-surface becomes mapped, when a non-NULL wl_buffer is applied and the parent surface is mapped. The order of which one happens first is irrelevant. A sub-surface is hidden if the parent becomes hidden, or if a NULL wl_buffer is applied. These rules apply recursively through the tree of surfaces. We currently apply this rule through reconstructing the view_list at repaint time, materialising new views and garbage-collecting unwanted views as appropriate. Since this can be a costly operation, it's best if we move this closer to the source. This makes the core recursively unmap any child views when the parent is unmapped. Future commits will do the same for mapping new views. Signed-off-by:3d9aecc8 -
Daniel Stone authored
Per the wl_subsurface spec: A sub-surface becomes mapped, when a non-NULL wl_buffer is applied and the parent surface is mapped. The order of which one happens first is irrelevant. A sub-surface is hidden if the parent becomes hidden, or if a NULL wl_buffer is applied. These rules apply recursively through the tree of surfaces. [...] If the parent wl_surface object is destroyed, the sub-surface is unmapped. The terminology is kind of loose. My reading of this is that we should 'unmap' (hide from display, remove from input/focus consideration, etc) a subsurface immediately when a parent is destroyed. However, if the child surface is then paired with another parent which is itself mapped, then the child surface should immediately be mapped, because it has a non-NULL buffer already applied, and the parent surface is mapped. By marking the surface as 'unmapped' on parent destroy, we were removing it from the scene graph, but also I think breaking the rules on mapping by requiring another commit when it was reassociated with another, already mapped, surface. Removing the explicit surface unmap leaves the surface in the 'mapped' state, but without any views, which I believe has the intended effect. Signed-off-by:17af1c4d -
Daniel Stone authored
This happens as a part of weston_view_destroy(). Signed-off-by:da8c8f96 -
Daniel Stone authored
Make sure that in a 1 -> 2 -> 3 -> 4 parent->child subsurface nesting, destroying surface 2 also immediately unmaps 3 and 4. Signed-off-by:0189bfac -
Daniel Stone authored
When the destroy signal is fired, child views will disassociate themselves from the parent. This means that we can no longer see what the child views are - and that recursive unmapping does not work. Make sure that views are fully unmapped before anything else happens in destroy, so we can recursively unmap child views. Signed-off-by:0ff72e53 -
Daniel Stone authored
weston_view_geometry_dirty() marks the passed-in view as dirty, as well as all of its children. weston_view_update_transform() updates the geometry of its ancestors, then itself. Users are required (for now) to call weston_view_update_transform() in order to not experience a disappointing amount of death-by-assert. Users do not have a pointer to child views which are magically materialised by the subsurface code. The end result is disappointing. But it is less disappointing if updating the transform for a view the user is actually aware exists, also updates the transform for all its children. Signed-off-by:49b5df7f -
Daniel Stone authored
This is just a consistency check, nothing else. Signed-off-by:fc6d4392 -
Daniel Stone authored
When we're committing anything, return the collected status of what we've just made live, including any changes resulting from subsurfaces having changed. Signed-off-by:ce6afda6 -
Daniel Stone authored
There's no need to go through and rebuild the subsurface list every time. In addition to being unnecessary work, it complicates things like damage tracking. Track a new surface dirty status indicating that the subsurface tree has changed in some way, and only rebuild subsurface stacking when this has occurred. Signed-off-by:c859dd1b -
Daniel Stone authored
weston_view_geometry_dirty_internal() can be used by internal callers to mark a view's internal geometry as dirty, without signaling the need for a full rebuild of the view list. This is a transitional step towards eliminating weston_view_geometry_dirty() from public API. Up until recently, the view-manipulation API has been that users should manually manipulate lists of transforms, layers, and other internal members, then call weston_view_geometry_dirty() as well as manually provoking damage. Now that we have helper functions to handle view manipulation, they still need to mark the view geometry as being dirty. However, most of them do not need to invoke a full rebuild of the view_list, which is only required when views are added or removed from the scene graph, or restacked. weston_view_geometry_dirty() will assume that everything has changed before eventually being ushered out of existence. Signed-off-by:c699253d -
Daniel Stone authored
Most of the time when we're changing things about views, we don't need to throw away the view list and rebuild it from scratch. The only times when we need to do this are when views have been added to or removed from the scene graph, or have been restacked within it. Signed-off-by:bf228370 -
Daniel Stone authored
When we create a new view for a top-level window, also create views for all its children. Signed-off-by:314f2ba0 -
Daniel Stone authored
If a view is in the view list when it's being destroyed, we need to rebuild the view list. However, doing so is currently very hairy as views are created and destroyed at will ... including when rebuilding the view list. In preparation for creating and destroying subsurface views at the time of the action rather than later at repaint time, pull out the immediate view-list rebuild and simply mark the view list as needing a full rebuild. Signed-off-by:f39b1e9f -
Daniel Stone authored
Does what it says on the box: sets the view's alpha, also inflicting damage where required. Signed-off-by:7d2c5e0c -
Daniel Stone authored
They do what they say on the box, and inflict damage where required. Signed-off-by:fc776c3b -
Daniel Stone authored
When we're destroying a parent view, also destroy any of its children which are subsurface views that we've created automatically in the core. Signed-off-by:4b7fb568 -
Daniel Stone authored
When we're linking a subsurface to its parent for the first time, materialise new views for every view the parent has. Signed-off-by:aac90fe4 -
Daniel Stone authored
Now we create subsurface views both when linking to the parent subsurface, and when creating new views for the parent surface, we no longer need to magically materialise new views when building the view list. Signed-off-by:57cd2483 -
Daniel Stone authored
Now that we deterministically create views for subsurfaces, we don't need to stash them away into unused_views to dynamically create and free them at repaint time. Signed-off-by:23ea8655
This diff is collapsed.