Performance testing was producing inconsistent values at different
times in the day since the GNOME default background is animated and
sometimes has a single layer, and sometimes two blended layers.
So we have consistent numbers, install a simple animated background
with GNOME Shell that has 40-year long transition ending in 2030,a
and set an environment variable in gnome-shell-perf-tool so that the
background is override with that background. (The background depends
on files installed by gnome-backgrounds; we assume that the person
running performance tests is doing so within the scope of a full
GNOME install.)
https://bugzilla.gnome.org/show_bug.cgi?id=734610
We must remove the old image from the cache, not the new one.
This was causing a leak of old (and expensive) background
images, and was causing errors at the end of animations, trying
to destroy the animated background.
When reacting to background settings changes, we may end up queuing
more than one load. The redundant backgrounds are expected to be
destroyed when the previous background has faded out; however since
commit 933f38390b, the tweened actor is the same for all
consecutive load operations and we end up with a single onComplete
handler, ergo a single destroyed actor.
As new backgrounds are always added to the bottom, we are not only
piling up additional background actors, but break changing backgrounds
more than once, as the correct background ends up being covered by
previously added redundant actors.
Fix this by destroying redundant actors right after loading rather
than waiting for the fade animation to complete.
https://bugzilla.gnome.org/show_bug.cgi?id=726120
If we have the following sequence:
cache.getImageContent({ filename: "foo", cancellable: cancellable1 });
cache.getImageContent({ filename: "foo", cancellable: cancellable2 });
cancellable1.cancel();
Then the second load will complete with "null" as its content, even though
it was never cancelled, and we'll see a blank image. Meanwhile, since the
second load simply appends to the list of callers for the second load,
cancellable2 does absolutely nothing: cancelling it won't stop the load,
and it will still receive onFinished handling.
To prevent this from happening, give the actual load operation its own
Gio.Cancellable, which is "ref-counted" -- only cancel it when all the other
possible callers cancel.
Based on work from Jasper St. Pierre <jstpierre@macheye.net>
https://bugzilla.gnome.org/show_bug.cgi?id=722149
At the moment when a file is loaded, we iterate through the list of
pending file loads and ignore any unrelated to the file, then iterate
all the callers of the related file loads and finish them.
In fact, there can only ever be one pending file load related to the
file, and we already know it, so we can avoid the ugly nested loops.
https://bugzilla.gnome.org/show_bug.cgi?id=722149
This commit moves the code around a bit such that the
caller gets allocated up front and then a file load is either
found or created to attach the caller to.
Functionally, the code is the same, it's just now factored in a way
that will make it easier to fix a bug with cancellation later.
https://bugzilla.gnome.org/show_bug.cgi?id=722149
Copying is actually a lightweight operation, so trying to avoid it just adds
code complexity for little gain.
Based on work from Jasper St. Pierre <jstpierre@macheye.net>
https://bugzilla.gnome.org/show_bug.cgi?id=722149
Because we were setting this.background before calling .destroy(),
the call that was meant to destroy the old background was actually
destroying the new one!
https://bugzilla.gnome.org/show_bug.cgi?id=722787
If the background is already removed, or we're trying to remove bad content,
this is probably a bug in content accounting, so let us crash so we can fix
the bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
Stomping on local variables and trying to keep loop state isn't
too fun. Just use a new variable here so we aren't too confused
with what we're doing.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
We don't have any better way of determining whether something is a slideshow
animation, so discriminate on the .xml filename instead of waiting for
gdk-pixbuf to determine whether it can load a file or not.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
We connect to the changed signal in _init() but never actually disconnect from
it. The callback has a reference to "this" which results into the background
object not getting garbage collected.
Fix that leaks by disconnecting in _destroy()
https://bugzilla.gnome.org/show_bug.cgi?id=709263
This fixes a blue background being drawn when switching the monitors
configuration using hardware keys
(clone/multimonitor/external/internal).
The problem is that the shell gather all background loading requests
under the same meta_background_load_file_async call using one
GCancellable (the first one to come). So when the shell receives a
batch of 12 or so XRandr events, it creates 12 new background managers
which end up trying to load 12 times the same background picture. All
of these requests are batched into the same
meta_background_load_file_async using the first GCancellable received
on the first request. Unfortunately, when the first request is
cancelled by the following event indicating a new monitor setup, all
of the background picture requests are dropped on the floor, and
nothing gets loaded (hence the blue screen background).
https://bugzilla.gnome.org/show_bug.cgi?id=703001
Migration from old settings can result in a path instead of URI
there. This is technically invalid, but can easily recognize it
and avoid the crash.
Minor changes by Ray Strode
https://bugzilla.gnome.org/show_bug.cgi?id=702121
if a slideshow file has a really large duration we'll currently
throw an exception.
This bug is aggravated by the fact that some versions of
gnome-desktop use UINT_MAX as a sentinel value to mean,
"don't ever update slide".
This commit treats durations that would overflow as infinitely
long.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
If a background gets requested from the cache while it's still
being loaded from an earlier call, then there will be two concurrent
loads of the same file.
That concurrency is mitigates the effectiveness of the cache and
also causes leaks.
This commit consolidates file loads so that concurrency doesn't
happen.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
BackgroundManager connects to the changed signal in
the backgrounds it manages.
The signal ids for the changed signal connectionss are stored
as state on the background manager object.
If the background being managed changes while the manager
is still loading the old background, then the signal id
variable can get out of sync with the background object being
managed.
This commit ties the signal id to the background objects themselves,
so there is no opportunity for them to desynchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
Normally backgrounds get evicted from the cache when their actor is
destroyed. If the actor changes content without destroying itself,
though, we should evict the old content from the cache, too.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
We currently only add the first instance of a background
to the cache. This means if the actor associated with that
background is destroyed, the content will be evicted and
it will need to get reloaded, even if it's already loaded
on another actor.
This commit ensures every content gets added to the cache.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
We need to look at the duration of the current step of the slideshow
to determine when to next queue an event, rather than the full slideshow
duration.
https://bugzilla.gnome.org/show_bug.cgi?id=695882
Due to weird and strange JS scoping semantics, if we are in a
callback, "i" won't be captured and when the callback is called,
we'll have the wrong index, causing addImage to be called instead
of updateImage.
https://bugzilla.gnome.org/show_bug.cgi?id=695882
The pattern is underneath, so we need to add one. It turns out
that ClutterGroup doesn't care about that, but we need to do this
to remove deprecations in mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=695882
We currently resync the stacking order of the two key frames
every iteration of the animation. This is costly and unnecessary.
This commit ensures they're stacked properly up front and doesn't
touch them after that.
https://bugzilla.gnome.org/show_bug.cgi?id=694993
