[sugar] [PATCH] screenshots hurt

[Erik Garrison]

On Fri, Sep 05, 2008 at 11:28:17AM -0400, C. Scott Ananian wrote:
> 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.

I desire to antagonize only so far as is necessary to push this issue to
conclusion.  I am trying to be extremely clear and explicit in my
discussion and questions, but I understand that this may appear negative
and request the understanding of those reading the thread.  My
apologies.

> 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.
> 

I think that Riccardo has scripts which could help.  (Riccardo: Could
you please provide a pointer?)

> * 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.
> 

Testing is needed.  I lack resources (time) to do so here (or generally
on my own) and am explicitly requesting help in this via this thread.

> * 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.
> 

Please note that this is exactly what the revised patch does.

Also note that previously we weren't taking screenshots on 'keep' (only
on close); rather the activity.py code expected there to be a steady
stream of screenshots available.  If the user worked solely within one
activity (never navigating away and triggering screenshots) this would
result in a journal entry without a screenshot--- a bug.

> * 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.)

I fully support such work.  Please note that my intention with the
current patch is to remove said functionality until it can be well
tested and its effects on user interaction better understood.

> * 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.

See above discussion, and patches at http://dev.laptop.org/~erik/sugar/,
which take screenshots on keep.
 
> From the strawpoll I took, people around the office here are excited
> about the opportunity to improve sugar performance, and willing to
> sneak it in even though it's really far too late in the 8.2 release
> cycle to be mucking about.  But the combative tone seems to have made
> it difficult for this thread to discover a solution acceptable to
> everyone.  (Not that I'm a master of tact myself!)

Great!

Please understand that I'm not trying to be combatative.  I desire more
design-motivational information and am asking very specific questions to
try to better understand the current design.

Erik