Openmoko Bug #1974: Enlightenment is slow to start / restart / update

[Openmoko Public Trac]

#1974: Enlightenment is slow to start / restart / update
---------------------------+------------------------------------------------
    Reporter:  Treviño     |        Owner:  raster  
        Type:  defect      |       Status:  closed  
    Priority:  normal      |    Milestone:          
   Component:  E - Illume  |      Version:  Om2008.8
    Severity:  normal      |   Resolution:  fixed   
    Keywords:              |    Blockedby:          
Reproducible:  always      |     Blocking:          
---------------------------+------------------------------------------------
Changes (by raster):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 1)
 a. keyboards are pluggable (if it's 3rd party keyboard apps that you mean)
 and illume has a gui config to select what one to run (or use illume's
 built-in). just need "Keyboard" in the Categories list for the .desktop
 for the kbd to run.
 b. if you mean personal .kbd layout files - yes. put your personal
 Default.kbd, Numbers.kbd ... or anything else in ~/.e/e/keyboards/ and it
 will take preference over the system package installed one :) same for
 ~/.e/e/dicts/ :)

 2)
 scrolling is done the exact same way in both situations - objects are
 moved around and thus the areas that change are redrawn (as things are
 moving over a static background with alpha a redraw is required). the
 difference is that the icons are well just more complex to draw, more
 things to draw. more work - thus slower to update. a combination of memory
 bandwidth and cpu in general as wel as the glamo has made this way of
 doing things really not work as well as it does on many other embedded
 platforms (the n800 does this much more smoothly - even at 300mhz for
 example). even my ancient zaurus sl-c860 (i bought  (400mhz xscale with an
 ati imageon @ 640x480) does better (visibly...) and that came out about 4
 years ago. in general the FR is particularly poor with being able to do
 redraws where every "embedded system" i have used and coded for and
 ported/run evas stuff on (zaurus sl5500/sl-c860, ipaq 3660, nokia n800,
 and other prototype hardware not released) has coped amazingly well.
 generally the "redraw it all using the cpu" works almost as well as
 accelerated blitting - if the platform has it, or well. enough, but the
 bonuses of having alpha blending, layers etc. are worth the swap. :) on
 the FR this equation has not come to be true. the fact is that trying to
 use hardware blit will be tricky as it totally bypasses the rendering
 pipeline and will limit you to a ui style that in all other places is
 possible and easy to do, so making the FR an exception to the rule.

 so as such. nothing to be done. well not without impacting development for
 many other devices. if it were me i'd not have scrolling. i'd paginate the
 display and you flip pages, not scroll. iphone-style still scrolls as
 such, but i don't intend to really address this stuff - i'm currently
 quite busy :(

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/1974#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac