Centralization of graphical awesomeness

[hab keen oh ne]

Some javascript/style in this post has been disabled (why?)

Hi community,
Im using the neo freerunner for 2 years now as an every day phone. It has great features which allow combined with the openness a great functionality (for instance I use the accelerator as some kind of wii controller). But theres one huge problem I have. Its ugly, and the ui is slow, too slow, despite maybe QtMoko. I cannot hand the phone to my parents and say 'Here, take a call'. Besides, under SHR scrolling between the applications is so slow, it even decreases the usability. And the sex appeal of the SHR GUI is near to nothing. So I suggest to centralize those issues at least on one wiki page with the aim to:
get graphical hardware acceleration with the glamo chip (even 2d acceleration would be great for the gui)
provide pretty UIs, especially some SHR themes would be great.
create a good web browser offering smooth scrolling.
Greetings,
MArtin.

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Carsten Haitzler (The Rasterman)-2]

On Mon, 26 Oct 2009 09:27:16 +0000 (GMT) hab keen oh ne <[hidden email]>
said:

> Hi community,
> Im using the neo freerunner for 2 years now as an every day phone. It has
> great features which allow combined with the openness a great functionality
> (for instance I use the accelerator as some kind of wii controller). But
> theres one huge problem I have. Its ugly, and the ui is slow, too slow,
> despite maybe QtMoko. I cannot hand the phone to my parents and say 'Here,
> take a call'. Besides, under SHR scrolling between the applications is so
> slow, it even decreases the usability. And the sex appeal of the SHR GUI is
> near to nothing. So I suggest to centralize those issues at least on one wiki
> page with the aim to: get graphical hardware acceleration with the glamo chip
> (even 2d acceleration would be great for the gui) provide pretty UIs,
> especially some SHR themes would be great. create a good web browser offering
> smooth scrolling. Greetings, MArtin.

1. acceleration isn't goint to help.. because what you gain in accel, you'll
lose in the now slower software fallbacks. the problem is glamo simply CANNOT
accelerate all the operations you want
2. and those operations it can, come with a nice list of gotchas that make
implementation of acceleration awful.
3. you can't speed up one of the nastiest bits of glamo. the 7mb/sec write
rates to glamo. thats slower than my slow 100mbit network. the local graphcis
chip is slower than the machine on the other side of my home. put that into
perspective. it's got a high res screen, a very very very slow bus to access
video memory. it's just bad. this is always going to bottleneck something.
4. the video bus is SHARED with sd card disk IO. so that 7m/sec needs to be
shared when doing IO on the micro-sd card.

you know how gta02 works better? run in qvga. it's 1/4 the # of pixels to draw.
you'll get something like a 4x speedup. most phones with that generation of cpu
are qvga anyway. there's a reason iphone and all the other phones look nicer.
they use avga or hvga (240x320 or 320x480). iphone is by far a more powerful
system with no nasty bottleneck to video memory (and as of the 3gs is has
opengles 2.0  hardware which is decent-ish).

the gta02's achillies heel is the slow memory bus access to video ram and the
large # of pixels needing drawing. gta02 would have appeared to perform much
better if it was qvga only.

gta02 is like trying to pull a caravan with a ride-on lawnmower. then
complaining why it's so slow. ITS a LAWNMOWER PULLING A CARAVAN! THAT'S WHY!.
you either get a car or something decent to pull the caravan (ie buy a modern
phone built on modern technology. iphone 3gs, palm pre, nokia n900, samsung 360
n/h1, etc. etc.) or... you replace the caravan with something smaller and not
so flashy that you can still sleep in.

you want speed? you will need to give up something. if you still want it to
look nice, then drop pixels. its the simplest and easiest solution. its the
right resolution for that cpu anyway. the glamo will still hurt you, but not as
much.

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [hidden email]


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Evgeniy Karyakin]

2009/10/26 Carsten Haitzler <[hidden email]>:
> you want speed? you will need to give up something. if you still want it to
> look nice, then drop pixels. its the simplest and easiest solution. its the
> right resolution for that cpu anyway. the glamo will still hurt you, but not as
> much.

   I'm sure everybody who has any professional connections with
Freerunner+Glamo development already took all possible measures to
solve this problem. But what concrete steps were taken to ease Glamo
bottleneck? If its throughput is so narrow, can we lower amount of
data flowing through it? There's one neighbor unanswered thread with a
question on how to start the kernel with qvga resolution. Aside of
this, what can be reduced, for example amount of available colours
(256 or even 16)? And if this [too] low throughput only of video
memory channel?

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Carsten Haitzler (The Rasterman)-2]

On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin <[hidden email]>
said:

> 2009/10/26 Carsten Haitzler <[hidden email]>:
> > you want speed? you will need to give up something. if you still want it to
> > look nice, then drop pixels. its the simplest and easiest solution. its the
> > right resolution for that cpu anyway. the glamo will still hurt you, but
> > not as much.
>
>    I'm sure everybody who has any professional connections with
> Freerunner+Glamo development already took all possible measures to
> solve this problem. But what concrete steps were taken to ease Glamo
> bottleneck? If its throughput is so narrow, can we lower amount of

