We don't need to do this, we can just leave them in the plane list until
they're used.
Also, doing so helps for when we want to move the primary_plane from
the compositor to the outputs in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We're going to move primary planes from compositor to output, so we need
struct weston_plane to precede struct weston_output.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Remove plane->damage and instead accumulate damage on paint
nodes.
This is a step towards allowing multiple overlapping outputs.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tracking the view's plane in the paint node in this way is a step towards
inflicting plane damage from paint node update during the output repaint,
instead of manually doing weston_view_damage_below().
We remove view->plane entirely and do all access through pnodes.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We used to do this through a byzantine path involving the view's plane
transitioning from NULL to primary - but that doesn't work very well
when we want to track the plane in the paint node, because the paint
node will never have a NULL plane state.
This can be removed later when we track damage on paint nodes.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have visibility for views, we can clip that to an output
and store it in paint nodes.
This requires us to split the paint_node_update() function into two,
one for things that need to be done before assign_planes() and
one for after.
This will eventually be useful for tracking damage with paint nodes,
as we'll need to damage a paint node's entire visible area for
some operations.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Pretty cosmetic right now, but make the ALL_DIRTY only contain set
bits, and fix the accidentally sparse bitfield.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is kind of confusing, as the visibility calculation is just a side
effect of the damage accumulation.
At the expense of walking the paint node list another time, make this
a separate function.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Later, we'll want to use the visible region for damage tracking in
paint_nodes. For now, we can use it in the renderers where they've been
calculating it independently to draw paint nodes.
We still can't remove view->clip entirely, because
weston_view_damage_below() may be called before the first render of
a view, when its visible region hasn't been calculated yet. The
clip is empty at that point, which allows weston_view_damage_below()
to "work".
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is when they need to be up to date. And it makes it so that
view_ensure_paint_node() only does what the function name indicates.
Also, later when we tie damage tracking to paint nodes it will make
more sense to update them just in time for the output being repainted.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future we'd like to have multiple overlapping outputs.
weston_output_damage() currently adds damage to the output's coordinates
on the primary plane. This plane is shared between all outputs, so it
would result in damaging more than the intended output.
Eventually, plane damage will go away and be replaced by paint node damage,
and damaging the entire output would involve adding damage to a list of
paint nodes.
Instead, use a flag to indicate the output must be fully redrawn, and add
the damage during the repaint loop.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Right now every backend clears output damage from the primary plane when
it repaints. Instead of having this same operation spread across all
the backends, just do it in the core instead.
In the future, we want to remove damage tracking from the primary plane
entirely, and this is a small step in that direction.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We've just made this impossible, so we can now clean up all the TODO
locations.
I've only turned some of them into assert()s, because they're all mostly
in the same place.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future when we track damage with paint nodes we have a problem when
a paint node is moved off of its output - it immediately stops being
present, so we don't generate damage for the move that placed it off
screen.
We don't want paint nodes to exist when their view isn't on their output
anyway, so let's cull these nodes at the point where we assign outputs to
views.
In the damage-from-paint-nodes future, this will let us properly post
damage when the paint node is destroyed.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Paint nodes should only exist when they're visible.
In the future where we want to track damage with paint nodes we need
this to be enforced, or damage won't properly be tracked when a
paint node is hidden from us but continues to exist.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We want an output's z_order_list to only contain paint nodes for that
output, but until now we've been pretty careless about this.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Notify the shell of the state transition when going from fullscreen to
normal toplevel window.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
The fullscreen state for xwayland surfaces can currently only be
effectively set from the client side. This commit enables
libweston-desktop based shells to properly set the fullscreen state
for xwayland surfaces.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
The output resize handler we only accounts for the background and panel
surfaces, so this handles all other regular shsurfs.
This patch would reuse any previously saved position, or reposition the
surfaces to avoid placing them outside of the output area. For maximized
or fullscreen type of surfaces, issue a new configure event to let
clients react to the new output dimensions.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
We'd need to go over them when handling output resize so use
desktop_shell to hang of the list of shsurfs.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This introduces two helpers, shsurf_is_max_or_fullscreen() and
set_shsurf_size_maximized_or_fullscreen() to handle
maximized/unmaximized fullscreen/unfullscreen transitions.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This makes sure we update min_allocation in situations where the
width and height passed is smaller than the one set previously
(obviously except for the first time). This has the side effect of
not overwriting pending_allocations such that we correctly resize when
passed a width/height smaller the ones set-up in the past.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
View transform parents can be set by anyone. parent_view, on the other
hand, is only set for subsurfaces.
Signed-off-by: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
Derek Foreman