Emulating the laptop display with Xephyr

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Emulating the laptop display with Xephyr

Manu Cornet-2

Hi all !

[Reposting from [hidden email], 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 :

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


Reply | Threaded
Open this post in threaded view
|

Emulating the laptop display with Xephyr

Behdad Esfahbod-4
On Tue, 2006-08-01 at 15:44 +0200, Manu Cornet wrote:
> Hi all !
>
> [Reposting from [hidden email], 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.laptop.org/pipermail/sugar/attachments/20060802/c9afe54f/attachment.bin
Reply | Threaded
Open this post in threaded view
|

Emulating the laptop display with Xephyr

Manu Cornet-2

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

Reply | Threaded
Open this post in threaded view
|

Emulating the laptop display with Xephyr

Behdad Esfahbod-4
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.laptop.org/pipermail/sugar/attachments/20060803/65da28a4/attachment.bin