none. it's a hardware issue. you simply cant read or write to video ram faster
than that. andy tried timing stuff all that happened was instability from
memory. glamo is most likely also the cause for the cpu runnig at 400 not
500mhz. the extra load on the memory bus (because glamo is hooked there
externally providing another addressable chip) probably caused the instability.
remove it and there is a big change the cpu could run at 500mhz instead of 400.
it's rated to do 500. (yes power consumption would go up - but it'd only be up
while its on. when suspended it wont matter).

> data flowing through it? There's one neighbor unanswered thread with a

render on the device - and this will then limit what you can render. evas can't
be fully accelerated by the glamo. it has too many opretations. a bit like
asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx
chip ever was designed to do and you will hit software fallbacks. evas has
multiple engnines. software (which is what is used - the 16bit renderer as
opposed to the full 32bit one). it has xrender - if xrender were fully
accelerated this should be better, but glamo cannot fully accelerate all the
ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet
is you'll end up same speed as the pure software engine, or worse. aftera
bunch of hard work you'll have gone nowhere. evas also has a gl and gles2
engine - but thats no use on glamo. it's gles1.1 and very limited (from memory
texture size is 256x256 which is pretty useless for 2d as most data you deal
with breaks these bounds).

> question on how to start the kernel with qvga resolution. Aside of

no need to do that - just configure x for qgva. :)

> this, what can be reduced, for example amount of available colours
> (256 or even 16)? And if this [too] low throughput only of video
> memory channel?

256 won't help. it increases complexity and really reduces display quality
through the floor. the best best is qvga 16bpp. its simple. it doesn't require
any hard work. it is actually the most common resolution for most phones and
devices out there so the software is more portable if you work on that (and
then higher). but... in the past everyone has moaned and complained and refused
to use it, and insisted on their vga resolution... and then complained about
speed.

if people don't believe me that the gta02 is just plain a "bad bit of
hardware and you have few choices" here's some examples. here'es an ooold efl
demo app i did:

http://www.rasterman.com/files/eem.avi
and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320).
it's from like 2001/2002 (from memory). its ancient. and watch it run evas:
http://www.rasterman.com/files/eem-live.avi

here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m
ram, and 800x480 (higher res than gta02):

http://www.rasterman.com/files/ello-elementary-smartq5.mp4

everywhere i look... theres much better hardware. if you look at performance vs
age of hardware (when it was released) gta02 is almost at the bottom of the
pile. :( you simply have a bad piece of hardware if you want graphics
performance. as soon as you acknowledge that and either downgrade the device
resolution for example to bring it in line with its performance, or just use
different hardware, the better life will be :)

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [hidden email]


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Vasco Névoa]

Downgrading to QVGA is something that should have been done a long time ago.
There's no point in trying to force a badly designed system.

How do we do it? Which files must be changed?


Citando Carsten Haitzler <[hidden email]>:

> On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin  
> <[hidden email]>
> said:
>
>> 2009/10/26 Carsten Haitzler <[hidden email]>:
>> > you want speed? you will need to give up something. if you still  
>> want it to
>> > look nice, then drop pixels. its the simplest and easiest  
>> solution. its the
>> > right resolution for that cpu anyway. the glamo will still hurt you, but
>> > not as much.
>>
>>    I'm sure everybody who has any professional connections with
>> Freerunner+Glamo development already took all possible measures to
>> solve this problem. But what concrete steps were taken to ease Glamo
>> bottleneck? If its throughput is so narrow, can we lower amount of
>
> none. it's a hardware issue. you simply cant read or write to video  
> ram faster
> than that. andy tried timing stuff all that happened was instability from
> memory. glamo is most likely also the cause for the cpu runnig at 400 not
> 500mhz. the extra load on the memory bus (because glamo is hooked there
> externally providing another addressable chip) probably caused the  
> instability.
> remove it and there is a big change the cpu could run at 500mhz  
> instead of 400.
> it's rated to do 500. (yes power consumption would go up - but it'd  
> only be up
> while its on. when suspended it wont matter).
>
>> data flowing through it? There's one neighbor unanswered thread with a
>
> render on the device - and this will then limit what you can render.  
> evas can't
> be fully accelerated by the glamo. it has too many opretations. a bit like
> asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx
> chip ever was designed to do and you will hit software fallbacks. evas has
> multiple engnines. software (which is what is used - the 16bit renderer as
> opposed to the full 32bit one). it has xrender - if xrender were fully
> accelerated this should be better, but glamo cannot fully accelerate all the
> ops evas uses, so... it will rely on software fallbacks. thus slow  
> down. my bet
> is you'll end up same speed as the pure software engine, or worse. aftera
> bunch of hard work you'll have gone nowhere. evas also has a gl and gles2
> engine - but thats no use on glamo. it's gles1.1 and very limited  
> (from memory
> texture size is 256x256 which is pretty useless for 2d as most data you deal
> with breaks these bounds).
>
>> question on how to start the kernel with qvga resolution. Aside of
>
> no need to do that - just configure x for qgva. :)
>
>> this, what can be reduced, for example amount of available colours
>> (256 or even 16)? And if this [too] low throughput only of video
>> memory channel?
>
> 256 won't help. it increases complexity and really reduces display quality
> through the floor. the best best is qvga 16bpp. its simple. it  
> doesn't require
> any hard work. it is actually the most common resolution for most phones and
> devices out there so the software is more portable if you work on that (and
> then higher). but... in the past everyone has moaned and complained  
> and refused
> to use it, and insisted on their vga resolution... and then complained about
> speed.
>
> if people don't believe me that the gta02 is just plain a "bad bit of
> hardware and you have few choices" here's some examples. here'es an ooold efl
> demo app i did:
>
> http://www.rasterman.com/files/eem.avi
> and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash,  
> qvga(240x320).
> it's from like 2001/2002 (from memory). its ancient. and watch it run evas:
> http://www.rasterman.com/files/eem-live.avi
>
> here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m
> ram, and 800x480 (higher res than gta02):
>
> http://www.rasterman.com/files/ello-elementary-smartq5.mp4
>
> everywhere i look... theres much better hardware. if you look at  
> performance vs
> age of hardware (when it was released) gta02 is almost at the bottom of the
> pile. :( you simply have a bad piece of hardware if you want graphics
> performance. as soon as you acknowledge that and either downgrade the device
> resolution for example to bring it in line with its performance, or just use
> different hardware, the better life will be :)
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    [hidden email]
>
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community
>

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Carsten Haitzler (The Rasterman)-2]

