Qtopia coming for Neo1973

[Dani Anon]

> I think you are misrepresenting the difference. I would write that as:
>
> 1. Application asks X to draw a line, then gets on with other stuff, or
> makes other calls while it waits. X calls the device driver which talks
> to the hardware GPU (using around 20 bytes of API call) which uses
> accelerated hardware to draw the line in the screen buffer. A few
> microseconds later X informs the application that the line has been
> drawn.
>
> 2. Application (via compiled in or dynamically linked libraries) talks
> directly to the memory mapped frame buffer. It does it's own geometry,
> area fill and transparency calculations, (wasting the perfectly good
> GPU that the hardware has) then directly updates several thousand
> memory locations to make the line appear on the screen. (flushing the
> CPU's cache in the process) While it is doing that it cannot do any
> other useful work.

Wow, do you actually think you can write that and stand uncorrected?

Why in your version of the second scenario there is no low level
graphic support and in the first scenario there is? Why in the second
scenario is there no hardware acceleration and in the first scenario
there is? Why on the second scenario you assume the application has to
do all the geometry instead of the operative system? I guess
handicapping the second hypothetical studio subject must be the only
way you can show the first scenario is less overhead but wow, I really
didn't expect that level of blatant manipulation in this list. The
second implementation can perfectly have gpu support, graphic
acceleration and OS assisted geometry and all the stuff you wrote
simply wouldn't happen; there's a pretty well known example of this,
how was it called? Oh yes, *Microsoft Windows*. In fact, there's
better support for everything you wrote on Windows than in Linux.
Also, do you really think that's an accurate representation of what's
happening in Openmoko vs any QTopia device for example?

Applications make other calls while they wait? Yeah, sure... if they
are not input dependant! In the time that stuff is drawn the component
may have been closed by the user (just to provide an example) so are
you sure you can get away with saying "Oh its OK, that stuff is
queued"? In the second scenario you only have to wait for the GPU, in
the first scenario you have to wait for the GPU and X. For a example
of an operation is only logical that we make it blocking but of course
it's more convenient for you that we make it non-blocking.

But hey I like how you conveniently left unanswered my comment about
how the FBUI and DirectFB projects exist solely to remove the X server
overhead. Can you explain to me and them why they are wrong and how
they have wasted all those months of development to solve a problem
that just doesn't exist?

>
> > Which one would you choose for performance? Apparently most of the
> > phones are using the second. The mind boggles...
>
> Interesting point. The advantage of the first (via X) is that it uses a
> standard API, and if the GPU device drivers are well written then most
> of the hard work can be offloaded, making screen updates very fast,
> even if the screen is very big (=lots of memory buffer to move around).
>
> The advantage of the second (direct frame buffer) is that it is much
> quicker to implement on new hardware, and uses slightly less memory.
>
> The way I see it, using a direct frame buffer system such as Qtopia is
> sensible in an early version before the GPU device drivers are working,
> but after that there is little benefit.
>
> --
> David Pottage
>
> Error compiling committee.c To many arguments to function.
>
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>