Re: patch - editable GeckoEmbed subclass

Robert Staudinger wrote:
> On 7/31/06, Marco Pesenti Gritti <mpg <at> redhat.com> wrote:
>
> [...]
>
>> > Done except for the relicensing. Galeon and epiphany heritage are
>> > making that a bit more involved.
>>
>> Thanks! For dealing with the relicensing pain too...
>>
>> > The OLPC's browser app will need fixing (geckoembed.Embed to
>> > geckoembed.Browser).
>
> Patch attached.
> For those who didn't follow the thread: you will need this patch to
> run the browser activity in a HEAD build.

Yeah please go ahead and check it in now that you have an account...
(You will have conflicts since I already checked in a quick fix)

Thanks!
Marco

Emulating the laptop display with Xephyr

Hi all !

[Reposting from devel <at> laptop.org, on Marco's request  ]

I already made a small report about this in my "weekly summary" for
Summer of Code projects, but I've been told that it would be a good
idea to advertise it a little more properly on the list, so here it is
:)

It seems necessary to emulate the laptop's display and the DCON chip's
special features (color swizzling, antialiasing) while designing
Sugar, in order to keep an eye on what things will actually look like,
and address problems such as small graphic elements (small fonts, thin
lines).

Here :

http://www.manucornet.net/pub/olpc/xephyr_swizzle.diff

you will find a patch for Xephyr (in particular, the
hw/kdrive/ephyr/hostx.c file) that emulates the laptop's display, with
both color swizzling and antialiasing.

There are a few screenshots on the project's wiki page :

http://wiki.laptop.org/go/GTK_for_OLPC

In particular, check out the difference between antialiased and not
antialiased swizzling :

Error in compilation

_______________________________________________
Sugar mailing list
Sugar <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/sugar

[OLPC-devel] OLPC theme benchmarked

Hi !

I have been coding a small "torture" application for GTK themes [1],
which mainly does two things: 1) crash test the engine by calling all
the GTK paint functions with unsual parameters and 2) measure the time
the theme takes to create/map/expose/resize/destroy widgets (with help
from Federico's widget profiler's infrastructure).

While fixing the OLPC theme to pass my crash test [2], I noticed that it
was quite a bit slower than I expected, so I thought that precise time
measures would be interesting. I hope this is useful, it will definitely
help me in the next few days :)

The full report is available as a spreadsheet [3]. Before writing a
short analysis, a few disclaimers:

* The main point of this benchmarking is to have a record of the current
speed (so that we can see how it evolves when some more work has been
done). The theme is a work in progress, and therefore understandably
still very slow compared to more polished ones.

* I tried my best to make the testing conditions as stable as possible:
same computer (of course), same programs running in the background,
tests performed within a small time window, etc.

* The different time measures correspond to the few important events in
a widget's life: create, map, expose, destroy. The "expose with resize"
corresponds to resizing the widget a lot of times (from a very small
size to a very big size) and measuring the expose time for each size.

* Each cell of the document is an amount of time (in seconds) averaged
from about 80 iterations of the same event, on the same type of widget.

* These are only observations, not explanations. Make the slow parts
faster will be the next job!

* Absolute time values aren't that useful, but ratios are more
interesting.

Okay, so a few observations:

* Create : ratios vary from 0.92 to 1.07, showing that create time is
pretty much the same for all themes, for each type of widget.

* Mapping a widget takes the OLPC theme about twice as much time as
Clearlooks (or HighContrast).

* Destroy is always slightly (30 %) faster on OLPC than on Clearlooks,
but slower than HighContrast (about 1.4 ratio). Destroy time are pretty
much the same between OLPC and Human (Ubuntu's theme) -- ratio ~ 1.

* Expose is a bit slower (1.9 ratio, and sometimes a little faster) with
OLPC than with Clearlooks or HighContrast, but faster than Human.

* Expose with resize is the most CPU-consuming task, and therefore
probably yields the most significant results. And the OLPC theme doesn't
do well with this one: it is from 30 to 130 times slower than Clearlooks
(50 times on average), and 35 times slower than Human.

I'll spend the next few weeks (along with the other developers of the
theme) trying to bring those numbers down while still aiming towards
Diana's great mockups :o)

Cheers,
Manu

[1]
http://wiki.laptop.org/go/GTK_for_OLPC#GTK_theme.2Fengine_torturer_and_crash_tester

[2]  See the report at
http://www.manucornet.net/pub/olpc/log_olpc_theme_torture.txt

[3] http://www.manucornet.net/pub/Themes_performance.ods

Re: [OLPC-devel] OLPC theme benchmarked

Is this with Jordan's new driver?  If so, we may have run into a slow
path that might be able to be sped up....  If not, it is time to install
his driver....
                           - Jim 