On Mon, 26 Oct 2009 12:23:51 +0000 Vasco Névoa <[hidden email]> said:

>
> Downgrading to QVGA is something that should have been done a long time ago.
> There's no point in trying to force a badly designed system.
>
> How do we do it? Which files must be changed?

last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2.
xrandr to runtime select it. note that toushcreen driver didn't account for res
change so ts coords were still assuming 480x640 - this is a small fix needed
for it to be totally usable. not sure if this was ever fixed, but if it
hasn't been - this is a good indicator of how no one has bothered with qvga.
thus the complaints. try it. you'll find it significantly faster. see videos
below - 206mhz ipaq3660.. smooth.

> Citando Carsten Haitzler <[hidden email]>:
>
> > On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin  
> > <[hidden email]>
> > said:
> >
> >> 2009/10/26 Carsten Haitzler <[hidden email]>:
> >> > you want speed? you will need to give up something. if you still  
> >> want it to
> >> > look nice, then drop pixels. its the simplest and easiest  
> >> solution. its the
> >> > right resolution for that cpu anyway. the glamo will still hurt you, but
> >> > not as much.
> >>
> >>    I'm sure everybody who has any professional connections with
> >> Freerunner+Glamo development already took all possible measures to
> >> solve this problem. But what concrete steps were taken to ease Glamo
> >> bottleneck? If its throughput is so narrow, can we lower amount of
> >
> > none. it's a hardware issue. you simply cant read or write to video  
> > ram faster
> > than that. andy tried timing stuff all that happened was instability from
> > memory. glamo is most likely also the cause for the cpu runnig at 400 not
> > 500mhz. the extra load on the memory bus (because glamo is hooked there
> > externally providing another addressable chip) probably caused the  
> > instability.
> > remove it and there is a big change the cpu could run at 500mhz  
> > instead of 400.
> > it's rated to do 500. (yes power consumption would go up - but it'd  
> > only be up
> > while its on. when suspended it wont matter).
> >
> >> data flowing through it? There's one neighbor unanswered thread with a
> >
> > render on the device - and this will then limit what you can render.  
> > evas can't
> > be fully accelerated by the glamo. it has too many opretations. a bit like
> > asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx
> > chip ever was designed to do and you will hit software fallbacks. evas has
> > multiple engnines. software (which is what is used - the 16bit renderer as
> > opposed to the full 32bit one). it has xrender - if xrender were fully
> > accelerated this should be better, but glamo cannot fully accelerate all the
> > ops evas uses, so... it will rely on software fallbacks. thus slow  
> > down. my bet
> > is you'll end up same speed as the pure software engine, or worse. aftera
> > bunch of hard work you'll have gone nowhere. evas also has a gl and gles2
> > engine - but thats no use on glamo. it's gles1.1 and very limited  
> > (from memory
> > texture size is 256x256 which is pretty useless for 2d as most data you deal
> > with breaks these bounds).
> >
> >> question on how to start the kernel with qvga resolution. Aside of
> >
> > no need to do that - just configure x for qgva. :)
> >
> >> this, what can be reduced, for example amount of available colours
> >> (256 or even 16)? And if this [too] low throughput only of video
> >> memory channel?
> >
> > 256 won't help. it increases complexity and really reduces display quality
> > through the floor. the best best is qvga 16bpp. its simple. it  
> > doesn't require
> > any hard work. it is actually the most common resolution for most phones and
> > devices out there so the software is more portable if you work on that (and
> > then higher). but... in the past everyone has moaned and complained  
> > and refused
> > to use it, and insisted on their vga resolution... and then complained about
> > speed.
> >
> > if people don't believe me that the gta02 is just plain a "bad bit of
> > hardware and you have few choices" here's some examples. here'es an ooold
> > efl demo app i did:
> >
> > http://www.rasterman.com/files/eem.avi
> > and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash,  
> > qvga(240x320).
> > it's from like 2001/2002 (from memory). its ancient. and watch it run evas:
> > http://www.rasterman.com/files/eem-live.avi
> >
> > here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m
> > ram, and 800x480 (higher res than gta02):
> >
> > http://www.rasterman.com/files/ello-elementary-smartq5.mp4
> >
> > everywhere i look... theres much better hardware. if you look at  
> > performance vs
> > age of hardware (when it was released) gta02 is almost at the bottom of the
> > pile. :( you simply have a bad piece of hardware if you want graphics
> > performance. as soon as you acknowledge that and either downgrade the device
> > resolution for example to bring it in line with its performance, or just use
> > different hardware, the better life will be :)
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    [hidden email]
> >
> >
> > _______________________________________________
> > Openmoko community mailing list
> > [hidden email]
> > http://lists.openmoko.org/mailman/listinfo/community
> >
>
>
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community
>

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [hidden email]


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Marcel-2]

Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler:

