Re: [sugar] Composition -- we've been here before!
On Wed, Sep 24, 2008 at 09:45:44PM -0700, Bert Freudenberg wrote: > At least this one has been fixed 4 months ago. Sure. I brought it up because, to me, it serves as a useful reminder of the careful regression test that enabling composition will require and of how few people really understand how the XO's graphics code works. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Composition -- we've been here before!
Am 24.09.2008 um 16:46 schrieb Michael Stone: > Folks, > > We've been over this ground before -- have any of the old bugs been > fixed? > [...] > http://dev.laptop.org/ticket/6759 At least this one has been fixed 4 months ago. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Congrats to Telepathy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Congratulations are in order, I think, for the Telepathy developers. Gnome 2.24 was just released, and from http://library.gnome.org/misc/release-notes/2.24/ """ GNOME 2.24 announces the inclusion of an instant messaging client based off the Telepathy communications framework. Empathy also supports XMPP/SIP audio and video conferencing as available on the Nokia N800/N810 devices (video requires H.263 codecs for GStreamer to be installed). Empathy is a great companion to Ekiga, GNOME's audio/video SIP client (see Section 2.3 ― Ekiga 3.0). Telepathy provides a common framework for applications to access instant messaging functionality. It can utilise many common protocols including Jabber/XMPP, Google Talk, MSN Messenger and Apple's Bonjour/Rendezvous local network chat. Any application is able to utilise the instant messaging session. As well as the Empathy client, GNOME 2.24 provides libraries enabling developers to add presence and status information, transfer files or set up sockets (known as Tubes) for collaboration and games over the Internet. See Section 4.4 ― Instant Messaging Libraries for more information on how this technology can be utilised in your application. """ In other words, Telepathy is now a bona fide upstream project, and will likely soon have many more non-Sugar users than Sugar users. This is good news for us. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjax6wACgkQUJT6e6HFtqQWrgCfd+XMuimmRxI6G3et5qCPGRAH w9YAnRqTHrtqvb5bblSEuRA+enmjk15m =jxL1 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] Calculate 25
Am 24.09.2008 um 15:54 schrieb Gary C Martin: > Not sure why but for me SW update is not picking up v25 (I have v24 > installed). I checked the wiky Activities page but you seem to have > that set fine (SW update looks there by default). I'm wondering if > your update_url = http://dev.laptop.org/~rwh/calculate content is > working correctly. That page does not have the special markup required by the updater. This is explained here: http://wiki.laptop.org/go/Activity_microformat - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] Calculate 25
Hi Reinier, On 24 Sep 2008, at 22:20, Reinier Heeres wrote: > Hi, > > I released a new version of Calculate, it's available at: > > http://dev.laptop.org/~rwh/calculate/Calculate-25.xo > > Sources are at: > > http://dev.laptop.org/pub/sugar/sources/calculate-activity/Calculate-25.tar.bz2 > > NEWS entries: > > * Spell 'license' correctly > > Regards, > > -- > Reinier Heeres Not sure why but for me SW update is not picking up v25 (I have v24 installed). I checked the wiky Activities page but you seem to have that set fine (SW update looks there by default). I'm wondering if your update_url = http://dev.laptop.org/~rwh/calculate content is working correctly. I've not tried that mechanism yet, I've just been playing it safe and relying on the default Activities page search. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
Just to follow-up with trying it, while at first the feeling of using composition was of a more responsive system, I did see performance degrade as I launched more activities and used it more. The saving grace was that there never was any ugly visual redraws (other than when a new activity is launching). Plus, there are a few bugs, like new activities launched after composition is turned on show their text in a smaller size (like in Browses address bar, and in its Back button palette). Eduardo 2008/9/24 Marco Pesenti Gritti <[EMAIL PROTECTED]>: > On Wed, Sep 24, 2008 at 8:56 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: >>> I'd vote for activating composition ASAP once we have a 9.1 joyride >>> branch and see how we can find the sweetest spot between speed and >>> memory usage. >>> >> >> I agree. >> >> There also may be bugs which we need to shake out. If this is a feature >> we know we want for 9.1, the sooner we start testing the better. > > Personally I think we should first try to debug our graphic > performance and see what is slow and if we can do anything about it. > > Marco > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 7:51 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > AFAIK, the only tradeback (and the reason why it hasn't been activated > yet) is that we must pay composition with increased memory usage. > Composition basically saves us unnecessary redraws by keeping in > memory copies of the windows contents. Note that this is video memory, so it's not a simple tradeoff between system memory and performance. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Wed, Sep 24, 2008 at 8:56 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: >> I'd vote for activating composition ASAP once we have a 9.1 joyride >> branch and see how we can find the sweetest spot between speed and >> memory usage. >> > > I agree. > > There also may be bugs which we need to shake out. If this is a feature > we know we want for 9.1, the sooner we start testing the better. Personally I think we should first try to debug our graphic performance and see what is slow and if we can do anything about it. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Wed, Sep 24, 2008 at 9:11 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > Bernie has talked about some wm hints that can be set on windows so > they get unredirected and thus their offscreen pixmaps released. Not > sure if matchbox would support them, though. > > Related with all this is the decision to switch window managers. > > Perhaps keeping redirected just the two activities on top of the stack > plus the desktop window may be enough? I think that would mean a > constant 12MB, approx. If I understood Bernie explanation correctly, using so much video memory would have bad effects on the general performance of the system. (Other things will be kicked out of system memory and will slow down graphics performance). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] Calculate 25
Hi, I released a new version of Calculate, it's available at: http://dev.laptop.org/~rwh/calculate/Calculate-25.xo Sources are at: http://dev.laptop.org/pub/sugar/sources/calculate-activity/Calculate-25.tar.bz2 NEWS entries: * Spell 'license' correctly Regards, -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 4:36 PM, Walter Bender <[EMAIL PROTECTED]> wrote: > of an issue than resolving incompatibilities between libraries (The > Gimp pulls in all sorts of stuff and Inkscape tries to pull in > incompatible libraries, such as an old version of poppler), No longer the case. > incompatibilities with where we'd like applications to write data (The > Gimp will stomp all over the filesystem), moving data to and from the > Journal (how do I open an image I took with Record in The Gimp? or use > a picture I edited with The Gimp in Memorize)? The fact that The Gimp See the thread I've started on resolving these issues. > uses lots of little auxiliary windows is easily dealt with in, for > example, the X Activity. Making this seamless in Sugar seems, IMHO, a > relatively low priority relative to these other inconsistencies. In my opinion, fixing the barriers that prevent developers from dogfooding sugar is of high importance. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Erik introduced the Journal/datastore to this thread about modifying the approach Sugar has taken to WM in order to better support legacy applications, The Gimp being everyone's favorite example. I am simply suggesting that the WM is--while not the least of our problems--less of an issue than resolving incompatibilities between libraries (The Gimp pulls in all sorts of stuff and Inkscape tries to pull in incompatible libraries, such as an old version of poppler), incompatibilities with where we'd like applications to write data (The Gimp will stomp all over the filesystem), moving data to and from the Journal (how do I open an image I took with Record in The Gimp? or use a picture I edited with The Gimp in Memorize)? The fact that The Gimp uses lots of little auxiliary windows is easily dealt with in, for example, the X Activity. Making this seamless in Sugar seems, IMHO, a relatively low priority relative to these other inconsistencies. -walter On Wed, Sep 24, 2008 at 4:26 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: >> >> We all agree that the datastore needs serious attention, although it >> doesn't directly impact the running of legacy activities. Rainbow is >> an issue. And moving data back and forth between Sugar and legacy apps >> is an issue. > > Please say more. > > Thanks, > > Michael > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: > We all agree that the datastore needs serious attention, although it > doesn't directly impact the running of legacy activities. Rainbow is > an issue. And moving data back and forth between Sugar and legacy apps > is an issue. But I'll argue the WM is a relatively minor issue in > these respects. What legacy applications and activities are you referring to? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: >We all agree that the datastore needs serious attention, although it >doesn't directly impact the running of legacy activities. Rainbow is >an issue. And moving data back and forth between Sugar and legacy apps >is an issue. Please say more. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] alt-tabbing to the Journal
A thought which has come up a few times in my exploration of activity switching performance, and a few times in conversations on the sugar list, is that the Journal shouldn't be included in the set of activities which can be alt+tab'ed to. The most compelling rationale is that there is already a dedicated button on the keyboard for it (F1). Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Tue, Sep 23, 2008 at 9:17 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > Well. It's off-topic. > > I guess it came to mind because the Journal and datastore are a point of > incompatibility between Sugar and the rest of the Linux desktop world. > > Erik > > On Tue, Sep 23, 2008 at 08:16:25AM -0400, Walter Bender wrote: >> Could you please elaborate on what the behavior of the Journal has to >> do with this thread? >> >> -walter >> >> On Mon, Sep 22, 2008 at 2:52 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: >> > On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: >> >> My impression, based on historical conversations with the parties >> >> involved is that there are a bunch of hackers who feel that we did >> >> ourselves a disservice by dropping _so much_ backwards compatibility, >> >> specifically with Unix filesystems and desktops, in exchange for >> >> cool ideas. The feeling is that had we traded compatibility for features >> >> less aggressively then there would be many more hackers available to >> >> help write the features since there would be many more hackers who felt >> >> it was possible to live within Sugar. >> >> >> >> This is just an impression, however. >> > >> > For what it's worth, it is also my impression. I have heard similarly >> > from virtually all technically-oriented parties involved. I have heard >> > echos of this from less technical users (e.g. teachers who are confused >> > by the behavior of the journal). >> > >> > Erik >> > >> >> >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org > We all agree that the datastore needs serious attention, although it doesn't directly impact the running of legacy activities. Rainbow is an issue. And moving data back and forth between Sugar and legacy apps is an issue. But I'll argue the WM is a relatively minor issue in these respects. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Wed, Sep 24, 2008 at 9:31 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Thu, Sep 25, 2008 at 12:43:02AM +0530, Sayamindu Dasgupta wrote: >> >> FWIW, sometime back, I did some benchmarks with a composite enabled >> Metacity - results at >> http://www.mail-archive.com/sugar@lists.laptop.org/msg03613.html >> Jim had suggested some memory saving tricks at >> http://www.mail-archive.com/sugar@lists.laptop.org/msg03647.html > > Thanks. > > I'm going to try out Jim's suggestion: > > On Thu, 05 Jun 2008 08:38:59 -0700, Jim Gettys wrote: >> For composition to not eat memory (a full frame buffer's >> worth/activity), the buried windows need to be "unmapped" in X parlance. >> When a window is unmapped, X can free the contents of the window even >> when composite is running (IIRC). > > We have gtk.Window.unmap() to play with. > > The difficult question is how to signal the activities to unmap > themselves. I suppose we could follow the pattern currently used to > trigger auto-saves. I think that if you iconify a window, it will be unmapped by the window manager. I believe (not sure though) that wnck.Window.minimize() will iconify it, that can be called from the shell. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Thu, Sep 25, 2008 at 12:43:02AM +0530, Sayamindu Dasgupta wrote: > > FWIW, sometime back, I did some benchmarks with a composite enabled > Metacity - results at > http://www.mail-archive.com/sugar@lists.laptop.org/msg03613.html > Jim had suggested some memory saving tricks at > http://www.mail-archive.com/sugar@lists.laptop.org/msg03647.html Thanks. I'm going to try out Jim's suggestion: On Thu, 05 Jun 2008 08:38:59 -0700, Jim Gettys wrote: > For composition to not eat memory (a full frame buffer's > worth/activity), the buried windows need to be "unmapped" in X parlance. > When a window is unmapped, X can free the contents of the window even > when composite is running (IIRC). We have gtk.Window.unmap() to play with. The difficult question is how to signal the activities to unmap themselves. I suppose we could follow the pattern currently used to trigger auto-saves. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Thu, Sep 25, 2008 at 12:26 AM, Erik Garrison <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 07:51:30PM +0200, Tomeu Vizoso wrote:
>> On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva <[EMAIL PROTECTED]> wrote:
>> > 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.
>>
>> AFAIK, the only tradeback (and the reason why it hasn't been activated
>> yet) is that we must pay composition with increased memory usage.
>> Composition basically saves us unnecessary redraws by keeping in
>> memory copies of the windows contents.
>>
>> Martin Dengler did back in March an excellent job quantifying this tradeback:
>>
>> http://lists.laptop.org/pipermail/sugar/2008-March/004718.html
>
> Using similar methods (ps_mem.py), I get roughly the same results.
>
> I run ps_mem.py at five places, before and after enabling composite with
> 0 to 4 activites running (Chat, Paint, Write, and Browse). (I get ten
> files named {before,after}_*_activity, and then grep them to make
> comparitive claims.)
>
>
> We can see that Activities use about the same amount of memory before
> and after the change:
>
>
> e.g. Paint:
>
> before_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint <65be2c3b
> before_2_activity: 9.2 MiB + 3.1 MiB = 12.3 MiB Paint <65be2c3b
> before_3_activity: 9.4 MiB + 2.5 MiB = 11.9 MiB Paint <65be2c3b
> before_4_activity: 9.4 MiB + 2.1 MiB = 11.5 MiB Paint <65be2c3b
>
> after_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint after_2_activity: 9.3 MiB + 3.1 MiB = 12.4 MiB Paint after_3_activity: 9.2 MiB + 2.5 MiB = 11.7 MiB Paint after_4_activity: 9.2 MiB + 2.1 MiB = 11.3 MiB Paint
>
> e.g. Write:
>
> before_3_activity: 19.4 MiB + 2.8 MiB = 22.2 MiB Write before_4_activity: 19.4 MiB + 2.4 MiB = 21.8 MiB Write
> after_3_activity: 19.4 MiB + 2.8 MiB = 22.2 MiB Write after_4_activity: 19.4 MiB + 2.4 MiB = 21.8 MiB Write
>
> However, there is an obvious memory difference between the two
> situations:
>
> [ total memory usage ]
>
> before_0_activity- 86.4 MiB
> before_1_activity- 98.0 MiB
> before_2_activity-126.6 MiB
> before_3_activity-146.2 MiB
> before_4_activity-154.9 MiB
>
> after_0_activity- 88.5 MiB
> after_1_activity-109.8 MiB
> after_2_activity-138.0 MiB
> after_3_activity-162.7 MiB
> after_4_activity-173.2 MiB
>
> When composition is enabled, we used 18.3 MiB more to run the same 4
> activities.
>
>
> Following Martin Dengler's lead, we discover that this memory is mostly
> used by the X server:
>
> bash-3.2# grep Xorg before*
> before_0_activity: 3.1 MiB + 390.5 KiB = 3.5 MiB Xorg
> before_1_activity: 3.2 MiB + 430.0 KiB = 3.6 MiB Xorg
> before_2_activity: 3.4 MiB + 420.0 KiB = 3.9 MiB Xorg
> before_3_activity: 3.7 MiB + 509.5 KiB = 4.2 MiB Xorg
> before_4_activity: 3.7 MiB + 507.5 KiB = 4.2 MiB Xorg
>
> bash-3.2# grep Xorg after*
> after_0_activity: 3.0 MiB + 342.5 KiB = 3.3 MiB Xorg
> after_1_activity: 10.9 MiB + 445.0 KiB = 11.4 MiB Xorg
> after_2_activity: 13.1 MiB + 425.5 KiB = 13.5 MiB Xorg
> after_3_activity: 18.0 MiB + 506.0 KiB = 18.5 MiB Xorg
> after_4_activity: 19.9 MiB + 504.0 KiB = 20.4 MiB Xorg
>
> A little under 15 MiB of increase.
>
>>
>> I'd vote for activating composition ASAP once we have a 9.1 joyride
>> branch and see how we can find the sweetest spot between speed and
>> memory usage.
>>
>
> I agree.
>
> There also may be bugs which we need to shake out. If this is a feature
> we know we want for 9.1, the sooner we start testing the better.
>
FWIW, sometime back, I did some benchmarks with a composite enabled
Metacity - results at
http://www.mail-archive.com/sugar@lists.laptop.org/msg03613.html
Jim had suggested some memory saving tricks at
http://www.mail-archive.com/sugar@lists.laptop.org/msg03647.html
Thanks
Sayamindu
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Wed, Sep 24, 2008 at 8:56 PM, Erik Garrison <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 07:51:30PM +0200, Tomeu Vizoso wrote:
>> On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva <[EMAIL PROTECTED]> wrote:
>> > 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.
>>
>> AFAIK, the only tradeback (and the reason why it hasn't been activated
>> yet) is that we must pay composition with increased memory usage.
>> Composition basically saves us unnecessary redraws by keeping in
>> memory copies of the windows contents.
>>
>> Martin Dengler did back in March an excellent job quantifying this tradeback:
>>
>> http://lists.laptop.org/pipermail/sugar/2008-March/004718.html
>
> Using similar methods (ps_mem.py), I get roughly the same results.
>
> I run ps_mem.py at five places, before and after enabling composite with
> 0 to 4 activites running (Chat, Paint, Write, and Browse). (I get ten
> files named {before,after}_*_activity, and then grep them to make
> comparitive claims.)
>
>
> We can see that Activities use about the same amount of memory before
> and after the change:
>
>
> e.g. Paint:
>
> before_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint <65be2c3b
> before_2_activity: 9.2 MiB + 3.1 MiB = 12.3 MiB Paint <65be2c3b
> before_3_activity: 9.4 MiB + 2.5 MiB = 11.9 MiB Paint <65be2c3b
> before_4_activity: 9.4 MiB + 2.1 MiB = 11.5 MiB Paint <65be2c3b
>
> after_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint after_2_activity: 9.3 MiB + 3.1 MiB = 12.4 MiB Paint after_3_activity: 9.2 MiB + 2.5 MiB = 11.7 MiB Paint after_4_activity: 9.2 MiB + 2.1 MiB = 11.3 MiB Paint
>
> e.g. Write:
>
> before_3_activity: 19.4 MiB + 2.8 MiB = 22.2 MiB Write before_4_activity: 19.4 MiB + 2.4 MiB = 21.8 MiB Write
> after_3_activity: 19.4 MiB + 2.8 MiB = 22.2 MiB Write after_4_activity: 19.4 MiB + 2.4 MiB = 21.8 MiB Write
>
> However, there is an obvious memory difference between the two
> situations:
>
> [ total memory usage ]
>
> before_0_activity- 86.4 MiB
> before_1_activity- 98.0 MiB
> before_2_activity-126.6 MiB
> before_3_activity-146.2 MiB
> before_4_activity-154.9 MiB
>
> after_0_activity- 88.5 MiB
> after_1_activity-109.8 MiB
> after_2_activity-138.0 MiB
> after_3_activity-162.7 MiB
> after_4_activity-173.2 MiB
>
> When composition is enabled, we used 18.3 MiB more to run the same 4
> activities.
>
>
> Following Martin Dengler's lead, we discover that this memory is mostly
> used by the X server:
>
> bash-3.2# grep Xorg before*
> before_0_activity: 3.1 MiB + 390.5 KiB = 3.5 MiB Xorg
> before_1_activity: 3.2 MiB + 430.0 KiB = 3.6 MiB Xorg
> before_2_activity: 3.4 MiB + 420.0 KiB = 3.9 MiB Xorg
> before_3_activity: 3.7 MiB + 509.5 KiB = 4.2 MiB Xorg
> before_4_activity: 3.7 MiB + 507.5 KiB = 4.2 MiB Xorg
>
> bash-3.2# grep Xorg after*
> after_0_activity: 3.0 MiB + 342.5 KiB = 3.3 MiB Xorg
> after_1_activity: 10.9 MiB + 445.0 KiB = 11.4 MiB Xorg
> after_2_activity: 13.1 MiB + 425.5 KiB = 13.5 MiB Xorg
> after_3_activity: 18.0 MiB + 506.0 KiB = 18.5 MiB Xorg
> after_4_activity: 19.9 MiB + 504.0 KiB = 20.4 MiB Xorg
>
> A little under 15 MiB of increase.
>
>>
>> I'd vote for activating composition ASAP once we have a 9.1 joyride
>> branch and see how we can find the sweetest spot between speed and
>> memory usage.
>>
>
> I agree.
>
> There also may be bugs which we need to shake out. If this is a feature
> we know we want for 9.1, the sooner we start testing the better.
Bernie has talked about some wm hints that can be set on windows so
they get unredirected and thus their offscreen pixmaps released. Not
sure if matchbox would support them, though.
Related with all this is the decision to switch window managers.
Perhaps keeping redirected just the two activities on top of the stack
plus the desktop window may be enough? I think that would mean a
constant 12MB, approx.
Regards,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Wed, Sep 24, 2008 at 07:51:30PM +0200, Tomeu Vizoso wrote:
> On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva <[EMAIL PROTECTED]> wrote:
> > 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.
>
> AFAIK, the only tradeback (and the reason why it hasn't been activated
> yet) is that we must pay composition with increased memory usage.
> Composition basically saves us unnecessary redraws by keeping in
> memory copies of the windows contents.
>
> Martin Dengler did back in March an excellent job quantifying this tradeback:
>
> http://lists.laptop.org/pipermail/sugar/2008-March/004718.html
Using similar methods (ps_mem.py), I get roughly the same results.
I run ps_mem.py at five places, before and after enabling composite with
0 to 4 activites running (Chat, Paint, Write, and Browse). (I get ten
files named {before,after}_*_activity, and then grep them to make
comparitive claims.)
We can see that Activities use about the same amount of memory before
and after the change:
e.g. Paint:
before_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint <65be2c3b
before_2_activity: 9.2 MiB + 3.1 MiB = 12.3 MiB Paint <65be2c3b
before_3_activity: 9.4 MiB + 2.5 MiB = 11.9 MiB Paint <65be2c3b
before_4_activity: 9.4 MiB + 2.1 MiB = 11.5 MiB Paint <65be2c3b
after_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint
> I'd vote for activating composition ASAP once we have a 9.1 joyride
> branch and see how we can find the sweetest spot between speed and
> memory usage.
>
I agree.
There also may be bugs which we need to shake out. If this is a feature
we know we want for 9.1, the sooner we start testing the better.
Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
Good grief ! > 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? I'm not a kid. I wish that someone *would* observe students, and prove me wrong. I just put up a bunch of *complex* screens (from various activities). Having disabled the frame, I can alt-tab to the next screen in a fraction of a second. Even when I have to traverse multiple screens, the time for me to get somewhere is only a second or two. That is way faster for me than looking at Frame. WHY is everyone talking about switching from the work one is doing, to looking at the icons in the Frame? I agree that when there are 20 Activities running, it makes sense to go *directly* to the screen one wants (without passing through the other 18). But few students are likely to have 20 Activities running. Besides, how will the student be able to tell among umpteen identical *icons* which is the one for the work he wants to do next? I maintain that by simply alt-tabbing through the screens, the student will *easily* recognize (and stop tabbing) when he comes to the one he wants to do more work in. > just noticed > that if you hit the alt-tab like some 1980 track'n field game in the > arcades, you can select a different activity with out focusing all the > others on the way there. This IMO is the wrong behaviour, even with a > longer delay to allow less frenetic tab key hitting, the behaviour > should be to focus ON RELEASE of the alt key. That way you can take > all the time in the world scanning the icons and choosing where you > need to get too. I can't __imagine__ why one would have to decide what screen one wanted to look at next. [Maybe if the user had gotten riled up by what he was doing, and now was contemplating which other screen would be more soothing?] And if one *must* "choose" (and perform a "direct" transfer) -- why not go to Journal instead of Frame? At least Journal will show the entry-fields from all the running Activities, so one can identify the particular activity-instance one wants. When I want to transfer screens I KNOW where I want to go. All that remains is the mechanism of getting there. My point is that if distractions such as the frame are gotten out of the way, then one can (without losing his train of thought) perform a simple action -- alt-tabbing -- and STOP when one gets to where one wants to be. mikus p.s. If the current alt-tab implementation has a performance impact (for instance, if a snapshot of each displayed screen were being taken) -- please work on the behavior of the software -- NOT on the behavior of the USER (which is what "burdening" alt-tab accomplishes).] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 7:51 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 24 Sep 2008, at 18:25, Eduardo H. Silva wrote: > >> 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. > > Just curious, you guys running on XO hardware? I hope so ;) The XO hardware is not so slow, the only problem is that using the existing resources as well as possible takes time and we don't have much of that. It also requires some expertise that the Sugar team lacks at this moment, as well. Remember that most of the software we reuse is developed by people that long ago stopped worrying about hardware similar to the XO, so we are the ones that should be improving performance in all that mountain of software. Focus on linux on embedded devices may help on that, but the hardware others use may be very different to the geode :/ Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva <[EMAIL PROTECTED]> wrote: > 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. AFAIK, the only tradeback (and the reason why it hasn't been activated yet) is that we must pay composition with increased memory usage. Composition basically saves us unnecessary redraws by keeping in memory copies of the windows contents. Martin Dengler did back in March an excellent job quantifying this tradeback: http://lists.laptop.org/pipermail/sugar/2008-March/004718.html I'd vote for activating composition ASAP once we have a 9.1 joyride branch and see how we can find the sweetest spot between speed and memory usage. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On 24 Sep 2008, at 18:25, Eduardo H. Silva wrote: > 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. Just curious, you guys running on XO hardware? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
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 <[EMAIL PROTECTED]>: > On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: >> On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> 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 n
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 12:37 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 12:25:43PM -0400, Eben Eliason wrote: >> On Wed, Sep 24, 2008 at 12:18 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: >> > On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: >> >> On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: >> > By "saving" I mean that changes in activity state trigger >> > Activity.save(). This hits jffs2 and the NAND. >> >> Sure, as Tomeu says, we could add a dirty bit. Of course, it seems >> that the Frame-based solution should actually be preventing this >> (given a long enough delay on revealing the activity window, or not >> revealing until releasing alt-tab), since the activities don't even >> get focused at all immediately. Only those you pause or stop on >> should be doing any saving of state, and even then only if needed. > > How long of a pause or stop triggers auto-save? > > We could also save on user idle. Say, when the user is idle for more > than 5 seconds and we haven't saved in the last 2 minutes. Or we could > just auto-save every N minutes. Both of these options would decouple > CPU-intensive actions from user intervention, with the effect of > improved system responsiveness. We could certainly try both of these. To clarify my point above, the basic rule was to auto-save at the activity's discretion (likely when dirty and N minutes have passed, and or idle) and when switching /away/ from the activity (and also dirty). My point, basically, is that we shouldn't be giving windows focus while we're still tabbing, in which case we never "leave" any activity we tab past, because we never "went into" it. Perhaps we can acheive the same effect without the Frame, but I'm not sure. The only activity which should do any saving during a tabbing operation, really, is the one we left when starting it. - Eben > Erik > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 12:25:43PM -0400, Eben Eliason wrote: > On Wed, Sep 24, 2008 at 12:18 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: > >> On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > > By "saving" I mean that changes in activity state trigger > > Activity.save(). This hits jffs2 and the NAND. > > Sure, as Tomeu says, we could add a dirty bit. Of course, it seems > that the Frame-based solution should actually be preventing this > (given a long enough delay on revealing the activity window, or not > revealing until releasing alt-tab), since the activities don't even > get focused at all immediately. Only those you pause or stop on > should be doing any saving of state, and even then only if needed. How long of a pause or stop triggers auto-save? We could also save on user idle. Say, when the user is idle for more than 5 seconds and we haven't saved in the last 2 minutes. Or we could just auto-save every N minutes. Both of these options would decouple CPU-intensive actions from user intervention, with the effect of improved system responsiveness. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 06:08:47PM +0200, Tomeu Vizoso wrote:
> On Wed, Sep 24, 2008 at 5:25 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> > On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> 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".
> >
> >> 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.
>
> We also shouldn't be autosaving when the activity is not dirty (most
> of the time when alt-tabbing).
>
> May be easier to actually enable composition and disable autosaving
> (by editing activity.py) than speculating here about cutting
> functionality.
My observations are partly coming from testing on composition and no
autosave... You're right that others should give it a whirl.
> Who could give this a try?
I have patches to enable composition in Sugar's main.py. We'll have to
push xcompmgr into the builds as well.
I also have a patch to disable autosaving (again with a flag in home,
/home/olpc/no-auto-save).
For what it's worth I'm attaching them here. Perhaps we should start a
new thread to discuss these?
Erik
diff --git a/src/main.py b/src/main.py
index 355565b..749e530 100644
--- a/src/main.py
+++ b/src/main.py
@@ -15,6 +15,7 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import os
+import subprocess
import gettext
import pygtk
@@ -45,6 +46,9 @@ def _start_matchbox():
gobject.spawn_async(cmd, flags=gobject.SPAWN_SEARCH_PATH)
+def _start_xcompmgr():
+subprocess.Popen(['xcompmgr', '-d', ':0.0'])
+
def _setup_translations():
locale_path = os.path.join(config.prefix, 'share', 'locale')
domain = 'sugar'
@@ -88,6 +92,7 @@ def main():
logger.start('shell')
+_start_xcompmgr()
_start_matchbox()
_setup_translations()
diff --git a/src/sugar/activity/activity.py b/src/sugar/activity/activity.py
index b55a09d..97abbc7 100644
--- a/src/sugar/activity/activity.py
+++ b/src/sugar/activity/activity.py
@@ -575,7 +575,8 @@ class Activity(Window, gtk.Container):
if self._active != active:
self._active = active
if not self._active and self._jobject:
-self.save()
+if not os.path.exists('/home/olpc/no-auto-save'):
+self.save()
active = gobject.property(
type=bool, default=False, getter=get_active, setter=set_active)
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: > On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> 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@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 5:25 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> 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". > >> 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. We also shouldn't be autosaving when the activity is not dirty (most of the time when alt-tabbing). May be easier to actually enable composition and disable autosaving (by editing activity.py) than speculating here about cutting functionality. Who could give this a try? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 11:34 AM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 24 Sep 2008, at 16:12, Erik Garrison wrote: > >> On Wed, Sep 24, 2008 at 11:03:01AM -0400, Chris Ball wrote: >>> Hi Erik, >>> 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? >>> >>> Sounds good, I'd agree with just removing it completely. >> >> Me too. > > I thought there was a bug with the current implementation that has > slipped this release cycle. I understood the Frame was to reveal and > then as you alt-tabbed you could see the focus move between the > Activity instances (i.e. no switching has yet happened), and when you Right... > finally release the alt key (on the instance you are really after, not > the Journal ;-b ), that instance is then focused. Yes, this was the initial intent. Playing with it (on faster machines, of course), we thought that there might be a reasonable delay at which to reveal the real window beneath, but I agree that right now it's much too fast. We might be able to get away without revealing the window at all, but we'll need to figure out a way to reveal the palette (primary only!) so you can see a textual description of the activity (to distinguish, for instance, 2 Browse instances). I'd definitely lean toward removing the delay completely (that is, not showing the actual window) over removing the Frame completely -- as much as "the actual window" is beneficial to the what-you-see-is-what-you-get ideal, I think it's far too slow (even without the Frame) to be practical. > I agree if you are just tabbing between 2 instances the frame reveal > is an unnecessary burden, but with 3 activities you'll probably be > focusing on something you don't want 50% of the time (at least most > kids will). More than 3 and you really are just ploughing the XO > through a heap of Activity redraws. Yup. No good. I just tried it without the Frame at all, and I don't much care for the experience at all. > I couldn't find the original trac ticket for this, anyone remember > (wanted to go see where dev stalled)? Benzea worked on this one a lot. There's a chance that it's closed since the current behavior is pretty much to the initial spec. I'm not sure. - Eben > --Gary > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Now YOU can write API documentation
On Wed, Sep 24, 2008 at 5:30 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > Tomeu Vizoso wrote: >> >> On Wed, Sep 24, 2008 at 3:12 PM, David Farning <[EMAIL PROTECTED]> >> wrote: >> >>> >>> On Wed, 2008-09-24 at 13:55 +0200, Morgan Collett wrote: >>> > > thanks > david > I've started on sugar.network as I went through that code recently. Here's an issue with pydocweb: http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/ doesn't show the name of a method starting with _ - _handle_accept. I knew it existed, so I manually edited the URL to get to http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/ which I edited. Bug? Feature? >>> >>> It is a feature. Pydocweb is set to not publish private methods and >>> classes. The idea is to create the documentation that is most >>> appreciated by application developers. Should we change this? >>> >> >> I think that we should start by adding docstrings to the public API in >> sugar.*, then document the shell's public classes and methods, and >> finally lift that limitation and add docstrings to all the private >> methods. >> > > The generated documentation should only contain public methods. Sure. > Actually I'm not even sure we should use pydocweb for private docs. Perhaps not, I guess it depends on which advantages it brings. That kind of docs would only be edited and consumed by developers, of course. > Informal > documentation directly in the code (when writing or modifying it) would be > enough imo. And on some functions documentation might just add noise... What do you mean by informal documentation? Personally, I think that docstrings without implementation details are useful everywhere. And inline comments should only be used when we are doing a hack because of performance, working around a bug in some other component, etc Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On 24 Sep 2008, at 16:34, Gary C Martin wrote: > I thought there was a bug with the current implementation that has > slipped this release cycle. I understood the Frame was to reveal and > then as you alt-tabbed you could see the focus move between the > Activity instances (i.e. no switching has yet happened), and when you > finally release the alt key (on the instance you are really after, not > the Journal ;-b ), that instance is then focused. Sorry, didn't describe that well on second read, and I just noticed that if you hit the alt-tab like some 1980 track'n field game in the arcades, you can select a different activity with out focusing all the others on the way there. This IMO is the wrong behaviour, even with a longer delay to allow less frenetic tab key hitting, the behaviour should be to focus ON RELEASE of the alt key. That way you can take all the time in the world scanning the icons and choosing where you need to get too. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar-meeting REMINDER (Thursday September 25 2008 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
Thursday September 25 2008 - 14.00 (UTC) Form the Sugarlabs Bugsquad At this meeting we want to form the Sugarlabs Bugsquad, the Quality Assurance (QA) team for Sugar. The squad keeps track of current bugs in the sugar software and try to make sure that major bugs do not go unnoticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the Sugar community if you cannot program. The squad is modelled on the gnome bugsquad: http://developer.gnome.org/projects/bugsquad/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On 24 Sep 2008, at 16:12, Erik Garrison wrote: > On Wed, Sep 24, 2008 at 11:03:01AM -0400, Chris Ball wrote: >> Hi Erik, >> >>> 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? >> >> Sounds good, I'd agree with just removing it completely. > > Me too. I thought there was a bug with the current implementation that has slipped this release cycle. I understood the Frame was to reveal and then as you alt-tabbed you could see the focus move between the Activity instances (i.e. no switching has yet happened), and when you finally release the alt key (on the instance you are really after, not the Journal ;-b ), that instance is then focused. I agree if you are just tabbing between 2 instances the frame reveal is an unnecessary burden, but with 3 activities you'll probably be focusing on something you don't want 50% of the time (at least most kids will). More than 3 and you really are just ploughing the XO through a heap of Activity redraws. I couldn't find the original trac ticket for this, anyone remember (wanted to go see where dev stalled)? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Now YOU can write API documentation
Tomeu Vizoso wrote: > On Wed, Sep 24, 2008 at 3:12 PM, David Farning <[EMAIL PROTECTED]> wrote: > >> On Wed, 2008-09-24 at 13:55 +0200, Morgan Collett wrote: >> thanks david >>> I've started on sugar.network as I went through that code recently. >>> >>> Here's an issue with pydocweb: >>> http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/ >>> doesn't show the name of a method starting with _ - _handle_accept. I >>> knew it existed, so I manually edited the URL to >>> get to >>> http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/ >>> which I edited. >>> >>> Bug? Feature? >>> >>> >> It is a feature. Pydocweb is set to not publish private methods and >> classes. The idea is to create the documentation that is most >> appreciated by application developers. Should we change this? >> > > I think that we should start by adding docstrings to the public API in > sugar.*, then document the shell's public classes and methods, and > finally lift that limitation and add docstrings to all the private > methods. > The generated documentation should only contain public methods. Actually I'm not even sure we should use pydocweb for private docs. Informal documentation directly in the code (when writing or modifying it) would be enough imo. And on some functions documentation might just add noise... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <[EMAIL PROTECTED]> 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". > 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. > 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. - Eben > invariably quite loaded, and the frame draw consequently is quite > clunky. > > The attached patch to sugar optionally disables frame appearance if > the file /home/olpc/no-frame-on-tabbing exists. This is just a > proof-of-concept hack to make it easier to quickly enable and disable > the functionality and observe the performance change. > > I have created a trac ticket: http://dev.laptop.org/ticket/8633 > > Erik > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison 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? | Another option, which I would prefer, is to show only the top bar of the frame. In general, when only one of the four sides of the frame is relevant, I think we should show only that side. Showing only the top bar should save something like 75% of the redraw CPU, while retaining the helpful display of available instances. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjaW6QACgkQUJT6e6HFtqQfDQCfWR7Y83T07PqYl+NritKeZIvL mgoAoIHZUNrngiqy7YgmFiFiK9c7dKDb =LUV/ -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 11:03:01AM -0400, Chris Ball wrote:
> Hi Erik,
>
>> 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?
>
> Sounds good, I'd agree with just removing it completely.
Me too.
>> The attached patch to sugar optionally disables frame appearance if
>> the file /home/olpc/no-frame-on-tabbing exists. This is just a
>> proof-of-concept hack to make it easier to quickly enable and
>> disable the functionality and observe the performance change.
>
> The patch isn't attached, and the patch I found in the Trac ticket isn't
> useful -- it has no lines of context and doesn't even specify which file
> is being patched, so it can't be applied; please resend using "diff -u",
> or ideally "git diff".
Whooops! Two errors. I put the wrong patch on the ticket and didn't
even attach the patch to the email.
Attached is the right file. I'm fixing the ticket... is there any way
to delete files from a trac ticket?
Erik
diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py
index e3153b0..54f2d4e 100644
--- a/src/view/tabbinghandler.py
+++ b/src/view/tabbinghandler.py
@@ -15,6 +15,7 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import logging
+import os
import gtk
import gobject
@@ -59,7 +60,8 @@ class TabbingHandler(object):
else:
shell = view.Shell.get_instance()
-self._frame.show(self._frame.MODE_NON_INTERACTIVE)
+if not os.path.exists('/home/olpc/no-frame-on-tabbing'):
+self._frame.show(self._frame.MODE_NON_INTERACTIVE)
def __timeout_cb(self):
self._activate_current()
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
Hi Erik, > 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? Sounds good, I'd agree with just removing it completely. > The attached patch to sugar optionally disables frame appearance if > the file /home/olpc/no-frame-on-tabbing exists. This is just a > proof-of-concept hack to make it easier to quickly enable and > disable the functionality and observe the performance change. The patch isn't attached, and the patch I found in the Trac ticket isn't useful -- it has no lines of context and doesn't even specify which file is being patched, so it can't be applied; please resend using "diff -u", or ideally "git diff". Thanks, - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] frame auto-visibility configuration
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? Drawing the frame animation during tabbing robs us of processor right when we need it, slowing the perceived transition time between windows. 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 invariably quite loaded, and the frame draw consequently is quite clunky. The attached patch to sugar optionally disables frame appearance if the file /home/olpc/no-frame-on-tabbing exists. This is just a proof-of-concept hack to make it easier to quickly enable and disable the functionality and observe the performance change. I have created a trac ticket: http://dev.laptop.org/ticket/8633 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Now YOU can write API documentation
On Wed, Sep 24, 2008 at 3:12 PM, David Farning <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-24 at 13:55 +0200, Morgan Collett wrote: >> > thanks >> > david >> >> I've started on sugar.network as I went through that code recently. >> >> Here's an issue with pydocweb: >> http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/ >> doesn't show the name of a method starting with _ - _handle_accept. I >> knew it existed, so I manually edited the URL to >> get to >> http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/ >> which I edited. >> >> Bug? Feature? >> > > It is a feature. Pydocweb is set to not publish private methods and > classes. The idea is to create the documentation that is most > appreciated by application developers. Should we change this? I think that we should start by adding docstrings to the public API in sugar.*, then document the shell's public classes and methods, and finally lift that limitation and add docstrings to all the private methods. So we should change that at some point, but not yet. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Now YOU can write API documentation
On Wed, Sep 24, 2008 at 15:12, David Farning <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-24 at 13:55 +0200, Morgan Collett wrote: >> > thanks >> > david >> >> I've started on sugar.network as I went through that code recently. >> >> Here's an issue with pydocweb: >> http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/ >> doesn't show the name of a method starting with _ - _handle_accept. I >> knew it existed, so I manually edited the URL to >> get to >> http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/ >> which I edited. >> >> Bug? Feature? >> > > It is a feature. Pydocweb is set to not publish private methods and > classes. The idea is to create the documentation that is most > appreciated by application developers. Should we change this? OK, I see the logic in that. However I did want to edit some poorly docstringed private methods. I'll just do that manually since I can... > As of yesterday, we hit a regression where some of the public methods > are not being imported correctly. We are working on the issue. > http://api.sugarlabs.org/ is importing all of the functions correctly I > believe. > > > thanks > david Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Now YOU can write API documentation
On Wed, 2008-09-24 at 13:55 +0200, Morgan Collett wrote: > > thanks > > david > > I've started on sugar.network as I went through that code recently. > > Here's an issue with pydocweb: > http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/ > doesn't show the name of a method starting with _ - _handle_accept. I > knew it existed, so I manually edited the URL to > get to > http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/ > which I edited. > > Bug? Feature? > It is a feature. Pydocweb is set to not publish private methods and classes. The idea is to create the documentation that is most appreciated by application developers. Should we change this? As of yesterday, we hit a regression where some of the public methods are not being imported correctly. We are working on the issue. http://api.sugarlabs.org/ is importing all of the functions correctly I believe. thanks david ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Reviews report
= New requests = Jabber server description is ambiguous http://dev.laptop.org/ticket/8623 "Battery fully charged" shows up in error (battery is removed) http://dev.laptop.org/ticket/5867 = Approved requests = Icons overlap unnecessarily in crowded neighborhood view. http://dev.laptop.org/ticket/8626 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Now YOU can write API documentation
On Sat, Sep 20, 2008 at 04:58, David Farning <[EMAIL PROTECTED]> wrote: > Now you can learn to document sugar APIs from the comfort of your own > wiki. > > With the help of Pauli Virtanen, Janet Swisher, and Marco, we now have a > wiki based tool for documenting sugar apis! Take a look at > http://sugarlabs1.xen.prgmr.com . > > Follow the instructions at > http://sugarlabs1.xen.prgmr.com/pydocweb/wiki/getting_started/ to get > started. > > Don't worry about being perfect, someone will come along and clean up > the docstrings before they are committed back to the git tree. > > To get us started, I have been adding function summaries and parameter > lists to the graphics package. > > thanks > david I've started on sugar.network as I went through that code recently. Here's an issue with pydocweb: http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/ doesn't show the name of a method starting with _ - _handle_accept. I knew it existed, so I manually edited the URL to get to http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/ which I edited. Bug? Feature? Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] sugar-toolkit 0.82.11
= Source = http://dev.laptop.org/pub/sugar/sources/sugar-toolkit/sugar-toolkit-0.82.11.tar.bz2 = Closed tickets = * #8626 Icons overlap unnecessarily in crowded neighborhood view. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] GCompris Chess & Sudoku issues
Hi Bruno On Wed, Sep 24, 2008 at 01:13, Bruno Coudoin <[EMAIL PROTECTED]> wrote: > Le mercredi 24 septembre 2008 à 00:26 +0200, Bruno Coudoin a écrit : >> Le mardi 23 septembre 2008 à 11:08 +0200, Morgan Collett a écrit : >> > Hi Bruno >> > >> > We are about to release 8.2 for the XO. GCompris Chess and Sudoku are >> > being considered for inclusion for preinstallation for G1G1. We need >> > to know if you have tested and verified that they are working with >> > 8.2-759 or later (for instructions on downloading 8.2 release, see: >> > http://wiki.laptop.org/go/Friends_in_testing). >> > >> > The basic activity test is defined here: >> > >> > http://wiki.laptop.org/go/Test_cases_8.2.0#Activities >> > >> > If you have tested them and confirmed that they work, please reply >> > ASAP. Include the version # of the activity and a link to the .xo >> > file. >> >> I just uploaded a new release set of all GCompris activities, including >> the full bundle. These now have the activity_version set to 9 and the >> license field to GPLv3+. >> >> Sadly, GCompris activity startup sequence is broken on this release, >> none of the 2 activities you selected works anymore. No idea why yet. >> > > OK, I got the traces. > > When I run the sudoku I get into this bug, my olpc is frozen for maybe a > minute: > http://dev.laptop.org/ticket/7251 Ouch. Please add a comment on that ticket, perhaps someone has an idea there. > When I run the chess_computer activity, I have an error complaining that > check_bundle_id isalnum() fails. Does that mean _ are no more accepted > in a bundle name ? If this on purpose ? http://wiki.laptop.org/go/Activity_bundles#.info_File_Format documents bundle_id, and suggests that http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names is the definition of what is allowed, which does include _ However I see on the Activity_bundles page: In the Python bindings, the bundle_id is also used as the activity's default service type when the activity is shared on the network. To determine this type, the distinct parts (separated by the '.' character) are reversed, any '.' is replaced by a '_' character, and the type is prefixed by a '_' character. So in this example, the default service type would be "_BrowserActivity_Sugar_redhat_com". Perhaps that affects the use of _ in bundle_id. Anyone else know the answer? Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
