[sugar] frame auto-visibility configuration

[Erik Garrison]

On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote:
> On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <erik at laptop.org> wrote:
> > Hello all,
> >
> > On tabbing we are currently auto-toggling the frame.  Are we sure that
> > this is necessary?  Could we include a configuration option to change
> > this?
> 
> I disagree that showing the Frame is a bad idea.  It emphasizes the
> purpose of the top edge of the Frame, and provides context while
> tabbing so that it's easy to see where you want to "get to".
> 

Do we have observations of how users (students) navigate?  Are they
using the frame to do all navigation (e.g. by pressing the frame button
to reveal it or mousing to a corner)?  Or are they alt+tabbing
everywhere?

> > Drawing the frame animation during tabbing robs us of processor right
> > when we need it, slowing the perceived transition time between windows.
> 
> Drawing the Frame does take a little effort, it's true.  Compositing
> support should later speed this up a good deal.  The current
> reveal/retraction rate of the Frame is at least 2x as slow as I'd like
> it to be, in practice.  Additionally, there *is* a lag on switching
> windows, and this is, actually, part of the reason that I think the
> Frame should be shown.  Without the Frame, we are forced to expose
> each window in the tabbing process, which injects delays into each
> tabbing event.  With the Frame shown, we delay the actual window
> switch slightly so that it's possible to tab quickly past a few
> activities you're not interested in, pausing only at those that you
> want to see in more detail.

I have a system with compositing enabled.  I am using xcompmgr to test.
You can do so by yum-installing xcompmgr, then running it from a
terminal in Sugar via "xcompmgr -d :0.0".

Generally, with compositing managed via xcompmgr, switching is fast
enough that it seems you can tab through several windows in the same
time that it takes to draw the frame onto the screen.  So perhaps the
utility of showing the frame will decrease in such an arrangement, as
users can figure out where they are by hopping around just as quickly as
they could by showing the frame.

It is true that when using composition the frame animation is smoother.
But, as I noted initially, the frame display performance is directly
related to the CPU load on our single processor.  Thus even with
composition enabled the frame animation stutters as other processes
compete for resources.  You just don't get the ugly grey 'undrawn'
blocks on the window which is revealed below.

> > Furthermore, as the XO only has one processor the frame animation (which
> > requires available processor to run smoothly) will skip a lot of frames
> > if the processor is loaded.  As we're auto-saving and re-rendering the
> > windows of every window we pass during tabbing, the processor is
> 
> Saving and re-rendering...could you elaborate?  As I mentioned, the
> point of using the Frame is to *minimize* the number of context
> switches that need to happen.

By "saving" I mean that changes in activity state trigger
Activity.save().  This hits jffs2 and the NAND.

By "re-rendering" I mean that, because we are not compositing each
window is unmapped when we navigate away from it and consequently the
each program has to re-draw its window when we visit it again.

Erik