> On Mon, 26 Oct 2009 12:23:51 +0000 Vasco Névoa <[hidden email]> said:
>
> >
> > Downgrading to QVGA is something that should have been done a long time ago.
> > There's no point in trying to force a badly designed system.
> >
> > How do we do it? Which files must be changed?
>
> last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2.
> xrandr to runtime select it. note that toushcreen driver didn't account for res
> change so ts coords were still assuming 480x640 - this is a small fix needed
> for it to be totally usable. not sure if this was ever fixed, but if it
> hasn't been - this is a good indicator of how no one has bothered with qvga.
> thus the complaints. try it. you'll find it significantly faster. see videos
> below - 206mhz ipaq3660.. smooth.

I tried to got to qvga for graphics performance testing about a week
ago. This is needed (tested on SHR's 2.6.29-rc3):
echo "qvga-normal" > /sys/bus/spi/devices/spi2.0/state
xrandr -s 240x320

To return to vga:
echo "normal" > /sys/bus/spi/devices/spi2.0/state
xrandr -s 480x640

Problems:
- SHR's pin entry dialogue and shr-today have a too large font so
they're hard to read, but still (kinda) usable, didn't try other apps
http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png
(yes, that's the whole screen)
- graphics in general are far too light, most colors become whiteish
- colored stripes horizontally over the whole display, but are invisible
on screenshots (naturally) - the same as above, but photographed:
http://d-a300.selfip.net/files/shr-today-qvga.jpg

If our software would run well in that resolution and if the display
would make it (better than now), I would clearly prefer qvga for
performance. I was about to write a little game, but that's impossible
with that horrible vga rendering performance.

--
Marcel


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Carsten Haitzler (The Rasterman)-2]

On Mon, 26 Oct 2009 14:53:50 +0100 Marcel <[hidden email]> said:

> Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler:
> > On Mon, 26 Oct 2009 12:23:51 +0000 Vasco Névoa <[hidden email]> said:
> >
> > >
> > > Downgrading to QVGA is something that should have been done a long time
> > > ago. There's no point in trying to force a badly designed system.
> > >
> > > How do we do it? Which files must be changed?
> >
> > last i checked... 1. xmd-line option to xglamo (kdrive) server to select
> > it, 2. xrandr to runtime select it. note that toushcreen driver didn't
> > account for res change so ts coords were still assuming 480x640 - this is a
> > small fix needed for it to be totally usable. not sure if this was ever
> > fixed, but if it hasn't been - this is a good indicator of how no one has
> > bothered with qvga. thus the complaints. try it. you'll find it
> > significantly faster. see videos below - 206mhz ipaq3660.. smooth.
>
> I tried to got to qvga for graphics performance testing about a week
> ago. This is needed (tested on SHR's 2.6.29-rc3):
> echo "qvga-normal" > /sys/bus/spi/devices/spi2.0/state
> xrandr -s 240x320
>
> To return to vga:
> echo "normal" > /sys/bus/spi/devices/spi2.0/state
> xrandr -s 480x640
>
> Problems:
> - SHR's pin entry dialogue and shr-today have a too large font so
> they're hard to read, but still (kinda) usable, didn't try other apps
> http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png
> (yes, that's the whole screen)
> - graphics in general are far too light, most colors become whiteish
> - colored stripes horizontally over the whole display, but are invisible
> on screenshots (naturally) - the same as above, but photographed:
> http://d-a300.selfip.net/files/shr-today-qvga.jpg
>
> If our software would run well in that resolution and if the display
> would make it (better than now), I would clearly prefer qvga for
> performance. I was about to write a little game, but that's impossible
> with that horrible vga rendering performance.

did dpi get adjusted too? still 285dpi? check e's scaling settings. it can
adapt to dpi if it is set up to do so. it also has a manual scale switch to set
it to whatever u want. whatever e sets, elementary inherits too, unless the
theme has been done in such a way not to allow scaling (the default does).
custom written edje files with font may also not scale for the same reason a
different elm theme may not. if things are done right it should just magically
"work" on qvga and look wonderful.

as for display artifacts - maybe its a refresh issue or a screen timing issue.
not sure. i remember those screen artifacts long ago (like before freerunner
was even released). looks like nothing has been fixed since :)

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [hidden email]


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Marcel-2]

Am Dienstag, den 27.10.2009, 01:02 +1100 schrieb Carsten Haitzler:

> On Mon, 26 Oct 2009 14:53:50 +0100 Marcel <[hidden email]> said:
>
> > Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler:
> > > On Mon, 26 Oct 2009 12:23:51 +0000 Vasco Névoa <[hidden email]> said:
> > >
> > > >
> > > > Downgrading to QVGA is something that should have been done a long time
> > > > ago. There's no point in trying to force a badly designed system.
> > > >
> > > > How do we do it? Which files must be changed?
> > >
> > > last i checked... 1. xmd-line option to xglamo (kdrive) server to select
> > > it, 2. xrandr to runtime select it. note that toushcreen driver didn't
> > > account for res change so ts coords were still assuming 480x640 - this is a
> > > small fix needed for it to be totally usable. not sure if this was ever
> > > fixed, but if it hasn't been - this is a good indicator of how no one has
> > > bothered with qvga. thus the complaints. try it. you'll find it
> > > significantly faster. see videos below - 206mhz ipaq3660.. smooth.
> >
> > I tried to got to qvga for graphics performance testing about a week
> > ago. This is needed (tested on SHR's 2.6.29-rc3):
> > echo "qvga-normal" > /sys/bus/spi/devices/spi2.0/state
> > xrandr -s 240x320
> >
> > To return to vga:
> > echo "normal" > /sys/bus/spi/devices/spi2.0/state
> > xrandr -s 480x640
> >
> > Problems:
> > - SHR's pin entry dialogue and shr-today have a too large font so
> > they're hard to read, but still (kinda) usable, didn't try other apps
> > http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png
> > (yes, that's the whole screen)
> > - graphics in general are far too light, most colors become whiteish
> > - colored stripes horizontally over the whole display, but are invisible
> > on screenshots (naturally) - the same as above, but photographed:
> > http://d-a300.selfip.net/files/shr-today-qvga.jpg
> >
> > If our software would run well in that resolution and if the display
> > would make it (better than now), I would clearly prefer qvga for
> > performance. I was about to write a little game, but that's impossible
> > with that horrible vga rendering performance.
>
> did dpi get adjusted too? still 285dpi? check e's scaling settings. it can
> adapt to dpi if it is set up to do so. it also has a manual scale switch to set
> it to whatever u want. whatever e sets, elementary inherits too, unless the
> theme has been done in such a way not to allow scaling (the default does).
> custom written edje files with font may also not scale for the same reason a
> different elm theme may not. if things are done right it should just magically
> "work" on qvga and look wonderful.
>
> as for display artifacts - maybe its a refresh issue or a screen timing issue.
> not sure. i remember those screen artifacts long ago (like before freerunner
> was even released). looks like nothing has been fixed since :)

A killall -HUP enlightenment at least fixed scaling for "pure" E stuff.
shr-today also looks okay, but the flaunch bar is too large. Haven't
tested anything else since the touchable area is reduced to about the
upper left half of the screen, so it's unusable. And still these
timing-things...


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Eric Olson-4]

Vasco Névoa wrote:

> Downgrading to QVGA is something that should have been done a long time ago.
> There's no point in trying to force a badly designed system.
>
> How do we do it? Which files must be changed?
>
>
> Citando Carsten Haitzler <[hidden email]>:
>
>> On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin  
>> <[hidden email]>
>> said:
>>
>>> 2009/10/26 Carsten Haitzler <[hidden email]>:
>>>> you want speed? you will need to give up something. if you still  
>>> want it to
>>>> look nice, then drop pixels. its the simplest and easiest  
>>> solution. its the
>>>> right resolution for that cpu anyway. the glamo will still hurt you, but
>>>> not as much.
>>>    I'm sure everybody who has any professional connections with
>>> Freerunner+Glamo development already took all possible measures to
>>> solve this problem. But what concrete steps were taken to ease Glamo
>>> bottleneck? If its throughput is so narrow, can we lower amount of
>> none. it's a hardware issue. you simply cant read or write to video  
>> ram faster
>> than that. andy tried timing stuff all that happened was instability from
>> memory. glamo is most likely also the cause for the cpu runnig at 400 not
>> 500mhz. the extra load on the memory bus (because glamo is hooked there
>> externally providing another addressable chip) probably caused the  
>> instability.
>> remove it and there is a big change the cpu could run at 500mhz  
>> instead of 400.
>> it's rated to do 500. (yes power consumption would go up - but it'd  
>> only be up
>> while its on. when suspended it wont matter).
>>
>>> data flowing through it? There's one neighbor unanswered thread with a
>> render on the device - and this will then limit what you can render.  
>> evas can't
>> be fully accelerated by the glamo. it has too many opretations. a bit like
>> asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx
>> chip ever was designed to do and you will hit software fallbacks. evas has
>> multiple engnines. software (which is what is used - the 16bit renderer as
>> opposed to the full 32bit one). it has xrender - if xrender were fully
>> accelerated this should be better, but glamo cannot fully accelerate all the
>> ops evas uses, so... it will rely on software fallbacks. thus slow  
>> down. my bet
>> is you'll end up same speed as the pure software engine, or worse. aftera
>> bunch of hard work you'll have gone nowhere. evas also has a gl and gles2
>> engine - but thats no use on glamo. it's gles1.1 and very limited  
>> (from memory
>> texture size is 256x256 which is pretty useless for 2d as most data you deal
>> with breaks these bounds).
>>
>>> question on how to start the kernel with qvga resolution. Aside of
>> no need to do that - just configure x for qgva. :)
>>
>>> this, what can be reduced, for example amount of available colours
>>> (256 or even 16)? And if this [too] low throughput only of video
>>> memory channel?
>> 256 won't help. it increases complexity and really reduces display quality
>> through the floor. the best best is qvga 16bpp. its simple. it  
>> doesn't require
>> any hard work. it is actually the most common resolution for most phones and
>> devices out there so the software is more portable if you work on that (and
>> then higher). but... in the past everyone has moaned and complained  
>> and refused
>> to use it, and insisted on their vga resolution... and then complained about
>> speed.
>>
>> if people don't believe me that the gta02 is just plain a "bad bit of
>> hardware and you have few choices" here's some examples. here'es an ooold efl
>> demo app i did:
>>
>> http://www.rasterman.com/files/eem.avi
>> and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash,  
>> qvga(240x320).
>> it's from like 2001/2002 (from memory). its ancient. and watch it run evas:
>> http://www.rasterman.com/files/eem-live.avi
>>
>> here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m
>> ram, and 800x480 (higher res than gta02):
>>
>> http://www.rasterman.com/files/ello-elementary-smartq5.mp4
>>
>> everywhere i look... theres much better hardware. if you look at  
>> performance vs
>> age of hardware (when it was released) gta02 is almost at the bottom of the
>> pile. :( you simply have a bad piece of hardware if you want graphics
>> performance. as soon as you acknowledge that and either downgrade the device
>> resolution for example to bring it in line with its performance, or just use
>> different hardware, the better life will be :)
>>

