Re: How snappy can the Openmoko GUI get using GTK?

2007-09-04 Thread polz
On Monday 03 September 2007 20:24:38 Michael 'Mickey' Lauer wrote:
 Guys,

 I wish to have time doing some benchmarks of e.g. GtkFB vs.
 GtkDirectFB vs. Gtk/X11 -- likewise EFL/X11 vs. EFL/Fb. Delivering
 factual numbers for things like that would be very interesting for us.
While this might not be a benchmark, I've noticed that mplayer works better 
with -vo dbdev than with -vo x11.

noslices=true also improves performance.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-04 Thread Nils Faerber
polz schrieb:
 On Monday 03 September 2007 20:24:38 Michael 'Mickey' Lauer wrote:
 Guys,
 
 I wish to have time doing some benchmarks of e.g. GtkFB vs.
 GtkDirectFB vs. Gtk/X11 -- likewise EFL/X11 vs. EFL/Fb. Delivering
 factual numbers for things like that would be very interesting for us.
 While this might not be a benchmark, I've noticed that mplayer works better 
 with -vo dbdev than with -vo x11.

You mean -fbdev ?

That would be quite natural since then you directly write to the
framebuffer instead of going through X11. But you will get troubles when
playing in a window but not fullscreen.

 noslices=true also improves performance.

That's a good hint.

Cheers
  nils faerber

-- 
kernel concepts GbRTel: +49-271-771091-12
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen Mob: +49-176-21024535
--

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-03 Thread Tilman Baumann

denis wrote:

Watching a lot of videos about Openmoko and the GUI I saw that it is
very slow and yards away from being snappy. (regarding the application
startup and the acting inside an application) I know that speed is not
the priority thing in developement  at the moment but how fast and
snappy can the Openmoko GUI using GTK get?


I think this will improve with the new faster CPU.

Seeing the difference between the Nokia 770 and the Nokia 800 (faster 
CPU), this will make a great difference. Especially considerung that 
OpenMoKo and Maemo use very much the same technology.


But you are right at some point.
Having a true multitasking os with memory management and the like and a 
display abstraction layer like X servers is completely different from 
dump devices like (old) palm with neither of them. *g*


And as you said. The sofware is not optimised yet.
I would say the device has enough horse power and most important enough 
RAM to run smoothly eventually.


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-03 Thread Andy Poling

On 2 Sep 2007, at 14:57, denis wrote:

Watching a lot of videos about Openmoko and the GUI I saw that it is
very slow and yards away from being snappy. (regarding the application
startup and the acting inside an application) I know that speed is not
the priority thing in developement  at the moment but how fast and
snappy can the Openmoko GUI using GTK get? I'm looking at this from
the user point of view, I'm not a developer so it would be very
interesting to me what can be expected in the future. What are you're
expectations? Will it get as snappy as the old PALM Pdas had been?


I haven't seen anyone else mention the obvious: some of the device drivers and
alot of the code have debugging output enabled.  Start the X server manually,
and watch the debugging info spew forth, and you'll get an idea where a bunch
of CPU cycles are going.  As an example, every stylus press results in at
least 4 debugging msgs printed, something happening in a place I would
consider latency-sensitive.  In addition various things complain constantly of
missing icon image files, etc... things that would surely be cached if they
were present, and those complaints take cycles.

It's all appropriate in a development environment - we just have to factor
that in when considering the responsiveness of the device.  IMO it's
appropriate for the primary focus to be functionality and the secondary focus
to be user interaction effectiveness at this point.

-Andy

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-03 Thread Giles Jones


On 3 Sep 2007, at 18:32, Andy Poling wrote:



I haven't seen anyone else mention the obvious: some of the device  
drivers and
alot of the code have debugging output enabled.  Start the X server  
manually,
and watch the debugging info spew forth, and you'll get an idea  
where a bunch
of CPU cycles are going.  As an example, every stylus press results  
in at

least 4 debugging msgs printed, something happening in a place I would
consider latency-sensitive.  In addition various things complain  
constantly of
missing icon image files, etc... things that would surely be cached  
if they

were present, and those complaints take cycles.

It's all appropriate in a development environment - we just have to  
factor

that in when considering the responsiveness of the device.  IMO it's
appropriate for the primary focus to be functionality and the  
secondary focus

to be user interaction effectiveness at this point.


I've found that using a stylus seems to help it recognise touches,  
maybe someone has tweaked something so finger presses don't register  
as easily?



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-03 Thread Andy Poling

On Mon, 3 Sep 2007, I wrote:

It's all appropriate in a development environment - we just have to factor
that in when considering the responsiveness of the device.  IMO it's
appropriate for the primary focus to be functionality and the secondary focus
to be user interaction effectiveness at this point.


Just to be clear, by user interaction effectiveness I meant the interaction
paradigms used and the use case solutions.  Not response time...

-Andy

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


How snappy can the Openmoko GUI get using GTK?

2007-09-02 Thread denis
Watching a lot of videos about Openmoko and the GUI I saw that it is
very slow and yards away from being snappy. (regarding the application
startup and the acting inside an application) I know that speed is not
the priority thing in developement  at the moment but how fast and
snappy can the Openmoko GUI using GTK get? I'm looking at this from
the user point of view, I'm not a developer so it would be very
interesting to me what can be expected in the future. What are you're
expectations? Will it get as snappy as the old PALM Pdas had been?

