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. >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!) --scott -- ( http://cscott.net/ ) _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