I agree with you Vasco, (about switching to QVGA) for the most part, but
a long time ago when Carsten asked this question, much of the community
responded that they wanted to keep the high res screen.  Things like
viewing webpages at 640x480 instead of qvga, viewing maps, etc. were
cited as useful and important.

Anyway, I agree we should make QVGA work well, and I would use it for
most apps.  We should also keep in mind ways to allow use of the high
res screen -- maybe picking certain apps (like browsers) that could
switch to VGA automatically, and making sure the transition between
resolutions is a smooth, fast, and automatic (where desired).

I don't have a lot of free coding time at the moment, but I can at least
test (with a neo1973, not a freerunner).

Anyway, the more immediate issues: when I switch to qvga, I get the same
lighter screen with horizontal bands that Marcel described, and I'm
using a neo1973 (no glamo).  Also my xrandr only lists 480x640 as
possible resolution which is not a problem for freerunners.

The graphics artifacts in QVGA are the most immediate problem if anyone
has any ideas.

Eric

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Yogiz]

> Anyway, I agree we should make QVGA work well, and I would use it for
> most apps.  We should also keep in mind ways to allow use of the high
> res screen -- maybe picking certain apps (like browsers) that could
> switch to VGA automatically, and making sure the transition between
> resolutions is a smooth, fast, and automatic (where desired).

