headers
Mikus Grinbergs | 1 Oct 02:32
Favicon

one response time

Had WikipediaEn-3.xo on a removable storage device.  Launched it by 
clicking in the Journal view for that device.  It took about a 
MINUTE before the "pulsing" (i.e., "activity is being launched") 
screen was displayed.  Otherwise the XO (766) just sat there (in an 
unchanged Journal view - not even a palette).  Except for the 
blinking of the LED on the storage device, I would not have known 
that anything was happening.

mikus
Permalink | Reply | 0 comments |
headers
Mikus Grinbergs | 1 Oct 02:39
Favicon

another response time

Launched XaoS-2 (on 766).  The "activity is being launched" screen 
pulsed and pulsed for a couple of minutes.  I had definitely 
concluded that it would *never* launch, and that this was the "Sugar 
launch" timeout that kept the screen pulsing -- when suddenly the 
XaoS activity screen was drawn.  It is likely that some people will 
not have the patience to wait that loooong.  [How *could* they tell 
whether the pulsing would end well, or would not end well ?]

mikus
Permalink | Reply | 2 comments |
headers
Gary C Martin | 1 Oct 05:52

Re: Image Viewer Activity

On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote:

> A screenshot is at
> http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png
> The code lives in Git:
> http://dev.laptop.org/git?p=users/sayamindu/imageviewer- 
> activity;a=tree
>
> Comments, patches and brickbats are welcome :-).

No brickbats (or patches), but just wanted to report one (very minor)  
Image Viewer misbehaviour. I noticed today that if I open an image,  
and then rename it within Image Viewer, it generates one of those  
"Keep Error" warnings about loosing all changes. The new name does  
actually change correctly. This error seems to crop up on a number of  
activities so I'm not sure if it's a Sugar bug or some common issue  
catching out Activity authors.

Regards,
--Gary

P.S. No one seems to have raised any issues yet with the icon sample I  
posted, so if you're happy with it, and I get no other feedback, I'll  
turn it into a SVG at end of tomorrow (though I may also try a version  
with a looking-glass partially over the image frame).
Permalink | Reply | 2 comments |
headers
Mikus Grinbergs | 1 Oct 06:01
Favicon

why are removable storage devices just an adjunct ?

Applications which I intend to use in the near future I keep 
"resident" (Sugar Activities in /home/olpc/Activities, Linux 
applications on my "permanent" SD card).  Those I access rarely I 
keep on a removable storage device.

Just now was using Journal to access Activity bundles kept on a 
removable storage device.  All I wanted to do was to run them once 
-- but Journal *installed* (in /home/olpc/Activities) each one that 
I clicked on.  I had not expected that.

The XO-1 does not have a lot of nand "storage".  What interests me 
is how best to "off-load" data *and programs* from nand.  I had been 
told that it was possible to run Activities from a removable storage 
device -- but I now see that in the actual implementation it *still* 
requires nand to run an "off-loaded" Activity -- in other words, the 
removable storage device is just an "adjunct", not a "repository".

There really ought to be a better way to "deposit" Activities which 
are not being accessed each week.  Sooner rather than later, there 
simply will not be room in /home/olpc/Activities.

mikus
Permalink | Reply | 1 comment |
headers
Tomeu Vizoso | 1 Oct 09:28

Re: another response time

On Wed, Oct 1, 2008 at 2:39 AM, Mikus Grinbergs <mikus <at> bga.com> wrote:
> Launched XaoS-2 (on 766).  The "activity is being launched" screen
> pulsed and pulsed for a couple of minutes.  I had definitely
> concluded that it would *never* launch, and that this was the "Sugar
> launch" timeout that kept the screen pulsing -- when suddenly the
> XaoS activity screen was drawn.  It is likely that some people will
> not have the patience to wait that loooong.  [How *could* they tell
> whether the pulsing would end well, or would not end well ?]

Hi Mikus,

as you probably installed previously the Wikipedia activity, my guess
is that the jffs2 gc thread was taking most of the CPU. Sadly, we can
expect greatly reduced overall system performance after any
significant allocation or deallocation of flash space.

This means to testers that before reporting any Sugar slowness, should
be checked with top that the jffs2 gc is not taking cpu.

It's not my area, but I guess this only will be solved when we move to
another fs, hopefully by 9.1.

