Commit Graph

56 Commits

Author SHA1 Message Date
Bastien Nocera
cd2bd7685a js: Name all the timeouts and idles
With very uninventive names. Names now, good names later.

https://bugzilla.gnome.org/show_bug.cgi?id=727983
2014-04-10 21:08:16 +02:00
Florian Müllner
d6197b0904 background: Destroy redundant backgrounds right after loading
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
2014-03-15 00:43:15 +01:00
Ray Strode
55d1c7e2ab background: fix cancellable issue
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
2014-03-12 12:15:43 -04:00
Ray Strode
fdf264ff64 background: get rid of nested loop when finishing file loading
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
2014-03-12 12:15:42 -04:00
Ray Strode
e917b7ce0f background: refactor file loading
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
2014-03-12 12:12:47 -04:00
Ray Strode
ec6facb9e7 background: always copy background content when loading into cache
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
2014-03-12 12:12:47 -04:00
Giovanni Campagna
816f5162f9 BackgroundManager: don't destroy the newly created actor
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
2014-01-22 20:35:02 +01:00
Jasper St. Pierre
d3905734c1 background: Remove unused argument 2014-01-13 20:17:57 -05:00
Jasper St. Pierre
933f38390b background: Don't require passing in a background to _updateBackground()
To make debugging background issues easier.
2014-01-13 17:14:58 -05:00
Florian Müllner
751a3f0e94 js: Use SOURCE_CONTINUE/SOURCE_REMOVE constants in source functions
With support for boolean constants in g-i, we can finally use the
more readable constants instead of true/false.

https://bugzilla.gnome.org/show_bug.cgi?id=719567
2013-12-16 18:27:19 +01:00
Jasper St. Pierre
01f740ce69 background: Don't prematurely remove file monitors
We need to only remove file monitors when there's no other users
of the content...
2013-12-13 11:50:17 -05:00
Jasper St. Pierre
7249b11899 background: Don't silently fizzle out when removing bad content from the cache
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
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
4cfb000812 background: Add copied content from pending image loads to the cache
https://bugzilla.gnome.org/show_bug.cgi?id=719803
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
5262a41619 background: Clarify the intent of the code
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
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
887590730d background: Simplify animation code
https://bugzilla.gnome.org/show_bug.cgi?id=719803
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
adb49bdf0b background: Remove unused variable
https://bugzilla.gnome.org/show_bug.cgi?id=719803
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
7f3aadc157 background: Remove the system noise content when not in use
https://bugzilla.gnome.org/show_bug.cgi?id=719803
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
eb1c85f3f5 background: Don't wait for gdk-pixbuf to fail before loading animations
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
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
dbdc884c96 background: Remove more bogus checks
The content in these arrays can never be null...

https://bugzilla.gnome.org/show_bug.cgi?id=719803
2013-12-03 19:13:12 -05:00
Jasper St. Pierre
04ea95049a background: Fix the check for spanning backgrounds
this._monitorIndex does not exist, and neither does
MetaBackground.monitor_index...

https://bugzilla.gnome.org/show_bug.cgi?id=719803
2013-12-03 18:36:46 -05:00
Rico Tzschichholz
d519c7263e Background: Drop "saturation" related source
"saturation" was removed from MetaBackground in mutter with
https://git.gnome.org/browse/mutter/commit/?id=0e589061
2013-10-23 21:37:27 +02:00
Adel Gadllah
8b0e846e0e background: Disconnect settings signal handler on destroy
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
2013-10-02 15:43:30 +02:00
Rico Tzschichholz
7f1b07b76f Revert "Background: Drop "saturation" related source"
This reverts commit 2f35ad6e65.
2013-09-18 13:54:54 +02:00
Rico Tzschichholz
2f35ad6e65 Background: Drop "saturation" related source
"saturation" was removed from MetaBackground in mutter with
https://git.gnome.org/browse/mutter/commit/?id=0e589061
2013-09-18 13:49:35 +02:00
Giovanni Campagna
4413f816e6 Background: allow passing the settings schema from outside
This way it is possible to use different settings for different
backgrounds.

https://bugzilla.gnome.org/show_bug.cgi?id=688210
2013-08-20 14:11:44 +02:00
Adel Gadllah
062235f3a7 Revert "background: fix asynchronous management of background loading operations"
This reverts commit 1020d8a0f8.