Here's an idea I'm not sure I've heard before and I think it should be
pointed out. When there was discussion whether to use VGA or move over
to QVGA I was for the higher resolution, because viewing maps,
terminal, pdfs and browsing at higher resolution was more important for
me then speed. If however we could have everything at QVGA by default
and change smoothly to VGA when required we could have all of the good
and none of the bad.

Sounds very good to me.

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Gennady Kupava]

Dear Carsten,

E is nice thing, but it look like highly unoptimized.

Yes, freerunner device is slow, but it is embedded device, and it's
impossible to continue kicking glamo which is already dead, as only
reason of slowness. People with GTA01 have no glamo and that? Is it
better? As far as I know - not.

> http://www.rasterman.com/files/ello-elementary-smartq5.mp4

Thank you for videos, but on high-resolution one we can see exactly same
slowness as on FreeRunner - exactly! See how top bar slides out  on
close of clock and button test - exacly as on my FreeRunner. Look how
slow scroll is, again as on FreeRunner!

That is that 7mb? Bandwidth we can use to update glamo contents? We can
count that 7mb if 10 fully updated frames for 640x480 at 16bit? This
looks much more that enough.

Also, I installed Qtv14 (thanks to Radek for that distribution), and
that I see? I is fast enought, scrolls fast, react fast, and so on. So,
E and E's programs just need optimizations. Openembedded in all sucks,
as it brings no benefit (same glibc and kernel) with bunch of drawbacks
- no easy way to compile for it, so (for me) it's uneasy to figure out
that's going on with E. No oprofile where.

I wish E to be faster!

Gennady.

В Пнд, 26/10/2009 в 22:51 +1100, Carsten Haitzler пишет:

