Re: Why qtopia uses framebuffer and ASU can't?
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? On 9/8/08, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sun, 7 Sep 2008 20:45:45 -0400 Yaroslav Halchenko [EMAIL PROTECTED] 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)[EMAIL PROTECTED] ___ 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: Why qtopia uses framebuffer and ASU can't?
On Mon, 8 Sep 2008 06:49:39 + [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Sun, 7 Sep 2008 20:45:45 -0400 Yaroslav Halchenko [EMAIL PROTECTED] 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)[EMAIL PROTECTED] ___ 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why qtopia uses framebuffer and ASU can't?
On Sun, 7 Sep 2008 21:34:52 + Leonti Bielski [EMAIL PROTECTED] babbled: Hello! Somewhere I read that Qtopia is much faster than other distros because it uses framebuffer. So I have some questions: misnoma. wrong. 1. How is it possible for qtopia to bypass glamo chip and write directly to the framebuffer? fb is available - but you will be competing with x for the fb and so you can choose - either qtopia and all - or x. not both. you can use x to write to the fb - it is simply an organised way of doing so. (ie you write to an shm buffer then xshmputimage the regions u want). 2. Is it possible to do the same with x11 server? 3. Is there other explanation(except for glamo) why apps are slow to respond on 400mhz proc? bandwidth to glamo - it holds the cpu in waitstates while writing to video ram (the framebuffer) so all time spent writing is lost as cycles to do anything else. and it's pretty slow (7mb/sec). 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 7mb/sec (so the memcpy() to video ram is artificially slowed down compared to what it would be mem - mem which would be about 50mb/sec so you lose about 85% of your cpu cycles entirely while writing to video ram). the glamo has acceleration - not everything, but a reasonable set (not really any less than most desktop x drivers when it comes to 2d). Thank you! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why qtopia uses framebuffer and ASU can't?
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 -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why qtopia uses framebuffer and ASU can't?
On Sun, 7 Sep 2008 20:45:45 -0400 Yaroslav Halchenko [EMAIL PROTECTED] 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)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
