Fw: UI ideas/questions or can we animate things as smooth as iPhone?

[Silva, Daniel]

OK resending this since i accidentally sent it directly to Mr John Seghers

Regards,
Daniel
----- Original Message -----
From: "Silva, Daniel" <danielsilva at danielsilva.net>
To: "John Seghers" <jseghers at cequint.com>
Sent: Thursday, June 07, 2007 6:40 PM
Subject: Re: UI ideas/questions or can we animate things as smooth as 
iPhone?

> ----- Original Message -----
> From: "John Seghers" <jseghers at cequint.com>
> To: "'OpenMoko'" <community at lists.openmoko.org>
> Sent: Thursday, June 07, 2007 5:05 PM
> Subject: RE: UI ideas/questions or can we animate things as smooth as 
> iPhone?
>
>> I've been lurking, but this is something that I do have a bit of 
>> experience
>> with--and definitely some opinions.
>>
>> Michael 'Mickey' Lauer wrote
>>> Tomasz Zielinski wrote:
>>> > framework, designed for mobile devices and running quick
>>> > framebuffer operations? GameBoy provided nice full-screen animations
>>> > in 1989, eighteen years ago.
>>>
>>> I feel your pain. Trust me, it hurts me as well...
>>
>> The GameBoy Advance is an ARM7TDMI running at 32MHz.  However, its screen
>> size was only 240 x 160 (1/8 VGA) and it had a hardware-based sprite 
>> system
>> as well as both bitmapped and character mapped graphics capabilities with
>> hardware fine scrolling and multiple planes.
>>
>> IIRC, the GTA01 has a 266MHz processor--only a little more than 8x the
>> GBA--and fully 8x the screen area with 16x the memory required for a 
>> bitmap.
>>
>>>
>>> > I'm 100% sure nobody will cry after pure-X11 applications we loose
>>> > this way. Almost every GTK application would require rewriting/porting
>>> > to fit OpenMoko capabilities, so it's not great loss too. Not to
>>> > mention font and other DPI-aware issues.
>>>
>>> Interesting. Can I hear more supportive or counter arguments?
>>> What do the others think?
>>
>> I've been writing games since 1981, on Atari 5200, 8-bit NES, SFX, 
>> Genesis,
>> Windows, and too many cell phones to keep track of. Please, please, 
>> please
>> give us direct access to the frame buffer and a low level API to the 
>> Blitter
>> in the GTA02.
>>
>> I don't know if you have to throw away X11 support to do so, but I do 
>> agree
>> that you won't lose much if you do so.
>
> No you don't have to sack X11 to have access to the underlying hardware, 
> you can
> interface with it through DRI ( Direct Rendering Infrastructure ), but 
> that would
> kill the point of having X11, why having X11 if you access the hardware 
> directly?
> And besides you would have to write a DRI driver to interface with 
> OpenMoko hardware,
> since there's only a handfull of drivers available.
>
> I agree that loosing X11 per se wouldn't do much harm, but going the 
> vanilla framebuffer
> way we would be loosing a lot. It would require ALOT of work to rebuild 
> what has been done
> until now ( if they're really using X11+GTK ) just to go in that 
> direction, when i believe
> the problem is not there.
> I believe people are missing few things, although i really didn't checked 
> the code yet,
> i bet the code is still very umpolished and could and will be optimized. 
> From what i've seen
> in the wiki, OpenMoko is still using KDrive ( trimmed down XServe 
> implementation ) and a full
> glibc.
> Change that for something like DirectFB and uClib ( or diet libc ) and you 
> already would
> start to see things shape up.
> Then there's loading times, for a solution like OpenMoko i wouldn't rely 
> on dynamic linking
> and would go for static linking, remeber this is not a desktop system.
> http://www.directfb.org/docs/GTK_Embedded/summary.html
> If you/they must use dynamic linking i would recomment using something 
> along the lines
> of prelink.
>
>> A lot of statements have been made here about people flocking to the Neo
>> *because* they can modify it. But remember that the geeks who will buy it
>> because they can run their favorite X application, or bring up a Linux 
>> shell
>> are the vast minority if you're looking at hundreds of thousands or 
>> millions
>> of devices being sold.
>>
>> The vast majority of the purchasers are going to be people who buy it
>> because it functions smoothly, makes great calls, and has lots of nifty 
>> eye
>> candy. And, oh by the way, the can customize it to their heart's desire. 
>> But
>> those customizations aren't going to be done at the Linux developer 
>> level.
>> Those are going to be seamless plug-ins or self-installing apps that give
>> them something they want on the phone. This also points to the need for a
>> slick graphical app catalog/installer.  Synaptic, apt-get, rpm...not 
>> going
>> to cut it for the normal end user.
>
> There are loads and loads of cheap and really great functioning cell 
> phones, OpenMoko/neo1973
> could be the greatest phone in the world and still noe even make a small 
> dent on
> the market.
> Sure there are people who will look for the best bang for the buck, but 
> mus of them
> will just buy what's more trendy and/or has the most 'cool' factor.
> Just look the iPod and the more recent iPhone fenomena, neither one are 
> the best on the
> class, but they have hype.
>
> neo1973/OpenMoko needs to have something that sets it apart, an for now, 
> more than the hardware
> its OpenMoko and its 'promise' to be a great platform to develop to.
> More developers = more applications = more users wanting to buy one. There 
> are many many linux
> ( and even windows developers, hey im one ) wanting to develop for it, and 
> it will gather much
> more attention if we already have known tools to our disposal like X11 and 
> GTK, throw a simple
> but powerfull language to it, and even non developers will buy one just to 
> tinkle with it.
>
>> This is a resource-constrained device compared to the computers we have 
>> on
>> our desks. Yet, people will expect that such a device will have fluid eye
>> candy, will be very responsive, and if it doesn't, it won't matter to 
>> them
>> that it was built with Desktop technology.
>>
>> The basic apps that run the phone need to have performance, fit, and 
>> finish
>> as their top priorities. And for that you can't have a ton of 
>> abstractions
>> between the apps and the hardware.
>>
>> - John
>
> I completly agree with this, but you don't have to throw away 
> X11/GTK/somethingelse out of the picture and
> loose a common ground to many developers to achive that.
>
> Regards,
> Daniel