[sugar] frame auto-visibility configuration

[Eduardo H. Silva]

Wow, just tried Erik's instructions for using xcompmgr, and it's
amazing how swift the frame slides, and how I don't see any screen
redraws. The experience is totally more fluid. Does it degrade overall
performance? If not much, and if that performance degradation could be
recovered in another area in Sugar (general performanfe improvements),
I'd vote for this to exist in joyride and even part of future stable
builds.

As for the alt-tabbing behavior, I agree that a longer time must be
given before switching to the highlighted activity:
One reason is that at your first alt-tab press, the frame comes up and
you need to move your eyes and atention to its top edge, then
interpret it in your mind, only then will you start thinking of
continuing to alt-tab or to which activity you want to switch too;
Second reason, I think kids will not be as proeficient with the
shortcut as we might be after years of using it (and generally using a
computer), so they will take not only longer to follow the previous
reason, but also take longer to execute the next 'tab' stroke.

Since the default behavior in other desktops is that only when alt is
released does the switch to selected program occur, I would make the
alt-tabbing feature follow this behavior by default, and then also
have the advanced usage of 'on waiting for some period of time the
switch is done'. The exact amount of time I'm not sure which would be,
but I'd be conservative (for the above reasons as well), and make it
at least 2 or 2,5 seconds. This would be the amount of time one takes
to interpret the activity icon, read its primary palette (if indeed
they will be revealed), and then if one wishes, wait for the focus be
switched to that activity to take a full look at it.

I like that if one doesn't want to stay there, he still has the alt
key pressed, and can more conveninetly continue the 'tab'bing process.

Eduardo
2008/9/24 Erik Garrison <erik at laptop.org>:
> 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
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>