On Wed, 2006-08-02 at 15:21 +0200, Manu Cornet wrote:
> 
> Hi !
> 
> I have been coding a small "torture" application for GTK themes [1],
> which mainly does two things: 1) crash test the engine by calling all
> the GTK paint functions with unsual parameters and 2) measure the time
> the theme takes to create/map/expose/resize/destroy widgets (with help
> from Federico's widget profiler's infrastructure).
> 
> While fixing the OLPC theme to pass my crash test [2], I noticed that it
> was quite a bit slower than I expected, so I thought that precise time
> measures would be interesting. I hope this is useful, it will definitely
> help me in the next few days :)
> 
> 
> The full report is available as a spreadsheet [3]. Before writing a
> short analysis, a few disclaimers:
> 
> * The main point of this benchmarking is to have a record of the current
> speed (so that we can see how it evolves when some more work has been
> done). The theme is a work in progress, and therefore understandably
> still very slow compared to more polished ones.
> 
> * I tried my best to make the testing conditions as stable as possible:
> same computer (of course), same programs running in the background,
> tests performed within a small time window, etc.
> 
> * The different time measures correspond to the few important events in
> a widget's life: create, map, expose, destroy. The "expose with resize"
> corresponds to resizing the widget a lot of times (from a very small
> size to a very big size) and measuring the expose time for each size.
> 
> * Each cell of the document is an amount of time (in seconds) averaged
> from about 80 iterations of the same event, on the same type of widget.
> 
> * These are only observations, not explanations. Make the slow parts
> faster will be the next job!
> 
> * Absolute time values aren't that useful, but ratios are more
> interesting.
> 
> 
> Okay, so a few observations:
> 
> * Create : ratios vary from 0.92 to 1.07, showing that create time is
> pretty much the same for all themes, for each type of widget.
> 
> * Mapping a widget takes the OLPC theme about twice as much time as
> Clearlooks (or HighContrast).
> 
> * Destroy is always slightly (30 %) faster on OLPC than on Clearlooks,
> but slower than HighContrast (about 1.4 ratio). Destroy time are pretty
> much the same between OLPC and Human (Ubuntu's theme) -- ratio ~ 1.
> 
> * Expose is a bit slower (1.9 ratio, and sometimes a little faster) with
> OLPC than with Clearlooks or HighContrast, but faster than Human.
> 
> * Expose with resize is the most CPU-consuming task, and therefore
> probably yields the most significant results. And the OLPC theme doesn't
> do well with this one: it is from 30 to 130 times slower than Clearlooks
> (50 times on average), and 35 times slower than Human.
> 
> I'll spend the next few weeks (along with the other developers of the
> theme) trying to bring those numbers down while still aiming towards
> Diana's great mockups :o)
> 
> Cheers,
> Manu
> 
> [1]
> http://wiki.laptop.org/go/GTK_for_OLPC#GTK_theme.2Fengine_torturer_and_crash_tester
> 
> [2]  See the report at
> http://www.manucornet.net/pub/olpc/log_olpc_theme_torture.txt
> 
> [3] http://www.manucornet.net/pub/Themes_performance.ods
> 
> _______________________________________________
> Devel mailing list
> Devel <at> laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
--

-- 
Jim Gettys
One Laptop Per Child

[OLPC-devel] Re: [sugar] Pygtk and garbage collecting

On Mon, 2006-07-31 at 17:32 +0200, Philip Van Hoof wrote:

> In case of tinymail the GtkTreeModel that holds a reference on all the
> headers of the current folder, is such an object. 
> 
> model = MsgHeaderListModel ()
> treeview.set_model (model)
> 
> newmodel = MsgHeaderListModel ()
> treeview.set_model (newmodel)
> 
> Will not immediately mark "model" for garbage collection (when model
> goes out of scope). Adding a gc.collect(), however, will. 

The usual idiom  is to have a way to explicitly dispose an object which
holds a reference to a non-GC resource.  In C# you do

  obj = new SomeObject ();
  treeview.set_model (obj);

  newobj = new SomeObject ();
  treeview.set_model (newobj);

  obj.Dispose ();

or use syntactic sugar:

  using (Gdk.Pixbuf pixbuf = new Gdk.Pixbuf ("foo.jpg")) {
      do_something_with_pixbuf (pixbuf);
  } /* exiting the "using" block disposes the pixbuf */

This is pretty useful for managed objects which maintain non-managed
data (file descriptors, memory buffers, database connections, etc.).

Does Python let you do something like this?

  Federico

Re: [OLPC-devel] OLPC theme benchmarked

On Wed, 2006-08-02 at 10:51 -0400, Jim Gettys wrote:

> > I'll spend the next few weeks (along with the other developers of the
> > theme) trying to bring those numbers down while still aiming towards
> > Diana's great mockups :o)

Wow, this is *fantastic* info!

