Joel Newkirk wrote: > On Wed, 25 Feb 2009 12:43:59 +0100 > Helge Hafting <[email protected]> wrote: > >> Joel Newkirk wrote: > [...] > As I said, I'm guessing, but when I removed the extra PNG images and > leav just one, enlightenment average CPU drops and the display is more > responsive. The glass button effect /is/ applied to every icon, > it's just that the parts ('parts' in edc syntax) relevant to the effect > are flagged as non-visible by default. I'm assuming that even when a
Urrgh - such inefficient coding. Making a 'movie' per icon - every time - and just not showing it for most of them. :-( The sane way is to only do the _needed_ calculations. Either animate a single icon when the effect is actually used, or generate all the frames once and just store them till needed. I wonder how they come up with such stuff. This is not only a problem on weak processors - it wastes energy on the good ones as well. :-( Maybe we ought to use a modified duke nukem as an app launcher interface instead of enlightenment. Duke has a _better_ framerate for scrolling and zooming - in 3D! Shoot at icons to start apps. Fire at the process list to kill. kill -9 using a bigger gun. ;-) [...] > Wonderful feature > to have, but I suspect that the calculations involved in this scaling > and other nice effects E offers are at least a slight detriment to the > (integer) FR user experience... > I wish people though more about efficiency. One can have all sorts of wonderful effects by precomouting some stuff _once_, and then use plain bit block transfers. 1990 game machines was weaker than the FR, but that did not seem to be a problem then. [...] > If you watch an icon closely when you press your stylus against it, you > can usually perceive the fade-in taking place, particularly if your FR > is straining, in which case you can sometimes see a few distinct delayed > steps. The linear transition is set to occur in 0.2 seconds fading in, > and 0.1 seconds fading out - so it is quite brief. I believe it > abides by the "Framerate" setting in Illume config (the spanner), such > that a 30fps setting and a 0.2 second fade equal a 6-frame animation. I have now set the framerate to its minimum of 5, and turned off animations where I could. At least the keyboard appears more quickly now. Icon animation and only two icons - selected and unselected. > Thanks for the encouragement. :) It's already improved my user > experience, but in my poking about I've broken things as well, which is > why I'm not offering the .edj to anyone yet. I plan to start from a > clean extraction from illume.edj and default.edj once more, applying > only the changes confirmed to be beneficial and not cause E to segfault. Great! I hope this will go into the distributions, at least as a selectable alternative. Eye candy is nice - but only as long as it doesn't create performance problems. Scrolling is slow enough even if I grab the iconless corner - so that no icon actually change state. (None was selected, none became selected) But of course it is still slow if all those icons have to be scaled 9 times or so before drawing the screen. > But at the pace I'm going that'll be a couple weeks still. Hopefully > at that point I'll be able to offer tarball and ipk versions of the > theme for both enlightenment in general and for elementary (shr-dialer > and kin, paroli, Raster's alarm, shr-config, etc all use elementary) as Take your time. Ideally, a beta release whenever one more performance killer is chopped off. If it isn't too much extra work. [...] > /* > below are lines 14053 through 14438 of 'default.edc', inside > 'default.edj', this copy extracted from FSO M5 IIRC but I believe the > same utilized in SHR. At the top it specifies what images are required > for this 'group', which defines a single icon on the desktop. (Illume in > our case) It also uses 'pager_base2.png' which is defined in a global > images stanza. > */ Scary stuff. An interpreted language just for the icon set. When I try to impress people with the FR, I show them cool apps like linball. Not the icon interface. It is not that hot anyway - and slowness is simply bad. Helge Hafting _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