> On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin <[hidden email]>
> said:
>
> > 2009/10/26 Carsten Haitzler <[hidden email]>:
> > > you want speed? you will need to give up something. if you still want it to
> > > look nice, then drop pixels. its the simplest and easiest solution. its the
> > > right resolution for that cpu anyway. the glamo will still hurt you, but
> > > not as much.
> >
> >    I'm sure everybody who has any professional connections with
> > Freerunner+Glamo development already took all possible measures to
> > solve this problem. But what concrete steps were taken to ease Glamo
> > bottleneck? If its throughput is so narrow, can we lower amount of
>
> none. it's a hardware issue. you simply cant read or write to video ram faster
> than that. andy tried timing stuff all that happened was instability from
> memory. glamo is most likely also the cause for the cpu runnig at 400 not
> 500mhz. the extra load on the memory bus (because glamo is hooked there
> externally providing another addressable chip) probably caused the instability.
> remove it and there is a big change the cpu could run at 500mhz instead of 400.
> it's rated to do 500. (yes power consumption would go up - but it'd only be up
> while its on. when suspended it wont matter).
>
> > data flowing through it? There's one neighbor unanswered thread with a
>
> render on the device - and this will then limit what you can render. evas can't
> be fully accelerated by the glamo. it has too many opretations. a bit like
> asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx
> chip ever was designed to do and you will hit software fallbacks. evas has
> multiple engnines. software (which is what is used - the 16bit renderer as
> opposed to the full 32bit one). it has xrender - if xrender were fully
> accelerated this should be better, but glamo cannot fully accelerate all the
> ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet
> is you'll end up same speed as the pure software engine, or worse. aftera
> bunch of hard work you'll have gone nowhere. evas also has a gl and gles2
> engine - but thats no use on glamo. it's gles1.1 and very limited (from memory
> texture size is 256x256 which is pretty useless for 2d as most data you deal
> with breaks these bounds).
>
> > question on how to start the kernel with qvga resolution. Aside of
>
> no need to do that - just configure x for qgva. :)
>
> > this, what can be reduced, for example amount of available colours
> > (256 or even 16)? And if this [too] low throughput only of video
> > memory channel?
>
> 256 won't help. it increases complexity and really reduces display quality
> through the floor. the best best is qvga 16bpp. its simple. it doesn't require
> any hard work. it is actually the most common resolution for most phones and
> devices out there so the software is more portable if you work on that (and
> then higher). but... in the past everyone has moaned and complained and refused
> to use it, and insisted on their vga resolution... and then complained about
> speed.
>
> if people don't believe me that the gta02 is just plain a "bad bit of
> hardware and you have few choices" here's some examples. here'es an ooold efl
> demo app i did:
>
> http://www.rasterman.com/files/eem.avi
> and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320).
> it's from like 2001/2002 (from memory). its ancient. and watch it run evas:
> http://www.rasterman.com/files/eem-live.avi
>
> here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m
> ram, and 800x480 (higher res than gta02):
>
> http://www.rasterman.com/files/ello-elementary-smartq5.mp4
>
> everywhere i look... theres much better hardware. if you look at performance vs
> age of hardware (when it was released) gta02 is almost at the bottom of the
> pile. :( you simply have a bad piece of hardware if you want graphics
> performance. as soon as you acknowledge that and either downgrade the device
> resolution for example to bring it in line with its performance, or just use
> different hardware, the better life will be :)
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    [hidden email]
>
>
>

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Tony McKeehan]

Would this only work with SHR/QtMoko, etc, or would this also work on
Android? I guess my question is, can this be solved from the kernel, or
is it done through the distribution itself?

-Tonym

Yogiz wrote:

>> Anyway, I agree we should make QVGA work well, and I would use it for
>> most apps.  We should also keep in mind ways to allow use of the high
>> res screen -- maybe picking certain apps (like browsers) that could
>> switch to VGA automatically, and making sure the transition between
>> resolutions is a smooth, fast, and automatic (where desired).
>>    
>
> Here's an idea I'm not sure I've heard before and I think it should be
> pointed out. When there was discussion whether to use VGA or move over
> to QVGA I was for the higher resolution, because viewing maps,
> terminal, pdfs and browsing at higher resolution was more important for
> me then speed. If however we could have everything at QVGA by default
> and change smoothly to VGA when required we could have all of the good
> and none of the bad.
>
> Sounds very good to me.
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community
>
>  

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote:
> > http://www.rasterman.com/files/ello-elementary-smartq5.mp4
>
> Thank you for videos, but on high-resolution one we can see exactly same
> slowness as on FreeRunner - exactly! See how top bar slides out  on
> close of clock and button test - exacly as on my FreeRunner. Look how
> slow scroll is, again as on FreeRunner!

I thought it was pretty snappy in comparison with my FreeRunner. But then...
I'm with 16bit software engine, a light theme... so maybe I've even a bit
less peeved at the performance than you are...

Regardless, it's a lot better than in the FreeRunner!

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Tony McKeehan]

HTC recently released the kernel source code to the Hero. Would this be
of any use to use? Would it be possible to get the HTC Sense OS on the
Freerunner? Or, worst case scenario, we could at least get some
information on how HTC modified Android to learn from.

http://developer.htc.com/

Let me know of you think of what we could do with this. I'm not advanced
enough to make the first step, sorry.

