Re: How "snappy" can the Openmoko GUI get using GTK?
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?
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?
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
Re: How "snappy" can the Openmoko GUI get using GTK?
Guys, currently we are still extraordinarily busy with providing the core functionality. 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. On a more general note, optimization as much as polishing is something that is usually done very late in the process, so bear with us for a while. -- - Michael Lauer <[EMAIL PROTECTED]> http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ 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?
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?
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?
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?
On 9/2/07, Myk Melez <[EMAIL PROTECTED]> wrote: > denis wrote: > > 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 not sure that's accurate. The developers may well have prioritized > snappiness but just not achieved it yet. > > In any case, from my perspective as a user of phones, snappiness is > really important. I would trade most of the features of my current > phone (a Motorola Razr) for it to respond instantly when I press a > button, at least for common operations, instead of just almost > instantly, which drives me nuts. I'll second that. All of the phones I've used in the last half decade have had almost-instantaneous response, and that 0.5 second that it takes it to respond is very very annoying. I think it would be a great advantage for OpenMoko-based phones if the basic UI can be optimized enough to be better than the average phone out there. Igor ___ 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?
denis wrote: 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 not sure that's accurate. The developers may well have prioritized snappiness but just not achieved it yet. In any case, from my perspective as a user of phones, snappiness is really important. I would trade most of the features of my current phone (a Motorola Razr) for it to respond instantly when I press a button, at least for common operations, instead of just almost instantly, which drives me nuts. -myk ___ 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?
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
Re: How "snappy" can the Openmoko GUI get using GTK?
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?
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?
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?
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