https://bugzilla.gnome.org/show_bug.cgi?id=704646
2013-08-16 21:32:52 +02:00
Lionel Landwerlin
586ebcd5be background: fix asynchronous management of background loading operations
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
2013-07-03 17:03:02 +01:00
Giovanni Campagna
798a0ca240 Background: don't require a URI scheme for picture-uri
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
2013-06-18 10:55:52 -04:00
Ray Strode
0376f22d41 background: stop monitoring file after removing from cache
https://bugzilla.gnome.org/show_bug.cgi?id=697395
2013-04-06 10:45:53 -04:00
Ray Strode
e98c6ff31b background: when updating image remove old one from cache
We're removing the new content from the cache instead of the
old content.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=697395
2013-04-06 09:44:51 -04:00
Ray Strode
9eae74357a background: don't leak background objects during quick changes
We currently let some backgrounds "fall through the cracks" if
a bunch of change notifications come in at once.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=697395
2013-04-06 09:44:50 -04:00
Ray Strode
78e011d558 background: fix multimonitor background placement in overview
This is like the previous commit but for monitor index, instead
of effects.

https://bugzilla.gnome.org/show_bug.cgi?id=696712
2013-03-27 12:13:47 -04:00
Ray Strode
76590d6c69 background: fix vignette in overview
We no longer apply background effects when loading backgrounds.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=696712
2013-03-27 12:09:02 -04:00
Ray Strode
1dadcee5c9 background: don't choke on huge slide show durations
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
2013-03-26 17:02:05 -04:00
Ray Strode
bed3bb45f7 background: don't load the same image more than once concurrently
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
2013-03-26 17:02:05 -04:00
Ray Strode
f920fd8b6f background: properly disconnect background signals
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
2013-03-26 17:02:05 -04:00
Ray Strode
b9da6d9ef6 background: When updating actor content, evict old content from cache
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
2013-03-26 17:02:04 -04:00
Ray Strode
3be489c69e background: always add content to cache
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
2013-03-26 17:02:04 -04:00
Jasper St. Pierre
5fecd07045 background: Look at the duration per-step
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
2013-03-14 17:48:07 -04:00
Jasper St. Pierre
8edd7ad32e background: Fix a bug with empty animations
Arrays always evaluate to true, even empty arrays,
so we need to check the length to make sure we have
no files.

https://bugzilla.gnome.org/show_bug.cgi?id=695882
2013-03-14 17:48:07 -04:00
Jasper St. Pierre
3a27d0b849 background: Keep the state of key frame files on Animation
This gets us from a mix of pure getters and class state
to just class state.

https://bugzilla.gnome.org/show_bug.cgi?id=695882
2013-03-14 17:48:07 -04:00
Jasper St. Pierre
b351536dee background: Rename animationUpdate to updateAnimation
This is more consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=695882
2013-03-14 17:48:07 -04:00
Jasper St. Pierre
eeea8559b6 background: Fix math to calculate the interval from the duration
The math here before was incorrect. This is still wrong, as we're
looking at the total duration of the animation rather than the next
step.

https://bugzilla.gnome.org/show_bug.cgi?id=695882
2013-03-14 17:48:07 -04:00
Jasper St. Pierre
17591117c1 background: Fix updating existing images that need loading
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
2013-03-14 17:48:07 -04:00
Jasper St. Pierre
c4470fd1e6 background: Set the correct index on images
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
2013-03-14 17:48:07 -04:00
Ray Strode
020128b9ca background: don't use raise_top() since it's costly
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
2013-03-05 16:03:12 -05:00
Ray Strode
96387cce47 background: drop StillFrame class
We aren't using it anymore so nix it.

https://bugzilla.gnome.org/show_bug.cgi?id=694326
2013-03-02 17:44:26 -05:00
Ray Strode
570fc68cb1 main: put noise texture below startup animation, not still frames
Right now we take a still frame of the desktop before showing the
start up animation.  This gives us an animation over what was
there before startup.

That's not actually desirable when restarting the shell.  We don't
want to animate over undecorated windows, we really want to animate
over the noise texture.

This commit drops the still frames in favor of the noise texture.

https://bugzilla.gnome.org/show_bug.cgi?id=694326
2013-03-02 17:44:26 -05:00
Giovanni Campagna
d5e647a191 ScreenShield: fix positioning of background with multimonitor
Previously, we would create one StBin per monitor, but each was positioned
at 0,0 and sized as the screen, so they would overlap and draw the box shadows
on top of the other backgrounds.
Instead, we need to size appropriately the bin, and then we need to position
the actual MetaBacgroundActor at 0,0, so add a flag to BackgroundManager
for this.
Also, get rid of MetaBackgroundGroup, they do nothing because the screenshield
is not a descendant of the MetaWindowGroup and because the widget in between
blocks the propagation of the visible region. At the same time, use a
widget, not a bin, because StBin requires you to set .child, not call add_child().

https://bugzilla.gnome.org/show_bug.cgi?id=694394
2013-02-25 14:46:40 +01:00
Giovanni Campagna
6fcc7e3e23 Background: don't check draw-background key
The key was removed from gsettings-desktop-schemas, GNOME should
always draw a background: the key existed to support xsetroot, but
we no longer read the _XROOTPMAP_ID.

https://bugzilla.gnome.org/show_bug.cgi?id=694463
2013-02-22 17:49:16 +01:00