Thanks,

Tomeu
Permalink | Reply | 0 comments |
headers
Tomeu Vizoso | 1 Oct 09:37

Re: why are removable storage devices just an adjunct ?

On Wed, Oct 1, 2008 at 6:01 AM, Mikus Grinbergs <mikus <at> bga.com> wrote:
> Applications which I intend to use in the near future I keep
> "resident" (Sugar Activities in /home/olpc/Activities, Linux
> applications on my "permanent" SD card).  Those I access rarely I
> keep on a removable storage device.
>
> Just now was using Journal to access Activity bundles kept on a
> removable storage device.  All I wanted to do was to run them once
> -- but Journal *installed* (in /home/olpc/Activities) each one that
> I clicked on.  I had not expected that.
>
>
> The XO-1 does not have a lot of nand "storage".  What interests me
> is how best to "off-load" data *and programs* from nand.  I had been
> told that it was possible to run Activities from a removable storage
> device -- but I now see that in the actual implementation it *still*
> requires nand to run an "off-loaded" Activity -- in other words, the
> removable storage device is just an "adjunct", not a "repository".
>
> There really ought to be a better way to "deposit" Activities which
> are not being accessed each week.  Sooner rather than later, there
> simply will not be room in /home/olpc/Activities.

You raise interesting points. The reason why there isn't better
support for removable devices is that the current resources didn't
allowed for more work to go in there.

I think Scott has plans to make possible run activities without
unpacking them anywhere, so I expect that would serve for your plans
of offloading activities to removable storage.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Dänzer | 1 Oct 12:55

Re: [sugar] rendering test

On Tue, 2008-09-30 at 21:30 +0200, Bernie Innocenti wrote:
> Michel Dänzer wrote:
> > On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: 
> >>
> >> My performance tests with X 1.3 and 1.4 had shown that turning on EXA 
> >> makes many operations slower.  It's hard to tell why, but it might have to 
> >> do with loosing XShmPut() (MIT shared memory), 
> > 
> > EXA does support XShmPutImage(), just not SHM pixmaps.
> 
> I was remembering the code.
> 
> As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer 
> being used.  Shall I commit a cleanup?

ShmPutImage is still accelerated though (also, that commit is only in
1.5, not 1.4). What kind of cleanup do you have in mind?

--

-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

_______________________________________________
xorg mailing list
xorg <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Permalink | Reply | 1 comment |
headers
Simon Schampijer | 1 Oct 15:17
Picon

evince/poppler

Hi,

we are using an old version of evince and poppler. Are there any 
intentions to update?

Current poppler we use is 0.6 and the latest stable is 0.8 
http://poppler.freedesktop.org/

And in jhbuild we use a custom evince branch 
http://dev.laptop.org/git?p=users/rwh/evince;a=summary

Thanks for clearing up,
    Simon
Permalink | Reply | 2 comments |
headers
Simon Schampijer | 1 Oct 15:22
Picon

Re: evince/poppler

Simon Schampijer wrote:
> Hi,
> 
> we are using an old version of evince and poppler. Are there any 
> intentions to update?
> 
> Current poppler we use is 0.6 and the latest stable is 0.8 
> http://poppler.freedesktop.org/
> 
> And in jhbuild we use a custom evince branch 
> http://dev.laptop.org/git?p=users/rwh/evince;a=summary
> 
> Thanks for clearing up,
>     Simon

Hah, found the answer :)
http://dev.laptop.org/ticket/7926

Best,
    Simon
Permalink | Reply | 0 comments |
headers
Mikus Grinbergs | 1 Oct 14:49
Favicon

Re: another response time

> as you probably installed previously the Wikipedia activity, my guess
> is that the jffs2 gc thread was taking most of the CPU.

If I understand correctly, this raises the possibility that other 
actions performed *prior* to the launching of an Activity can 
noticeably affect the time it takes to launch that Activity.

Would someone else please launch XaoS, and see what kind of 
"response time for the launch" they get?

Tried it again, after the XO had sat there overnight (having now 
hopefully done everything it needed to, for jffs2 housekeeping). 
For me, the "launch screen" for XaoS pulsed for 100 seconds before 
the "activity screen" was drawn.  [My guess is that it is 
calculating the fractal picture before showing it.]

mikus
Permalink | Reply | 1169 comments |

Gmane