Why qtopia uses framebuffer and ASU can't?
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Mon Sep 8 10:06:45 CEST 2008
On Mon, 8 Sep 2008 06:49:39 +0000 prishelec at gmail.com babbled:
> Raster, thank you for explanation!
> If I get it right there is no difference in speed between qtopia and
> other distros related to graphics.
> And just for education - what 'misnoma' means?
as such they go through the same hardware - x is just a way to get to the
hardware. often x apps/toolkits are very bad at using it. the x11 port of
qtopia isnt great - its really raw and performance is poor. this is a qt
problem, not x11 problem. x11 gets blames so often for problems nothing to do
with x11 but entirely to do with the bad programming done using it and lack of
knowledge of x11 its internals or graphics hardware or routines. i am standing
up for x because it is blamed for stuff that have nothing to do with it.
oops. i mean misnomer. :) i am using misnomer for the fact that everyone runs
around going "running in the framebuffer is so much faster" taking fb drawing
as obviously faster and something desirable you must do for speed. so as such i
used it correctly - just misspelt.
> On 9/8/08, The Rasterman Carsten Haitzler <raster at rasterman.com> wrote:
> > On Sun, 7 Sep 2008 20:45:45 -0400 Yaroslav Halchenko
> > <site-openmoko.org at onerussian.com> babbled:
> >> > for example. lets say i spend 1 second to write data to video ram - that
> >> > is
> >> > 1 second i CANNOT spend on anything else. the glamo limits write rates
> >> > to
> >> > about
> >> so why then during boot of X in ASU (2008.8) those precious cycles are
> >> spent on a 'box animation'? uff
> > because 1. users need to know the device is alive at all and not just hung -
> > so
> > something needs to change on the screen. otherwise for a long time the
> > screen
> > is "hung". and 2. that is just following in design from the existing design
> > for
> > the booting screen. as e has no idea how far along it is in init until it is
> > told "i'm done" - it can just display some form of status. a bouncing box
> > follows an existing notion of "that means its busy but doesnt know how long
> > to
> > go" from the windows boot as well as splash from psplash/ubuntu, and gtk and
> > other widget sets uses this as an indicator of just that.
> > you are free to modify the theme though. i personally would have gone for
> > something different - but that's a question of taste and preferences. it
> > also
> > wont help the boot THAT much. you want to find the BIG gains - not the small
> > ones. it consumes maybe about 20-25% (combine enlightenment_init and xglamo)
> > for the animation. so yes - u'd speed it up by a bit - but not immensely
> > (not
> > double or triple which is what u really want).
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler) raster at rasterman.com
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> Openmoko community mailing list
> community at lists.openmoko.org
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community