[sugar] [PATCH] screenshots hurt

[C. Scott Ananian]

In informal discussions here at 1cc w/ Chris and Michael, they seemed
very pro- anything-which-makes 8.2 significantly faster.  I think the
general antagonistic tenor of the thread here so far has made it hard
to see what quick fixes we could do to improve performance without
throwing away journal previews.

Here's what *I* would like to see (speaking only for myself):

* Quantitative measurements.  "Switching performance is down to x ms
rather than x ms".  This helps us discuss alternatives rationally
without resorting to "sugar performance *sucks* unless we do X"
mudslinging.

* Thorough testing.  It is possible to launch an activity and close it
without a screenshot ever being taken.  What happens in that case?
Does the journal crash?  Does sugar crash?  We need to have confidence
the effects of suppressing screenshots are small.

* More moderate solutions.  We're currently taking a lot of
screenshots.  Can we quantify what the benefits of taking "fewer"
screenshots without making this into an all-or-nothing discussion?
What if we took a screenshot when the keep button was pressed, when
the activity closed *while it was mapped* (there are ways to close
unmapped activities*, and (say) on window switch and in the background
but no more frequently than every N minutes.  I bet we can find a
compromise which removes a lot of the unnecessary screenshots w/o
removing them completely.

* Unbiased investigation of other alternatives: are we convinced it is
not possible to make the screenshot-taking code faster?  Would
rewriting that code be a lower-risk path to equivalent performance
improvement?  (Quantitative measurements help here, too.)

* A UI-centric evaluation.  What if we (say) only took screenshots
when the user pressed the 'keep' button, and otherwise used the
activity icon. This is a strawman, because the activity icon is, I
believe, already present in the 'details' view in the journal, so this
would add no information.  But maybe someone can think of a lower-cost
generic preview mechanism, or a simple way for *some* activities to
improve their performance by providing an "preview data" callback
which sugar could use in lieu of a screenshot.