-Tonym

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Ken Young]

Gennady Kupava <[hidden email]> wrote:
[...]
> Yes, freerunner device is slow, but it is embedded device, and it's
> impossible to continue kicking glamo which is already dead, as only
> reason of slowness. People with GTA01 have no glamo and that? Is it
> better? As far as I know - not.

Actually, yes the GTA01 is very noticeably faster in graphics.
I've got both, and I've run 'em side-by-side.   The glamo actually
is a graphics DEcellerator.   That's why GTA02-core is kicking it out.

Ken Young


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Marcel-2]

Am Montag, den 26.10.2009, 20:33 +0000 schrieb Rui Miguel Silva Seabra:

> On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote:
> > > http://www.rasterman.com/files/ello-elementary-smartq5.mp4
> >
> > Thank you for videos, but on high-resolution one we can see exactly same
> > slowness as on FreeRunner - exactly! See how top bar slides out  on
> > close of clock and button test - exacly as on my FreeRunner. Look how
> > slow scroll is, again as on FreeRunner!
>
> I thought it was pretty snappy in comparison with my FreeRunner. But then...
> I'm with 16bit software engine, a light theme... so maybe I've even a bit
> less peeved at the performance than you are...
>
> Regardless, it's a lot better than in the FreeRunner!

Indeed - the top bar struggles a bit when the button demo with clouds
runs in the background which seems quite logical to me, the other times
its so smooooth.


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Mon, Oct 26, 2009 at 04:41:06PM -0400, Tony McKeehan wrote:
> HTC recently released the kernel source code to the Hero. Would this be
> of any use to use? Would it be possible to get the HTC Sense OS on the
> Freerunner? Or, worst case scenario, we could at least get some
> information on how HTC modified Android to learn from.
>
> http://developer.htc.com/
>
> Let me know of you think of what we could do with this. I'm not advanced
> enough to make the first step, sorry.

Are the drivers there, or is the "release" a sham?

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Tony McKeehan]

 From what I can tell, there are a lot of drivers in the source.

I ls'd the source and here's what I got.

$ ls kernel_hero/drivers/
accessibility connector gpu macintosh nubus rtc thermal
acpi cpufreq hid Makefile of s390 uio
amba cpuidle hwmon mca oprofile sbus usb
ata crypto i2c md parisc scsi video
atm dca ide media parport serial virtio
auxdisplay dio ieee1394 memstick pci sh w1
base dma infiniband message pcmcia sn watchdog
block edac input mfd pnp spi xen
bluetooth eisa isdn misc power ssb zorro
cdrom firewire Kconfig mmc ps3 switch
char firmware leds mtd rapidio tc
clocksource gpio lguest net regulator telephony

This what you're talking about?

-Tonym

Rui Miguel Silva Seabra wrote:

> On Mon, Oct 26, 2009 at 04:41:06PM -0400, Tony McKeehan wrote:
>  
>> HTC recently released the kernel source code to the Hero. Would this be
>> of any use to use? Would it be possible to get the HTC Sense OS on the
>> Freerunner? Or, worst case scenario, we could at least get some
>> information on how HTC modified Android to learn from.
>>
>> http://developer.htc.com/
>>
>> Let me know of you think of what we could do with this. I'm not advanced
>> enough to make the first step, sorry.
>>    
>
> Are the drivers there, or is the "release" a sham?
>
> Rui
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community
>
>  

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

No... the drivers necessary to run the devices on the HTC Hero...

On Mon, Oct 26, 2009 at 05:03:58PM -0400, Tony McKeehan wrote:

>  From what I can tell, there are a lot of drivers in the source.
>
> I ls'd the source and here's what I got.
>
> $ ls kernel_hero/drivers/
> accessibility connector gpu macintosh nubus rtc thermal
> acpi cpufreq hid Makefile of s390 uio
> amba cpuidle hwmon mca oprofile sbus usb
> ata crypto i2c md parisc scsi video
> atm dca ide media parport serial virtio
> auxdisplay dio ieee1394 memstick pci sh w1
> base dma infiniband message pcmcia sn watchdog
> block edac input mfd pnp spi xen
> bluetooth eisa isdn misc power ssb zorro
> cdrom firewire Kconfig mmc ps3 switch
> char firmware leds mtd rapidio tc
> clocksource gpio lguest net regulator telephony
>
> This what you're talking about?
>
> -Tonym
>
> Rui Miguel Silva Seabra wrote:
> > On Mon, Oct 26, 2009 at 04:41:06PM -0400, Tony McKeehan wrote:
> >  
> >> HTC recently released the kernel source code to the Hero. Would this be
> >> of any use to use? Would it be possible to get the HTC Sense OS on the
> >> Freerunner? Or, worst case scenario, we could at least get some
> >> information on how HTC modified Android to learn from.
> >>
> >> http://developer.htc.com/
> >>
> >> Let me know of you think of what we could do with this. I'm not advanced
> >> enough to make the first step, sorry.
> >>    
> >
> > Are the drivers there, or is the "release" a sham?
> >
> > Rui
> >
> > _______________________________________________
> > Openmoko community mailing list
> > [hidden email]
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> >  
>
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community

--

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community