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

[John Seghers]

Daniel sent his response directly instead of to the list by accident. I
confirmed that with him so I'm leaving his entire reply and adding my points
at the end...

> -----Original Message-----
> From: Silva, Daniel [mailto:danielsilva at danielsilva.net]
> Sent: Thursday, June 07, 2007 10:40 AM
> To: John Seghers
> 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

What I see is a situation very similar to the WinG (Windows Game) libraries
in the Windows 95 timeframe.  These allowed a Windows app to take over the
entire screen and bypass GDI--even to the point of changing screen res and
refresh rates.  Then, when you Alt-Tab'd away, or some other reason required
you to go back to other windows, you'd revert back to the normal modes.

If we can have a method by which an app can take over the screen from X, and
then give it back (or have it taken back if necessary) then the apps (e.g.
games) that need bare-metal access can do it, and those that can perform
fine within X can do that.

I'm certainly not trying to say that all apps need bare-metal access, or
that frameworks are a bad thing.  But they become bad if they prevent you
from bypassing them at need.

I'm not an X expert--I've dealt with Linux as little as possible in my
career--so I don't have ready access to the knowledge about what is
possible, what is easy, and what just plain won't work with these systems.
If we can keep X and GTK and provide a way to get maximum performance for
those apps that need it...great!

- John