pretty bad blocker bug which takes multiple commits to fix

[Ray Strode <halfline gmail com>]

Hey guys,

We have a fairly serious blocker bug right now in the new backgroudn
rendering code where we inadventently leak backgrounds.  This means
over time (especially with slide show animations) the shell memory
usage can balloon to gigabytes of memory usage and then die from the
OOM killer.

The bug is here:

https://bugzilla.gnome.org/show_bug.cgi?id=696157

Note it takes multiple fixes to various layers to keep it from behaving badly:

1) a patch to fix GTask usage to unref the task associated with
loading the image from disk. Without this the task is never freed.
2) another GTask-y fix, that makes sure we unref the pixbuf when we're
done with it, since GTask transfers ownership
3) a fix to the cache code to evict old slides when a slide show
changes to the next slide.
4) another cache fix.  This one isn't really a leak fix, but makes the
caching more effective.  We could really go either way on this one I
guess.
5) another cache fix.  If the same image is loaded multiple times at
once, we should only load it once, instead of multiple times in
parallel. This makes the cache more effective, in practice, and
prevents having multiple copies of background data hanging around
unnecessarily.
6) code to reuse shader snippets.  We need this for cogl to free
pipelines we allocate when we tell it to because of internal caching
it does.
7) code to drop blur and desaturate from the api. We don't use them
anymore, and keeping them in the api would complicate the patch for 6)
somewhat.
8) a fix in the clean up handler that can make gnome-shell crash or
hang when freshly created backgrounds get garbage collected.
9) a fix that prevents an exception from being thrown in multiple
backgrounds are changed in quick succession
10) a fix that prevents a background from being freed in some cases
for the workspace thumbnail
11) an unrelated fix that stops an exception from being thrown in some
slide shows.  probably should be on another bug and go in 3.8.1

Colin pointed out this is a lot to go in at once, and I don't disagree
with him. On the other hand background data tends to be big, and so
leaking that kind of data is really bad.  I think we should seriously
consider most of the patches with the exception of 10, and maybe 4 and
5.

--Ray