Create StImageContent as a simple ClutterImage with preferred width/height
properties in order to be able to use explicit sizing when creating clutter
contents that will be applied to actors whose size depends on the content itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Instead of just passing a scale when getting a cached icon, pass both a
'paint_scale', the scale of which the icon will be painted on the
stage, and a 'resource_scale', the scale of the resource used for
painting.
In effect, the texture size will use the scale 'paint_scale * resource_scale'
in a ceiled value while the size of the actor will use 'paint_scale' when
determining the size.
this would load a bigger texture, but the downscaling would keep the visual
quality.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=765011
Create the surfaces for background shadows at scaled sizes and then draw on them
using logical coordinates, by setting the surface device scale accordingly.
Use the said surface scale when generating the actual shadow cairo pattern
but in such case, to reduce the number of code changes, is better to work in
absolute coordinates, and to do so:
1) Create a temporary shadow-spec copy with scaled values to absolute sizes
2) Invert the scaling on the shadow matrix
3) Do the actual painting in absolute coordinates
4) Set the shadow matrix scaling back to the logical coordinates.
Finally scale down the created shadow pattern surface size when painting it,
applying again a reverse scale to the matrix.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Pass resource-scale to drawing phase, and use it to create texture
surfaces scaled with the widget current scaling.
Also redraw by default widgets when the resource scale changes.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
A fractional resource scale would mean we never use the fast path for
creating the shadow, because we'd cast the int to a float before
comparing, which would never match.
Instead compare the expected texture size with the source texture, to
actually potentially trigger the fast path.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
The fade shader will draw the fade effect up until the border pixel. If
we set the bottom right coordinate to the outer edge of the pixel we
might end up not drawing the fade effect on all of the pixels. This
could for example happen if one logical pixel (clutter stage pixel)
consists of more than one physical pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This commit makes StWidget manage the scale of which its associated
resources should be multiplied with. The resource scale is calculated
by clutter, and is retrieved by clutter_actor_get_resource_scale(). Due
to the resource scale not always being available, the getter may fail,
and the actual widget that draws the content will have to deal with
this situation.
As the resource scale depends on where on the stage the widget is drawn,
the resource scale will in general be available once the widget is
mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Since commit deec0bf255, the texture cache is based on ClutterImage
rather than ClutterTexture. As ClutterImage (like all ClutterContent)
is only concerned with painting, it doesn't influence the size of the
actor it is added to at all, and the returned actor will now stay at
size 0x0 after the image has been loaded.
Set up the actor to follow the content's size instead, to get closer
to the previous behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/402
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
_st_create_shadow_pipeline_from_actor creates shadow pipelines
from actors. This function special-cases ClutterTexture as a
small performance improvement, since we can have access to the
CoglTexture easily with it. However, recent commits removed all
usage of ClutterTexture from GNOME Shell, rendering this optimization
useless. Instead, actors now may have a ClutterImage set as
their content, that can be used instead.
Replace the check for ClutterTexture with a check for ClutterImage,
and use the texture of the image when it is available.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/371
This drops usage of Gtk/X11, replacing it with code that is dependent
of the Clutter backend in use. Another positive side effect is that
the keymap state will now be correct on wayland, since there were no
guarantees that X11 key state would reflect the current reality.
https://bugzilla.gnome.org/show_bug.cgi?id=762881
The last patch in the series, this one adapts StShadowHelper
to received a CoglFramebuffer. This is where we first touch
JavaScript with Cogl types, and as such, it depends on the
latest Mutter. Earlier versions of Mutter didn't have its
Mutter-Clutter GIR to generate types for various Cogl types.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
Same case of the previous patch; _st_paint_shadow_with_opacity()
uses cogl_get_draw_framebuffer(), and this patch makes it receive
a CoglFramebuffer as a parameter instead.
The cautious reader might notice that this commit apparently goes
against the long-term goal, for it introduces more instances of
cogl_get_draw_framebuffer(). This is not wrong, but these introduced
ones will be removed later on, when ClutterActor.paint() receives
a CoglFramebuffer as a parameter instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
This is in preparation for a future where only explicit frambuffer
APIs are available, i.e., cogl_get_draw_framebuffer() does not
exist.
There is absolutely no functional changes in this patch (nor the
following ones in this series), only rearrangements so that various
functions receive a CoglFramebuffer instead of using the draw
framebuffer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
Handling those events is neccessary if a touch event that pressed down a
button turns out to be a gesture. In this case the button should be
released without emitting the clicked signal.
After loading the GdkPixbuf, StTextureCache unconditionally
creates a ClutterImage and, if it's not in the cache, add
it to the cache. That's a waste of resources when the image
is already committed to the texture cache.
Fix that by reusing the ClutterImage of the cache if it is
already there; otherwise, create a new ClutterImage as we
were previously doing.
ClutterTexture is a deprecated class that is simultaneously
an actor, and the content of the actor. Clutter's new model
is to separate painting (via ClutterContent) from actors.
Currently, StTextureCache relies on ClutterTexture to store
the loaded textures. This not only does not match the latest
practices of Clutter, but also generates various compile-time
warnings.
Port StTextureCache to store ClutterImages instead of storing
ClutterTextures. ClutterImage exposes the internal CoglTexture,
so no helpers are needed to match the current StTextureCache
API. Aspect ratio was dropped, but from my testing, it doesn't
change anything.
When computing the effective border color, we operate on colors with
premultiplied alpha to simplify the calculations, then unpremultiply
the result. However we miss a bounds check in the last check, so any
color component can overflow the allowed maximum of 0xff and shift the
result in unexpected ways.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/305
If the actor is not on the stage yet (i.e. does not have a theme
node), but has a paint state cached, we currently fail to invalidate
it, which will lead to the actor painting with old contents once it
gets onto the stage.
This commit fixes the issue by changing our invalidation strategy;
previously we were looking at the widget's own theme node to determine
if it should be invalidated or not.
Now we look at the theme nodes of our cached paint states. When the
widget is mapped on stage, those are the same as the widget's own
theme node, but when the widget is not on the stage, we'll still be
able to invalidate them.
As part of this, we move the invalidation API to StThemeNodePaintState,
which is a more natural place for our use case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/314
In X11, pointer emulated touch events are replicated with normal PRESS, RELEASE
pair events which are generated by the server. Thus for a single tap we get:
- TOUCH_BEGIN -> TOUCH_END, PRESS -> RELEASE
This will cause st-button to send two "clicked" signals, instead of just one,
breaking extensions (like dash-to-dock) that show buttons in the main stage
which will be checked two times or that will receive the same signal two times.
cogl_texture_new() is used in a few places in GNOME Shell, but
it's a deprecated Cogl function. The replacement is the less
verbose cogl_texture_2d_new_with_size(), that is very much a
straightforward replacement.
Remove the few places where this function is used, replacing
it by the CoglTexture2d counterpart.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/287
StTextureCache installs file monitors that invalidate caches when
contents of the underlying file change.
At the moment, the cache uses the Gio.FileMonitorEvent.CHANGED event
type to make that determination.
However, that is suboptimal for at least two reasons:
- while a file is being written to disk, many CHANGED events will be
emitted in sequence. That will cause needless cache invalidations,
and we will risk loading the file before it's fully loaded.
- if an existing file is replaced, e.g. with g_file_replace(), we may
not get a CHANGED event but a CREATED one instead, so the cache ends
up never getting invalidated.
The good news is that in both of those cases GFileMonitor will send a
CHANGES_DONE_HINT event after changes have settled, or after the file
is replaced.
This commit fixes both cases by switching from the CHANGED event to
CHANGES_DONE_HINT to determine that a file has in fact changed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/286
According to Clutter documentation, "[…] actors implementing the
ClutterContainer interface should override the default implementation
of the class handler of this signal and call clutter_actor_destroy()
on their children."
StBin was doing that in GObject:dispose() instead. Move the child
destruction to a new ClutterActor:destroy() vfunc override.
StBoxLayout implements StScrollable, which, semantically, means that
the StBoxLayout size may not match the minimum size reported by the
layout manager. In this specific case, the layout manager by is a
ClutterBoxLayout by default. For example:
+--------------+
| Viewport |
+------+--------------+-----------------+
| | | |
| | | Content |
| | | |
+------+--------------+-----------------+
| |
+--------------+
So, assuming that:
- ContentSize = the minimum size of the content;
- ViewportSize = the allocated size of the viewport;
When allocating StBoxLayout, it must assume ViewportSize, but must
pass ContentSize to the layout manager. That way, the children of
StBoxLayout are correctly placed within it, even if it's bigger than
ViewportSize.
And here's the problem: right now, StBoxLayout assumes ViewportSize
AND also passes it to layout manager. Commit 77c4c6b6d specifically
exposed this bug by relying entirely on StBoxLayout to arrange the
app and window icons.
Fix that by using ViewportSize to allocate StBoxLayout itself, but
passing ContentSize to the layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
All adjustment setter functions take good care of avoiding emission of
notify:: when it's not needed. The set_property() implementation already
calls into the setter functions, so mark the properties as EXPLICITY_NOTIFY
in order to optimize notify:: emission away through g_object_set (rather
common from JS code).
The actor allocation doesn't change per-se, but apply_transform()
will practically transform it. In order to have the paint volume
update accordingly, queue a relayout.
The default get_paint_volume() implementation will do the union
of children, and the child ClutterText paint volume may expand
beyond StEntry size when text overflows.
We actually want all content to be clipped to the StEntry, so
implement get_paint_volume() and tell it so.
And constrain it in StScrollView instead (instead of falling back to an
infinite paint volume, as the actor as paint/pick impls, but no
corresponding get_paint_volume one).
Fixes artifacts with the AppView (and possibly other places) when paint
volumes are aggressively cached.
