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>
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>
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>
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: Daniel Stone <daniels@collabora.com>
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: Daniel Stone <daniels@collabora.com>
Instead of passing an output to weston_compositor_build_view_list(),
have it set up all the output z_order_lists at once.
This is a preamble for MR !1285 which wants to maintain a compositor
wide dirty bit for the view list.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Moves the output specific stuff into one place, after the view_list is
already properly set up.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
A video mode change would be needed to change the underlying renderer
framebuffer. All other backends make uses of this so let's do it for the
DRM-backend as well.
This would also be needed for the output capture to function properly as
we need call weston_output_update_capture_info() when a new mode set has
set. Otherwise we'd run into mismatched dimensions for the current mode
versus the dimensions set-up initially in weston_output_capture_source_info.
Signed-off-by: marius vlad <marius.vlad@collabora.com>
Turn the Pixman/GL if/else conditionals into switch cases to make it
easier to add support for other renderers in the future.
Also makes sure that weston --backend=wayland --renderer=noop fails
with an error message instead of segfaulting.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Turn the Pixman/GL if/else conditionals into switch cases to make it
easier to add support for others renderer in the future.
Also makes sure that weston --backend=x11 --renderer=noop fails
with an error message instead of starting with the GL renderer.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
There are some cases in which we are seeing segment breaks like this in
the debug scopes: (0.00, 0.00]. A segment whose domain goes from 0 to 0
makes no sense.
This happens because we are printing the breaks with only two decimal
places. Increase that to four, in order to have more accurate
information in the debug scopes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There's a case we were missing when printing the tone curves: the ones
with zero segments.
These are 16-bit sampled curves. Start taking them into account.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If backend initialization fails, weston_compositor_shutdown() is called
twice, once right away in weston_compositor_load_backend(), and once in
weston_compositor_destroy().
Remove the first and fix a segfault when trying to weston_plane_remove()
the primary plane a second time.
Fixes: 90c11cf40e ("libweston: move weston_compositor_shutdown call out of backends")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This will help us to debug our color pipeline optimizer without the
need to craft special ICC profiles for that. In this initial patch,
we are able to add matrices and curve sets to the pipeline and assure
that the optimizer is doing the right thing.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
At the moment, when we merge two curve sets it becomes a sampled one.
With this change, we start merging power-law curve sets and keeping them
as parametric, as we'd rather have a parametric curve than a sampled
one.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
At the moment, when we merge curves we transform them into sampled
curves, even if they were parametric before.
If we have two inverse parametric curve sets in sequence in the color
pipeline, we can drop them both, as merging them would result in the
identity curve. If we don't do that and merge the resulting identity
with another curve set, we'll end up with a sampled curve.
Start dropping inverse curve sets in sequence. This change help us in
the following scenarios:
pipeline:
curve set A, curve set B (inverse of A), curve set C (parametric)
Merging A and B results in identity, and merging that with C results in
a sampled curve. With our changes, we end up with curve set C intact,
and we'd rather end up with a parametric curve than with a sampled one.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