Could you run sysprof on the benchmark to see what's eating all the
time?

  Federico

Re: Emulating the laptop display with Xephyr

On Tue, 2006-08-01 at 15:44 +0200, Manu Cornet wrote:
> Hi all !
> 
> [Reposting from devel <at> laptop.org, on Marco's request  ]
> 
> It seems necessary to emulate the laptop's display and the DCON chip's
> special features (color swizzling, antialiasing) while designing
> Sugar, in order to keep an eye on what things will actually look like,
> and address problems such as small graphic elements (small fonts, thin
> lines).

You should try some filtering (I want to try it out myself but that may
not happen this week or next).  The idea is to use a convolution filter
to distribute the energy among the neighboring pixels that have
different color, such that you don't lose data in the single-channel
pixels.  Try the following for example:

  1 2 3 2 1
  2 4 6 4 2
  3 6 9 6 3     (all divided by 81)
  2 4 6 4 2
  1 2 3 2 1

Check this page out for more details (that's about subpixel text
rendering, but this is quite similar):

  http://www.grc.com/cttech.htm

Note that this technique may be infringing some patents owned by Apple.
Needs further investigation if to be used.

behdad

> Here :
> 
> http://www.manucornet.net/pub/olpc/xephyr_swizzle.diff
> 
> you will find a patch for Xephyr (in particular, the
> hw/kdrive/ephyr/hostx.c file) that emulates the laptop's display, with
> both color swizzling and antialiasing.
> 
> There are a few screenshots on the project's wiki page :
> 
> http://wiki.laptop.org/go/GTK_for_OLPC
> 
> In particular, check out the difference between antialiased and not
> antialiased swizzling :
> 
> http://wiki.laptop.org/go/GTK_for_OLPC#Color_swizzling_and_antialiasing
> 
> If you're designing anything from the Sugar UI, you might want to give
> it a try.
> 
> This display simulation is not actually loyal to the final appearance,
> since the display will have much more luminosity than this (as far as
> I know), but it's already a good preview. Plans are also to make the
> display 16 bit (instead of 24 bit currently) to match the actual
> hardware more closely.
> 
> Of course, feedback is most welcome, especially bug reports and
> screenshots!
> 
> Cheers,
> Manu

--

-- 
behdad
http://behdad.org/

_______________________________________________
Sugar mailing list
Sugar <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/sugar

Re: Emulating the laptop display with Xephyr

Hi Behdad!

> You should try some filtering (I want to try it out myself but that may
> not happen this week or next).  The idea is to use a convolution filter
> to distribute the energy among the neighboring pixels that have
> different color, such that you don't lose data in the single-channel
> pixels.  Try the following for example:
> 
>   1 2 3 2 1
>   2 4 6 4 2
>   3 6 9 6 3     (all divided by 81)
>   2 4 6 4 2
>   1 2 3 2 1

This would certainly improve the display, but will the OLPC hardware
actually be able to do that (I know it performs AA with 4 neighbors, not
sure it will do it with 24)? My goal is more to simulate the hardware's
behavior (DCON chip) as closely as possible than to get a nice display
in Xephyr.

Cheers,
Manu

Re: Emulating the laptop display with Xephyr

On Thu, 2006-08-03 at 10:54 +0200, Manu Cornet wrote:
> Hi Behdad!
> 
> > You should try some filtering (I want to try it out myself but that may
> > not happen this week or next).  The idea is to use a convolution filter
> > to distribute the energy among the neighboring pixels that have
> > different color, such that you don't lose data in the single-channel
> > pixels.  Try the following for example:
> > 
> >   1 2 3 2 1
> >   2 4 6 4 2
> >   3 6 9 6 3     (all divided by 81)
> >   2 4 6 4 2
> >   1 2 3 2 1
> 
> This would certainly improve the display, but will the OLPC hardware
> actually be able to do that (I know it performs AA with 4 neighbors, not
> sure it will do it with 24)? My goal is more to simulate the hardware's
> behavior (DCON chip) as closely as possible than to get a nice display
> in Xephyr.

Right.  I didn't know what exactly the chip does.  Reading your patch, I
gather it's doing this:

    1
  1 4 1
    1

That's probably a good approximation with only four neighbors, but a
more accurate one is:

    1
  1 2 1
    1

but it's harder to do in the chip as it needs division.  Now that you
have made the patch, we can experiment with different filters and see
how they affect the output.  I'm sure the chip designers have done this
work already and came up with the current setting, but it's still
interesting to see if the output can be improved further.

A sidenote about your patch.  I think the reason RGB channels are
inverted is that your machine is little-endian and the channels are
stored as ARGB in a word.

> Cheers,
> Manu

Cheers,
--

-- 
behdad
http://behdad.org/

_______________________________________________
Sugar mailing list
Sugar <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/sugar