I'm really looking forward for your answers.

Regards, Denis.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-02 Thread Giles Jones


On 2 Sep 2007, at 14:57, denis wrote:


Watching a lot of videos about Openmoko and the GUI I saw that it is
very slow and yards away from being snappy. (regarding the  
application

startup and the acting inside an application) I know that speed is not
the priority thing in developement  at the moment but how fast and
snappy can the Openmoko GUI using GTK get? I'm looking at this from
the user point of view, I'm not a developer so it would be very
interesting to me what can be expected in the future. What are you're
expectations? Will it get as snappy as the old PALM Pdas had been?

I'm really looking forward for your answers.

Regards, Denis.



Launch speed is something that can be fixed, I'm not sure if the  
build system is using pre-linking? if not it will be something to use  
as this is the cure to application launch speed delays on Unix like  
systems.


The interface is VGA and so there's a lot more to draw and this makes  
the GUI less responsive than QVGA. The acceleration in the next gen  
hardware will solve this.


The Palm PDAs were using task switching, it wasn't a full  
multitasking OS, so you have to realise that a Linux based PDA will  
always lag behind a very simple OS.





___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-02 Thread wim delvaux
On Sunday 02 September 2007 16:17:25 Giles Jones wrote:
 On 2 Sep 2007, at 14:57, denis wrote:
  Watching a lot of videos about Openmoko and the GUI I saw that it is
  very slow and yards away from being snappy. (regarding the
  application
  startup and the acting inside an application) I know that speed is not
  the priority thing in developement  at the moment but how fast and
  snappy can the Openmoko GUI using GTK get? I'm looking at this from
  the user point of view, I'm not a developer so it would be very
  interesting to me what can be expected in the future. What are you're
  expectations? Will it get as snappy as the old PALM Pdas had been?
 
  I'm really looking forward for your answers.
 
  Regards, Denis.

 Launch speed is something that can be fixed, I'm not sure if the
 build system is using pre-linking? if not it will be something to use
 as this is the cure to application launch speed delays on Unix like
 systems.

Lazy loading is too ... (the problem with delay is that ALL symbols need 
linkage also those not needed by the current user needs)


 The interface is VGA and so there's a lot more to draw and this makes
 the GUI less responsive than QVGA. The acceleration in the next gen
 hardware will solve this.

 The Palm PDAs were using task switching, it wasn't a full
 multitasking OS, so you have to realise that a Linux based PDA will
 always lag behind a very simple OS.




 ___
 OpenMoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-02 Thread Ted Lemon

On Sep 2, 2007, at 7:17 AM, Giles Jones wrote:
Launch speed is something that can be fixed, I'm not sure if the  
build system is using pre-linking? if not it will be something to  
use as this is the cure to application launch speed delays on Unix  
like systems.


This is probably true.

The interface is VGA and so there's a lot more to draw and this  
makes the GUI less responsive than QVGA. The acceleration in the  
next gen hardware will solve this.


This is definitely not true.   I mean, it's true that the QVGA is  
going to take less time to paint, but paint times aren't the problem  
- if they were, kinetic scrolling wouldn't look so nice.   No,  
there's something else going on that's making the UI so  
unresponsive.   Possibly something is timing out, or something's  
running in lock-step that should be asynchronous.


The Palm PDAs were using task switching, it wasn't a full  
multitasking OS, so you have to realise that a Linux based PDA will  
always lag behind a very simple OS.


Again, true, but not likely to produce the results we're seeing.
E.g., when an app is running, and a tap on the UI takes seconds to  
produce a response, this is not something you can attribute to the  
fact that Linux is a protected-mode multitasking kernel.



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-02 Thread Giles Jones


On 2 Sep 2007, at 15:58, Ted Lemon wrote:




This is definitely not true.   I mean, it's true that the QVGA is  
going to take less time to paint, but paint times aren't the  
problem - if they were, kinetic scrolling wouldn't look so nice.
No, there's something else going on that's making the UI so  
unresponsive.   Possibly something is timing out, or something's  
running in lock-step that should be asynchronous.


VGA is 4x times the data, not two times. That will have a noticable  
effect. The only VGA device I have owned was a Toshiba E800 PDA, this  
had an ATI chip and it was still a little sluggish.



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How snappy can the Openmoko GUI get using GTK?

2007-09-02 Thread Ted Lemon

On Sep 2, 2007, at 8:24 AM, Giles Jones wrote:
VGA is 4x times the data, not two times. That will have a noticable  
effect. The only VGA device I have owned was a Toshiba E800 PDA,  
this had an ATI chip and it was still a little sluggish.


Hm.   The best example of slow draw times that I can find in the Moko  
UI is the terminal keyboard.   The reason this draws slowly is  
because it's being drawn line by line.   If it were just blitted in,  
it would be quite a bit faster.   It's certainly true that you will  
see slowness as a consequence both of the slow CPU and the lack of a  
GPU, I would guess particularly when surfing the web.   However, this  
is not why the UI feels slow right now.


The UI feels slow right now because when you click on a control,  
sometimes you get no response at all.   Right now, the UI is mainly  
operating in the realm of you click on something, I do something.
This works well when the something happens quickly, but when it  
doesn't, you want you click on something, I do something to show  
that your click registered, I do something.   The elapsed time will  
be slightly longer in the second case, but the perceived UI lag will  
be less because you aren't wondering whether or not your tap registered.



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community