Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
>> >> Raster, what devices are those? Do they feature a gsm device too? > >maybe. maybe not. this is the point where you will just be guessing. :) :) OK, i understand. cheers ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Mon, 2 Mar 2009 20:01:51 +0100 Petr Vanek said: > On Tue, 3 Mar 2009 00:44:01 +1100 > Carsten Haitzler (The Rasterman) (CH(R) wrote: > > >remember you are just getting e's default upstream theme - it actually > >works just fine on the more modern devices i have (omap3, 6410 etc.) > > Raster, what devices are those? Do they feature a gsm device too? maybe. maybe not. this is the point where you will just be guessing. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Tue, 3 Mar 2009 00:44:01 +1100 Carsten Haitzler (The Rasterman) (CH(R) wrote: >remember you are just getting e's default upstream theme - it actually >works just fine on the more modern devices i have (omap3, 6410 etc.) Raster, what devices are those? Do they feature a gsm device too? thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Mon, 02 Mar 2009 11:44:12 +0100 Helge Hafting said: > Carsten Haitzler (The Rasterman) wrote: > > > i really suggest you have a better look at the code. it uses timepoints. > > Good advice. Critic based on assumptions isn't good enough. > Still, the problem remain. The user interface is a bit on the slow side. > And it doesn't have to - simplified themes are faster. remember you are just getting e's default upstream theme - it actually works just fine on the more modern devices i have (omap3, 6410 etc.) and looks nice to boot. i am not going to go to a lot of extra work by doing a specially trimmed down theme for the gta02 when i also have other more modern platforms to support across many devices and i want to keep my work down. as the default works - i'm leaving it tat that :) > Eye candy is nice - but not when it cause performance problems. eye > candy is also nice for showing off a great product - but this backfires > when it demonstrates slowness. reality is reality here. it is a slow device. it is open though. but it's slow. i'm not OM's marketing department. :) i'm not here to try make the freerunner look better than it is - i have a level playing field for everything targetted - they all get the same. :) > [enlightenment graphichs explanation deleted] > > >> 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! > > > > and runs in 8bpp and doesnt alpha blend, doesnt do interpolated scaling. > > doesnt do a tonne of things. > > Well, it was a joke. Duke gets much speed from low resolution. > Still - it raises questions. Do we want the resolution, 16bpp, alpha > blend and so on? it looks good in screenshots. you have a 16bpp screen like it or not anyway. duke render in 8bpp then expands to 16bpp - evas actualyl does the harder. renders in 32bpp and goes down to 16. you can get speed by building without dithering on - or use line dithering that is as fast as none, but offer some level of dither. not good for artificial images, but ok for photos. better than no dither. > I happen to like the high resolution and color depth. So perhaps > scrolling cannot go really fast in my case, and instead must to big > jumps to keep up with finger speed. It'd still be nice if it was more > responsive - scrolling start noticeably later than the dragging. there is always a lag - also notice there is an explicit lag too - there is a minimum amount of finger movement before it considers it a scroll. this is just due to the nature of inaccurate finger input. > > btw - scrolling issues were also a problem of the event loop in some ways > > and has been fixed in the meantime - but you are unlikely to see those > > fixes until fso/shr or om2008.x update. (basically it was getting and > > actually responding to more mouse events than it could handle delaying > > rendering even more than it should have been 0 i fixed that. it shouldnt > > have been doing it but somewhere along the way a excess mouse move filter > > got removed and i dont know when/where so i put one back in). it all went > > smooth again. > > > Good to hear! Even more to look forward to in future distribution > upgrades. :-) > [...] > >> 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. > > > > as per my other mail. the reason i DIDNT do this is that there is a > > tradeoff - every precompute means u have to store it. storing means using > > up more ram, and using less cpu. you give up one resource for another. ALSO > > you need to > > Right, wasting too much memory is not the way to go either. yup. so this stuff always comes with a big gotcha. use mroe ram, so also now use cpu caches less effectively, and possibly pay a price of cycling the scale caches too often thus negating the benefit. so as such i just have not done it to date as it simply has not turned out an "on average win". > > intelligently differentiate dynamic data vs static. lets say u have a vidoe > > that changes data every frame - there is zero point in computing a scaled > > version and making a copy of it to keep as next frame it will be different. > > same for when the image or data keeps changing size. each frame its a new > > size. again - pointless to keep a copy. its not so easy just to > > "precompute" it makes coding life harder as the programmer now needs to do > > this in advance. you want the api to figure it out for u and just do it by > > magic. as i said - i have a patch that added a scalecache that does this, > > but it also introduced bugs and thus isnt in. i havent had time ot come > > back to it lately - but its on my todo list. > > Yes, I understand this is hard to do in the general case. > The application
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Carsten Haitzler (The Rasterman) wrote: > i really suggest you have a better look at the code. it uses timepoints. Good advice. Critic based on assumptions isn't good enough. Still, the problem remain. The user interface is a bit on the slow side. And it doesn't have to - simplified themes are faster. Eye candy is nice - but not when it cause performance problems. eye candy is also nice for showing off a great product - but this backfires when it demonstrates slowness. [enlightenment graphichs explanation deleted] >> 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! > > and runs in 8bpp and doesnt alpha blend, doesnt do interpolated scaling. > doesnt > do a tonne of things. Well, it was a joke. Duke gets much speed from low resolution. Still - it raises questions. Do we want the resolution, 16bpp, alpha blend and so on? I happen to like the high resolution and color depth. So perhaps scrolling cannot go really fast in my case, and instead must to big jumps to keep up with finger speed. It'd still be nice if it was more responsive - scrolling start noticeably later than the dragging. > btw - scrolling issues were also a problem of the event loop in some ways and > has been fixed in the meantime - but you are unlikely to see those fixes until > fso/shr or om2008.x update. (basically it was getting and actually responding > to > more mouse events than it could handle delaying rendering even more than it > should have been 0 i fixed that. it shouldnt have been doing it but somewhere > along the way a excess mouse move filter got removed and i dont know > when/where > so i put one back in). it all went smooth again. > Good to hear! Even more to look forward to in future distribution upgrades. :-) [...] >> 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. > > as per my other mail. the reason i DIDNT do this is that there is a tradeoff - > every precompute means u have to store it. storing means using up more ram, > and > using less cpu. you give up one resource for another. ALSO you need to Right, wasting too much memory is not the way to go either. > intelligently differentiate dynamic data vs static. lets say u have a vidoe > that changes data every frame - there is zero point in computing a scaled > version and making a copy of it to keep as next frame it will be different. > same for when the image or data keeps changing size. each frame its a new > size. > again - pointless to keep a copy. its not so easy just to "precompute" it > makes > coding life harder as the programmer now needs to do this in advance. you want > the api to figure it out for u and just do it by magic. as i said - i have a > patch that added a scalecache that does this, but it also introduced bugs and > thus isnt in. i havent had time ot come back to it lately - but its on my todo > list. Yes, I understand this is hard to do in the general case. The application launcher's icon collection is a specific case though. The icons seem to be static, and they can be scaled once. (Actually, whenever the user resets the icon size or install more apps.) > > believe it or not evas's software engine is REALLY efficient and fast. it gets > both quality and speed. it plays some other tricks you barely even know exist. > i know about all these game engine tricks- i started life writing game engines > in assembly. i have just specifically chosen to handle certain paths for > certain reasons. and to date those paths have worked extremely well for the > workloads they were given. those paths were a LOT more dynamic with new data, > new/different sizes and much less re-use of images/.data at the same size > where > caching would help. > [...] >> Scary stuff. An interpreted language just for the icon set. > > again - you need to actually do your research. it's not interpreted at > all. .edc's are a data structure. they declare what becomes an in-memory > object tree with properties. they get compiled to binary .edj files that are > loaded and converted to real life objects REALLY FAST. its highly optimised. > they also cache and share instances so it only loads the 1 edje group once - > it > then just references the already loaded one and makes copies runtime. it keeps > them around even when not references speculatively in case they are needed > again. the only interpreted part is embryo script {} sections. inside of that > is also not interpreted like python or perl. its bytecompiled into a very > small efficient bytecode language. its stored in the .edj as bytecode so > simply loaded up - never compiled or interpreted at runtime as you see it. the > bytecode engine is VERY fast. it's 2x the s
Re: SHR first impression : it's slow ?
Joel Newkirk wrote: > BTW - the speed with which those icons scroll is how fast the main > Illume icons /should/ be able to be dragged, but with the Illume theme > as it currently stands (with FSO M5 and SHR at least) each 'desktop' > icon is adorned with multiple transparent PNG files layered to create > pretty buttons, and scrolling becomes dramatically slower than what you > are probably familiar with from the base ASU theme with 2008.x. > > I (and surely others) am working on a leaner, faster theme - any > eye-candy that distinctly impacts the user experience should NOT be > default, and in this case we desperately need a simple and fast theme > as the default or the immediate impression users will get is: "Damn, > this is slow!" Well, I think that the configuration panel icons can be dragged really quickly. I'm using e17-svn with the default theme and the software-x11-16 engine and the finger scrolling there is very fast and generally smooth. The main issue stays in the desktop, where the icon-dragging is really very slow. This must be really fixed. -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Fri, 27 Feb 2009 17:16:39 +0100 Flemming Richter Mikkelsen said: > Once again I write about something I shouldn't > write about at all since I don't know how it works. > > I could be very, very wrong here... just guessing: > > I got a feeling that no calculation (no effects) > is faster than this "optimal code". > > OM2008.0808 and earlier was quite fast and > I think adding all kinds of effects is a step > backward. > > No eye candy means that one could play > music, etc. when scrolling. > > Do we really need illume? Why not something > lighter with less/no visual effects, etc.? > > What happened with "back to the basics"? > > I don't think scalecache can make everything > as smooth as the good old GTK theme, but > it would be nice if I am wrong. it's really nothng to do with the the fading effects. 3 main reasons 1. om2008 theme has a black background. drawing a solid color is half the memory access bandwidth of drawing an image - even when not scaled. 2. it used the 16bit engine (the main main main reason for speed is this) 3. indeed icons where simple - even the label was simple text. the illume theme just inherits from e17's default. the text here includes a soft dropshadow - that shadowed text is draw.. believe it or not.. with 25 text draws in addition to the text, so 26. so it actually draws 26x the text for labels compared to the om2008 theme. the illume theme really just adds a few elements over e17's default - which is focused on a desktop. this just saves work for upstream to go make special themes for illume - i'm not happy with illume anyway. it's had a lot of compromises and things done quickly to meet requests, so until i give it some of the attention it needs to fix it up, it isn't going to have upstream's theme really change as it is currently just on "minimal effort' to make it work. keep working on themes YOU want - make the ui the way YOU like. that is the point of themes being so flexible - they can do a LOT. they alsoo have a very big affect on performance. N.B. the default e17 theme and illume work like a charm on more modern embedded systems (phones as well) with more modern soc's - even with software rendering, so the eyecandy is worth it. freerunner is just a fairly "pathological case" in that it has incredibly low compute/draw power and a LOT of pixels to fill. if you ask me the right design would have been something more like qvga lcd if you changed nothing else on the device. i otherwise liken it to putting a lawnmower engine into a ferrari body - the screen LOOKS nice, like the ferrari, but don't expect it to go well. (it's a little extreme i know - but i'm making a point). if you actually read the glamo specs and programming docs its very apparent it was designed for qvga, and vga is a totally "on the limit" edge case. the soc also is old and vga refresh uses up a significant bandwidth percentage of the memory bandwidth available. by contrast vga uses up "almost nothing" compared to the bandwidth available on the 6410 or even the omap3 where its pretty much a non-event. so don't get me wrong - it's just that you need to be realistic. the FR is a corner-case in the device world. at least upstream dev like efl is focusing on "whats common" not "whats out there in a strange corner". it can work - but it needs careful tuning and attention for corner cases. so do your themes - reduce thew workload for the renderer. a scalecache DOES help. i have checked. its a visible difference. :) it just needs to be done so it doesnt cause instability :) thats on my todo actually in the next few weeks. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Fri, 27 Feb 2009 15:13:39 -0300 robert lazarski said: > On Fri, Feb 27, 2009 at 11:35 AM, The Rasterman Carsten Haitzler > wrote: > > On Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting > > said: > > > >> Joel Newkirk wrote: > > > >> 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. > > > > if i want to impress i do not show them a freerunner. i show them something > > with much better hardware :) > > > > You mean like this? > > http://www.youtube.com/watch?v=E6J5EtiQ1ps > > Its not opensource, but still impressive and far beyond anything FR is > dreaming of I'm afraid. well ok- i don't have one of those, but i do have hardware that is better - ask everyone who has a beagleboard how amazing the cortex-a8 is and omap3... as far as a cpu/soc it totally wipes the fr off the table. we all know the fr is old hw - it's open. that's its positive. it is not something i'd use to impress people with how amazing linux is on embedded devices. for ooh ahh drool value there's s3c6410 based hardware around that really whips the fr, and that is yet again whipped by omap3. don't get me wrong - OPEN is awesome. that is fantastic. FR is not something used to impress when it comes to eyecandy :) of course time will tell - newer more modern hw with an open os ready to "hack" will appear. when its up to snuff with an up-to-date soc etc. - then we can talk :) > BTW, see you soon in porto de galinas :-) . muito bom! :) :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
2009/2/27, Johny Tenfinger : > On Fri, Feb 27, 2009 at 21:26, "Marco Trevisan (Treviño)" > wrote: >> ELM_ENGINE=x16 > > No - it should be: > ELM_ENGINE=x11-16 x11-16, x16, software-16-x11, software_16_x11 will all work ... hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
On Fri, Feb 27, 2009 at 21:26, "Marco Trevisan (Treviño)" wrote: > ELM_ENGINE=x16 No - it should be: ELM_ENGINE=x11-16 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Xavier Cremaschi wrote: > 3. SHR Panels : some panels in 'Settings' hang when I click on them > (GSM/operators for example) I'd suggest you to use the Software-X11-16 engine also for elementary and not only for Enlightenment (where can be set by the configuration -> Advanced -> engine). To use it in elementary you should export the environment variable ELM_ENGINE=x16 Put it in ~/.profile for example... ;) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Fri, Feb 27, 2009 at 11:35 AM, The Rasterman Carsten Haitzler wrote: > On Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting said: > >> Joel Newkirk wrote: > >> 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. > > if i want to impress i do not show them a freerunner. i show them something > with much better hardware :) > You mean like this? http://www.youtube.com/watch?v=E6J5EtiQ1ps Its not opensource, but still impressive and far beyond anything FR is dreaming of I'm afraid. BTW, see you soon in porto de galinas :-) . - R ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Once again I write about something I shouldn't write about at all since I don't know how it works. I could be very, very wrong here... just guessing: I got a feeling that no calculation (no effects) is faster than this "optimal code". OM2008.0808 and earlier was quite fast and I think adding all kinds of effects is a step backward. No eye candy means that one could play music, etc. when scrolling. Do we really need illume? Why not something lighter with less/no visual effects, etc.? What happened with "back to the basics"? I don't think scalecache can make everything as smooth as the good old GTK theme, but it would be nice if I am wrong. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Wed, 25 Feb 2009 23:43:00 -0500 Joel Newkirk said: > On Wed, 25 Feb 2009 12:43:59 +0100 > Helge Hafting wrote: > > > Joel Newkirk wrote: > > > > With the default.edj theme (Illume doesn't override it for Fileman, > > > which includes Illume icons) every icon on the 'desktop' initially > > > displays just the icon image, be it png, jpg, animated edj, > > > whatever. When you touch the screen to scroll it, it will highlight > > > the touched icon even if you don't actually select it. > > Hm - it shoudln't highlight unless it actually is selected. :-/ > > > When it highlights it, it > > > makes visible a 'background' png behind the icon, and two or three > > > layers of transparent pngs on top of the icon, to give the 'glass > > > button with an icon embedded in it' effect. Even when not visible > > > (IE, on at least all but one icon at a time) those extra pngs are > > > there, their positions are calculated AFAIK and their bitmaps are > > > loaded. > > > > I'm not sure if I understand that. Only one icon looks like a glass > > button - sure. Now, I understand that illume may have precomputed the > > glass button look for every icon there is, spending some memory. But > > why should that need any cpu when scrolling? The glass button effect > > isn't applied to the other icons, so those glass images should just > > sit in memory somewhere untouched? > > > > > (again, AFAIK - those two are internals of Enlightenment and I'm > > > guessing) > > 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 > element in the GUI is flagged visible=0 that it still calculates its > position onscreen, so that if you have 20 icons in Illume then you're > trying to scroll at least 100 transparent png images. ('icon' image, > background, shine, highlight, shadow - there are actually 9 png images > specified, plus the icon image itself) Pasted at the end is the entire > group "e/fileman/desktop/icon/fixed" from default.edc. You can see that > each icon actually contains eight png images, and twelve programs, > including six that specify animated transitions. evas does not load the data for an image file until needed. it only loads header. also when its in the theme its no longer a png. it's a much simpler encoding of argb data in the .edj (still compressed tho based on the .edj source options). it also only loads one copy once. every extra copy is just a reference to the existing one. so as such you are only paying the cost of an extra object, not an extra image. be it a rectangle or an image - same cost pretty much. also remember the animation of the fade is a redraw, as is the scroll. so they equate to the same thing actually. simply the fact that it draws under and above 1 icon a base and overlay is the extra rendering cost. this of course means dynamic stretching of it. also for calculations - its a really simple one to calculate a move of an obj - its simply doing some sets of x,y, integers. its nothing really unless you are talking 1000's of objects... > it also doesn't help that Enlightenment is advanced enough to perform > some very nice scaling tricks - like specifying that 6 pixels inward > from each edge should not be stretched away from that edge, so for > example you can have a 13x13 PNG that functions as a 6-pixel border, > with the central pixel being scaled as large as needed, while the edges > are only stretched in one dimension, along the edge. 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... actually nothing floating point here at all. all integer. evas actually scales quite fast. considering its scaling everything on the fly... with interpolation and/or supersampling. it has no code to cache such work (yet). if i were you - i'd wait for the scalecache :) i have demo code that does it but it .. is buggy. basically evas will detect is scales something to a specific size for more than N draws then it generates a copy and keeps it and re-uses it. :) so no need to work in the theme as its done runtime. > > > But to make the user experience worse, whenever those extra pngs are > > > made visible or invisible, it uses an animated fade-in/fade-out. So > > > every time you drag to scroll, it's busy animating a fade-out on the > > > previously highlighted icon, animating a fade-in on the one under > > > your finger, and scrolling all the transparent and invisible PNGs. > > > The effect is quite attractive, if only the FR had the horsepower > > > to manage it while running a phone, GPS, and frameworkd. :( > > > > I see no fade effect. When I click an icon,
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting said: > Joel Newkirk wrote: > > On Wed, 25 Feb 2009 12:43:59 +0100 > > Helge Hafting 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. :-( i really suggest you have a better look at the code. it uses timepoints. animation simply modifies properties of objects - doesnt RENDER at points in time. when you begin an anim it flags things at point A. then when the next frame "tick" rolls around it calculates whatever properties (size, position, alpha etc.) and applies those. applying does NO rendering. all it does is set values in data structures. small values. its very efficient. after all the coee that is transitioning opject values finishes setting the properties - and everything goes idle THEN it decides to draw/render - whatever the state is at now. if the animation already completed (eg animation was set to take 0.1 second, but actually 0.2 seconds has elapsed since the start) all properties will just instantly be set to the final state and only that rendered. if you want to find out how the code works ask those that wrote it. dont assume from things you read here :) it's not making a "movie" per icon. it's simply modifying a few parameters (maybe a grand total of 50 of them) per frame. and then it only renders the frames it CAN render. if u set the framerate to 200fps - it sure as hell wont calculate 200 frames per second as it will be render limited and will only calculate what it can. the code is very smart and does just what is needed. > 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! and runs in 8bpp and doesnt alpha blend, doesnt do interpolated scaling. doesnt do a tonne of things. btw - scrolling issues were also a problem of the event loop in some ways and has been fixed in the meantime - but you are unlikely to see those fixes until fso/shr or om2008.x update. (basically it was getting and actually responding to more mouse events than it could handle delaying rendering even more than it should have been 0 i fixed that. it shouldnt have been doing it but somewhere along the way a excess mouse move filter got removed and i dont know when/where so i put one back in). it all went smooth again. > 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. as per my other mail. the reason i DIDNT do this is that there is a tradeoff - every precompute means u have to store it. storing means using up more ram, and using less cpu. you give up one resource for another. ALSO you need to intelligently differentiate dynamic data vs static. lets say u have a vidoe that changes data every frame - there is zero point in computing a scaled version and making a copy of it to keep as next frame it will be different. same for when the image or data keeps changing size. each frame its a new size. again - pointless to keep a copy. its not so easy just to "precompute" it makes coding life harder as the programmer now needs to do this in advance. you want the api to figure it out for u and just do it by magic. as i said - i have a patch that added a scalecache that does this, but it also introduced bugs and thus isnt in. i havent had time ot come back to it lately - but its on my todo list. believe it or not evas's software engine is REALLY efficient and fast. it gets both quality and speed. it plays some other tricks you barely even know exist. i know about all these game engine tricks- i started life writing game engines in assembly. i have just specifically chosen to handle certain paths for certain reasons. and
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
2009/2/26 Helge Hafting : > Joel Newkirk wrote: >> On Wed, 25 Feb 2009 12:43:59 +0100 >> Helge Hafting 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. :-( Perhaps you should have alook at the efl before stating such things. I also don't have much insight, but thats what I think I understood: The non-visible parts shouldn't need any but size caclculations, the layering and stuff is also reasonably fast, at least much faster than what the FR can transfer to the screen anyway. I think the main proplem is the scaling, smooth scaling is pretty slow, there is a scale cache planned, but not actually finished, when it comes things will get much faster. The efl are way faster than any other toolkit I know of, especially if you trim down theming. > 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! Well does it do alpha? And is it using the screen in 480x640 or only a quarter the screen size? > 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. Really have a look at the EFL, very efficient. Problem is, the Theme just needs to be optimized. And using the 16-bit engine also gives a huge speedup. > [...] >> 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. If it can't cope with the high framerate it will of course simply drop frames. And for parts it will easily hit 30 fps, that's why I leave it on default (but disable some animations). > 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.
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting wrote: > Joel Newkirk wrote: > > On Wed, 25 Feb 2009 12:43:59 +0100 > > Helge Hafting 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. :-( Well as I said, I don't know to what degree and in what fashions this may be optimized within E - I'm assuming that it prescales and doesn't scale on the fly, but that the scrolling needs to take all visible and non-visible parts into account - I don't know this however, I'm guessing. > 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. ;-) :) Thanks, and to BillK for the enlightening and entertaining link. :) With my car broken down this morning, any amusement is welcome. > [...] > > 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. My philosophy has always been colored by my time with the Amiga. I 'grew up' believing that clever hardware and clever software could overcome limited horsepower, and that the immediacy of feedback provided by a responsive GUI is often worth more than a doubled clock. (at 7mhz it 'felt' as fast as some 3ghz beasts I've used, simply because everything was tweaked for smooth consistent responsiveness) > [...] > > 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. What has me concerned on this front, looking more long-term, is that OM have exhibited a tremendous reluctance to make the Illume/Enlightenment config accessible, so that changing framerate and disabling animations of windows opening, Top Shelf opening/closing, etc are currently not possible for a new owner 'out of the box'. Hopefully that'll be addressed before the platform reaches more mainstream (read: non-hacker) customers... And not by simply disabling such features, though that might be preferable to enabled and unconfigurable. > > 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. Still guessing, but I expect the scaling only takes place once. > > 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-dial
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Thu, 2009-02-26 at 11:31 +0100, Helge Hafting wrote: > Joel Newkirk wrote: > > On Wed, 25 Feb 2009 12:43:59 +0100 > > Helge Hafting wrote: > > > >> Joel Newkirk wrote: > > ... > 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. ;-) ... > 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 > you would love this then ... http://www.cs.unm.edu/~dlchao/flake/doom/ :) BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Joel Newkirk wrote: > On Wed, 25 Feb 2009 12:43:59 +0100 > Helge Hafting 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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Helge Hafting a écrit : > For example: > telnet localhost gpsd > r > You should get at least one message per second after hitting "enter" > after the "r" - whether you have a fix or not. Already done, 1 msg/second, always the same (no fix inside, no numerical values) > You may also want to try > grep ogpsd < /var/log/frameworkd.log > check if there are any messages indicating trouble. this particular one > is normal, although it looks like a problem: > > 2009.02.25 22:47:06 ogpsdWARNING (could not write to > '/sys/bus/platform/devices/neo1973-pm-gps.0/power_on': [Errno 2] No such > file or directory:'/sys/bus/platform/devices/neo1973-pm-gps.0/power_on') Already done too, I made an update yesterday @ 23h00 CET time, and just after I deleted the pickle file and rebooted, and I had a fix. I presume a bug was fixed. Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
On Thu, Feb 26, 2009 at 10:49, Pander wrote: > Is openmoko-agpsui still an up to date tool for SHR to manage the GPS > operation? No. Use Zhone for that. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Helge Hafting wrote: > Xavier Cremaschi wrote: >> Helge Hafting a écrit : >>> Remove the file /etc/freesmartphone/persist/ogpsd.pickle >>> then, restart frameword or just reboot. (Restarting frameworkd sometimes >>> cause trouble with the phone side instead). >>> >>> ogpsd.pickle is where gps information is saved in order to speed up the >>> next activation of the gps unit. It goes bad sometimes, particularly >>> after starting a newly flashed SHR unstable. If this file goes bad >>> enough, you wont get a fix - ever! >>> >>> Deleting the file forces the gps to "cold start", which may take an >>> extra minute or two. But it works reliably. When you stop using the gps >>> unit, a new ogpsd.pickle file is created - this time with good data. >>> >>> Helge Hafting >> >> Already done, no fix at all after >40min. > > Then I don't know - deleting the pickle file was the fix for me. > > You may want to take a look at the mailing list archives, there are > various procedures for checking that the gps has power and such. > > For example: > telnet localhost gpsd > r > You should get at least one message per second after hitting "enter" > after the "r" - whether you have a fix or not. If this works, then > things are mostly ok you just don't have a fix. If you get nothing, then > there are communication or power problems that prevents the gps unit > from working. > > You may also want to try > grep ogpsd < /var/log/frameworkd.log > check if there are any messages indicating trouble. this particular one > is normal, although it looks like a problem: > > 2009.02.25 22:47:06 ogpsdWARNING (could not write to > '/sys/bus/platform/devices/neo1973-pm-gps.0/power_on': [Errno 2] No such > file or directory:'/sys/bus/platform/devices/neo1973-pm-gps.0/power_on') > Is openmoko-agpsui still an up to date tool for SHR to manage the GPS operation? > > Helge Hafting > > ___ > 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: SHR first impression : it's slow ?
Xavier Cremaschi wrote: > Helge Hafting a écrit : >> Remove the file /etc/freesmartphone/persist/ogpsd.pickle >> then, restart frameword or just reboot. (Restarting frameworkd sometimes >> cause trouble with the phone side instead). >> >> ogpsd.pickle is where gps information is saved in order to speed up the >> next activation of the gps unit. It goes bad sometimes, particularly >> after starting a newly flashed SHR unstable. If this file goes bad >> enough, you wont get a fix - ever! >> >> Deleting the file forces the gps to "cold start", which may take an >> extra minute or two. But it works reliably. When you stop using the gps >> unit, a new ogpsd.pickle file is created - this time with good data. >> >> Helge Hafting > > > Already done, no fix at all after >40min. Then I don't know - deleting the pickle file was the fix for me. You may want to take a look at the mailing list archives, there are various procedures for checking that the gps has power and such. For example: telnet localhost gpsd r You should get at least one message per second after hitting "enter" after the "r" - whether you have a fix or not. If this works, then things are mostly ok you just don't have a fix. If you get nothing, then there are communication or power problems that prevents the gps unit from working. You may also want to try grep ogpsd < /var/log/frameworkd.log check if there are any messages indicating trouble. this particular one is normal, although it looks like a problem: 2009.02.25 22:47:06 ogpsdWARNING (could not write to '/sys/bus/platform/devices/neo1973-pm-gps.0/power_on': [Errno 2] No such file or directory:'/sys/bus/platform/devices/neo1973-pm-gps.0/power_on') Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Wed, 25 Feb 2009 12:43:59 +0100 Helge Hafting wrote: > Joel Newkirk wrote: > > With the default.edj theme (Illume doesn't override it for Fileman, > > which includes Illume icons) every icon on the 'desktop' initially > > displays just the icon image, be it png, jpg, animated edj, > > whatever. When you touch the screen to scroll it, it will highlight > > the touched icon even if you don't actually select it. > Hm - it shoudln't highlight unless it actually is selected. :-/ > > When it highlights it, it > > makes visible a 'background' png behind the icon, and two or three > > layers of transparent pngs on top of the icon, to give the 'glass > > button with an icon embedded in it' effect. Even when not visible > > (IE, on at least all but one icon at a time) those extra pngs are > > there, their positions are calculated AFAIK and their bitmaps are > > loaded. > > I'm not sure if I understand that. Only one icon looks like a glass > button - sure. Now, I understand that illume may have precomputed the > glass button look for every icon there is, spending some memory. But > why should that need any cpu when scrolling? The glass button effect > isn't applied to the other icons, so those glass images should just > sit in memory somewhere untouched? > > > (again, AFAIK - those two are internals of Enlightenment and I'm > > guessing) 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 element in the GUI is flagged visible=0 that it still calculates its position onscreen, so that if you have 20 icons in Illume then you're trying to scroll at least 100 transparent png images. ('icon' image, background, shine, highlight, shadow - there are actually 9 png images specified, plus the icon image itself) Pasted at the end is the entire group "e/fileman/desktop/icon/fixed" from default.edc. You can see that each icon actually contains eight png images, and twelve programs, including six that specify animated transitions. it also doesn't help that Enlightenment is advanced enough to perform some very nice scaling tricks - like specifying that 6 pixels inward from each edge should not be stretched away from that edge, so for example you can have a 13x13 PNG that functions as a 6-pixel border, with the central pixel being scaled as large as needed, while the edges are only stretched in one dimension, along the edge. 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... > > But to make the user experience worse, whenever those extra pngs are > > made visible or invisible, it uses an animated fade-in/fade-out. So > > every time you drag to scroll, it's busy animating a fade-out on the > > previously highlighted icon, animating a fade-in on the one under > > your finger, and scrolling all the transparent and invisible PNGs. > > The effect is quite attractive, if only the FR had the horsepower > > to manage it while running a phone, GPS, and frameworkd. :( > > I see no fade effect. When I click an icon, it gets the "glass" > effect. It appear with a slight delay, but there is no visible "fade > in". One minute there is just the icon, the next moment it is > "glassed". So if much work goes into this - then it is all wasted. 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. You can see it in the first two program sections below, "go_active" and "go_passive". The thumb_gen series with the decelerated and sinusoidal transitions aren't used on the Illume desktop it seems, but if you for example open the wallpaper settings in Illume config you can observer thumbnails that 'zoom' out from zero size when displayed, to become clickable 'icons'. > > > > With the present state of my altered Illume theme (serenity.edj) > > I've trimmed the icons down to just the 'icon' image itself and a > > single png that appears behind it when highlighted. Outside the > > theme itself I've disabled dropshadows and changed rendering, and > > disabled the battery applet display (pending debugging - it sucks > > CPU apparently) and it reduced Enlightenment cpu usage > > dramatically. > > > > But I found significant further savings by tweaking icons. > [...] > I am lookin
Re: SHR first impression : it's slow ?
Helge Hafting a écrit : > Remove the file /etc/freesmartphone/persist/ogpsd.pickle > then, restart frameword or just reboot. (Restarting frameworkd sometimes > cause trouble with the phone side instead). > > ogpsd.pickle is where gps information is saved in order to speed up the > next activation of the gps unit. It goes bad sometimes, particularly > after starting a newly flashed SHR unstable. If this file goes bad > enough, you wont get a fix - ever! > > Deleting the file forces the gps to "cold start", which may take an > extra minute or two. But it works reliably. When you stop using the gps > unit, a new ogpsd.pickle file is created - this time with good data. > > Helge Hafting Already done, no fix at all after >40min. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Finally I found a repo with working links-x11! Dziękuję indeed. On Wed, Feb 25, 2009 at 2:25 PM, Petr Vanek wrote: > On Wed, 25 Feb 2009 13:24:18 +0100 > Johny Tenfinger (JT) wrote: > >>cd /etc/opkg && wget >>http://openmoko.opendevice.org/build/shr-unstable/feed/shr-unstable-pl.conf > > Dziękuję bardzo :) > > btw watch for the line wraps whoever wants to use the above :) > > uff, these are tons of updates! what am i getting into? :) > > cheers > Petr > > > > ___ > 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: SHR first impression : it's slow ?
On Wed, 25 Feb 2009 13:24:18 +0100 Johny Tenfinger (JT) wrote: >cd /etc/opkg && wget >http://openmoko.opendevice.org/build/shr-unstable/feed/shr-unstable-pl.conf Dziękuję bardzo :) btw watch for the line wraps whoever wants to use the above :) uff, these are tons of updates! what am i getting into? :) cheers Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
On Wed, Feb 25, 2009 at 13:18, Petr Vanek wrote: > just curious - how long does it take for it to boil all through the way > into packages for opkg uppgrade? (of course i can get a git snapshot > immediately) I don't know, but package is now updated in my repo (compatible with shr-unstable): cd /etc/opkg && wget http://openmoko.opendevice.org/build/shr-unstable/feed/shr-unstable-pl.conf ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
On Wed, 25 Feb 2009 13:10:12 +0100 Johny Tenfinger (JT) wrote: >On Wed, Feb 25, 2009 at 12:50, Helge Hafting >wrote: >> Remove the file /etc/freesmartphone/persist/ogpsd.pickle >> then, restart frameword or just reboot. (Restarting frameworkd >> sometimes cause trouble with the phone side instead). > >I've just commited to shr-settings ability to remove ogpsd.pickle file >from GUI ;) thank you just curious - how long does it take for it to boil all through the way into packages for opkg uppgrade? (of course i can get a git snapshot immediately) -- Petr Vaněk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
On Wed, Feb 25, 2009 at 12:50, Helge Hafting wrote: > Remove the file /etc/freesmartphone/persist/ogpsd.pickle > then, restart frameword or just reboot. (Restarting frameworkd sometimes > cause trouble with the phone side instead). I've just commited to shr-settings ability to remove ogpsd.pickle file from GUI ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Fernando Martins wrote: > Xavier Cremaschi wrote: >> I cannot make it working. Hardware is ok since it worked with Om2008.8, >> timezone/time is good, but no fix... 'telnet localhost 2947' always >> output same 'empty' data. >> >> > Someone recently (2 weeks ago or so) posted some steps to solve this. > Unfortunately I didn't bookmark it and I can't look for it right now. Remove the file /etc/freesmartphone/persist/ogpsd.pickle then, restart frameword or just reboot. (Restarting frameworkd sometimes cause trouble with the phone side instead). ogpsd.pickle is where gps information is saved in order to speed up the next activation of the gps unit. It goes bad sometimes, particularly after starting a newly flashed SHR unstable. If this file goes bad enough, you wont get a fix - ever! Deleting the file forces the gps to "cold start", which may take an extra minute or two. But it works reliably. When you stop using the gps unit, a new ogpsd.pickle file is created - this time with good data. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Joel Newkirk wrote: > On Tue, 24 Feb 2009 12:32:09 +0100 > Helge Hafting wrote: > >> Yorick Moko wrote: I (and surely others) am working on a leaner, faster theme - any eye-candy that distinctly impacts the user experience should NOT be default, and in this case we desperately need a simple and fast theme as the default or the immediate impression users will get is: "Damn, this is slow!" >>> nice to hear that >>> ugly and fast beats pretty and damn slow any day for me >>> (pretty and fast would also be acceptable ;-)) >> Pretty and fast should be possible then. >> >> There is no need for multiple layers of transparent icons. They can >> be collapsed into one layer with a single transparent icon, looking >> _exactly_ the same. >> >> Effects when a icon is actually selected is another story, but that >> sort of thing should not need to impact scrolling. >> >> Helge Hafting > > Therein lies the problem, in a sense. (or a large part of it) > > With the default.edj theme (Illume doesn't override it for Fileman, > which includes Illume icons) every icon on the 'desktop' initially > displays just the icon image, be it png, jpg, animated edj, whatever. > When you touch the screen to scroll it, it will highlight the touched > icon even if you don't actually select it. Hm - it shoudln't highlight unless it actually is selected. :-/ > When it highlights it, it > makes visible a 'background' png behind the icon, and two or three > layers of transparent pngs on top of the icon, to give the 'glass > button with an icon embedded in it' effect. Even when not visible (IE, > on at least all but one icon at a time) those extra pngs are there, > their positions are calculated AFAIK and their bitmaps are loaded. I'm not sure if I understand that. Only one icon looks like a glass button - sure. Now, I understand that illume may have precomputed the glass button look for every icon there is, spending some memory. But why should that need any cpu when scrolling? The glass button effect isn't applied to the other icons, so those glass images should just sit in memory somewhere untouched? > (again, AFAIK - those two are internals of Enlightenment and I'm > guessing) > > But to make the user experience worse, whenever those extra pngs are > made visible or invisible, it uses an animated fade-in/fade-out. So > every time you drag to scroll, it's busy animating a fade-out on the > previously highlighted icon, animating a fade-in on the one under your > finger, and scrolling all the transparent and invisible PNGs. The > effect is quite attractive, if only the FR had the horsepower to manage > it while running a phone, GPS, and frameworkd. :( I see no fade effect. When I click an icon, it gets the "glass" effect. It appear with a slight delay, but there is no visible "fade in". One minute there is just the icon, the next moment it is "glassed". So if much work goes into this - then it is all wasted. > > With the present state of my altered Illume theme (serenity.edj) I've > trimmed the icons down to just the 'icon' image itself and a single png > that appears behind it when highlighted. Outside the theme itself I've > disabled dropshadows and changed rendering, and disabled the battery > applet display (pending debugging - it sucks CPU apparently) and it > reduced Enlightenment cpu usage dramatically. > > But I found significant further savings by tweaking icons. [...] I am looking forward to see all this. :-) It should definitely improve the user experience. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Joel Newkirk wrote: > On Wed, 25 Feb 2009 09:19:37 +0800 > HouYu Li wrote: > >> Sounds amazing. But where can we get the serenity.edj theme??? >> > > Nowhere right now, I'm working on it. I've gotten a few thing just > how I want them, others as yet untouched, and occasional bugs. > Started with illume.edj, imported some pieces of default.edj to make > overriding them easier, and started in changing the look. Probably > 2/3 done now, but I've kept restarting as I changed from 2008.x to FSO > to SHR and so on and kept resyncing my changes to the newest Illume > changes. Will you work to get your performance improvements into SHR? Scrolling with good responsitivity would be great to have! Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Carl Lobo a écrit : > Is fso-gpsd running? Try restarting it from Settings/Services. GPS > seems to be working fine for me with my last update on Monday.. Yes of course, - date and timezone ok - persist file removed - fso-gpsd restarted - no concurrent gpsd running - telnet localhost 2947 ok but without real data when press on r (but lots of commas !) And no fix in tangogps even after long time. Xavier. PS : but you're right to mention trivial things, to avoid the "omfg-cable-was-unplugged-since-beginning" syndrom ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Wed, 25 Feb 2009 09:19:37 +0800 HouYu Li wrote: > Sounds amazing. But where can we get the serenity.edj theme??? > Nowhere right now, I'm working on it. I've gotten a few thing just how I want them, others as yet untouched, and occasional bugs. Started with illume.edj, imported some pieces of default.edj to make overriding them easier, and started in changing the look. Probably 2/3 done now, but I've kept restarting as I changed from 2008.x to FSO to SHR and so on and kept resyncing my changes to the newest Illume changes. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Is fso-gpsd running? Try restarting it from Settings/Services. GPS seems to be working fine for me with my last update on Monday.. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Sounds amazing. But where can we get the serenity.edj theme??? On Wed, Feb 25, 2009 at 5:18 AM, Joel Newkirk wrote: > On Tue, 24 Feb 2009 12:32:09 +0100 > Helge Hafting wrote: > > > Yorick Moko wrote: > > >> I (and surely others) am working on a leaner, faster theme - any > > >> eye-candy that distinctly impacts the user experience should NOT be > > >> default, and in this case we desperately need a simple and fast > > >> theme as the default or the immediate impression users will get > > >> is: "Damn, this is slow!" > > >> > > > > > > nice to hear that > > > ugly and fast beats pretty and damn slow any day for me > > > (pretty and fast would also be acceptable ;-)) > > > > Pretty and fast should be possible then. > > > > There is no need for multiple layers of transparent icons. They can > > be collapsed into one layer with a single transparent icon, looking > > _exactly_ the same. > > > > Effects when a icon is actually selected is another story, but that > > sort of thing should not need to impact scrolling. > > > > Helge Hafting > > Therein lies the problem, in a sense. (or a large part of it) > > With the default.edj theme (Illume doesn't override it for Fileman, > which includes Illume icons) every icon on the 'desktop' initially > displays just the icon image, be it png, jpg, animated edj, whatever. > When you touch the screen to scroll it, it will highlight the touched > icon even if you don't actually select it. When it highlights it, it > makes visible a 'background' png behind the icon, and two or three > layers of transparent pngs on top of the icon, to give the 'glass > button with an icon embedded in it' effect. Even when not visible (IE, > on at least all but one icon at a time) those extra pngs are there, > their positions are calculated AFAIK and their bitmaps are loaded. > (again, AFAIK - those two are internals of Enlightenment and I'm > guessing) > > But to make the user experience worse, whenever those extra pngs are > made visible or invisible, it uses an animated fade-in/fade-out. So > every time you drag to scroll, it's busy animating a fade-out on the > previously highlighted icon, animating a fade-in on the one under your > finger, and scrolling all the transparent and invisible PNGs. The > effect is quite attractive, if only the FR had the horsepower to manage > it while running a phone, GPS, and frameworkd. :( > > With the present state of my altered Illume theme (serenity.edj) I've > trimmed the icons down to just the 'icon' image itself and a single png > that appears behind it when highlighted. Outside the theme itself I've > disabled dropshadows and changed rendering, and disabled the battery > applet display (pending debugging - it sucks CPU apparently) and it > reduced Enlightenment cpu usage dramatically. > > But I found significant further savings by tweaking icons. I've been > using some Oxygen icons, and because I always have the launcher at > 'extra large' (3 icons across in portrait) I started out with the > 256x256 oxygen icons. Which are beautiful, but suck resources like > crazy. I figured changing to 128x128 would help but the problem was > almost exactly the same, while it looked worse on screen. So I did some > investigating and testing and found that if I prescale my icons to the > actual displayed size on the FR it responds great. In this case, > that's 116x116 pixels. (that's the icon itself at 'extra large' - > Illume displays the name below that, and the two of them are in IIRC a > 162x142 tile) > > So by prescaling to 116x116 pixel icons in Gimp I get the same memory > and CPU (hence UI responsiveness) as with much smaller (blotchier > after scaling) images. 'Large' launcher icons appear to be 76x76, and > 'medium' 36x36. This is theme-dependent though, as well as preferences > dependent - within the edje theme they can be scaled or resized or > whatever. So a prepackaged icon theme would probably need to be scaled > to match a particular Illume theme's resulting sizes... Even then, if > the user has utilized the useful 'scaling' settings it will probably > differ. Still pondering the best answer here. > > So right now, with the rescaled icons, removing excess icon adornments, > and disabling dropshadows and battery the SHR Illume is /almost/ as > smooth scrolling as 2008.x. I also found that disabling animation of > the slipshelf drop-down etc helped significantly in making it feel more > responsive. Overall, it feels like a completely different phone when I > switch back to the Illume theme. > > j > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Best Regards HouYu Li, Karajan karajan_ii (at) hotmail.com karadog (at) gmail.com lihouyu (at) phpex.net PHP Programmer Red Hat Certified Engineer 15th Feb, 2008 Shanghai, China ___ Openmoko community mailing list
Re: SHR first impression : it's slow ?
Xavier Cremaschi wrote: > I cannot make it working. Hardware is ok since it worked with Om2008.8, > timezone/time is good, but no fix... 'telnet localhost 2947' always > output same 'empty' data. > > Someone recently (2 weeks ago or so) posted some steps to solve this. Unfortunately I didn't bookmark it and I can't look for it right now. Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Tue, 24 Feb 2009 12:32:09 +0100 Helge Hafting wrote: > Yorick Moko wrote: > >> I (and surely others) am working on a leaner, faster theme - any > >> eye-candy that distinctly impacts the user experience should NOT be > >> default, and in this case we desperately need a simple and fast > >> theme as the default or the immediate impression users will get > >> is: "Damn, this is slow!" > >> > > > > nice to hear that > > ugly and fast beats pretty and damn slow any day for me > > (pretty and fast would also be acceptable ;-)) > > Pretty and fast should be possible then. > > There is no need for multiple layers of transparent icons. They can > be collapsed into one layer with a single transparent icon, looking > _exactly_ the same. > > Effects when a icon is actually selected is another story, but that > sort of thing should not need to impact scrolling. > > Helge Hafting Therein lies the problem, in a sense. (or a large part of it) With the default.edj theme (Illume doesn't override it for Fileman, which includes Illume icons) every icon on the 'desktop' initially displays just the icon image, be it png, jpg, animated edj, whatever. When you touch the screen to scroll it, it will highlight the touched icon even if you don't actually select it. When it highlights it, it makes visible a 'background' png behind the icon, and two or three layers of transparent pngs on top of the icon, to give the 'glass button with an icon embedded in it' effect. Even when not visible (IE, on at least all but one icon at a time) those extra pngs are there, their positions are calculated AFAIK and their bitmaps are loaded. (again, AFAIK - those two are internals of Enlightenment and I'm guessing) But to make the user experience worse, whenever those extra pngs are made visible or invisible, it uses an animated fade-in/fade-out. So every time you drag to scroll, it's busy animating a fade-out on the previously highlighted icon, animating a fade-in on the one under your finger, and scrolling all the transparent and invisible PNGs. The effect is quite attractive, if only the FR had the horsepower to manage it while running a phone, GPS, and frameworkd. :( With the present state of my altered Illume theme (serenity.edj) I've trimmed the icons down to just the 'icon' image itself and a single png that appears behind it when highlighted. Outside the theme itself I've disabled dropshadows and changed rendering, and disabled the battery applet display (pending debugging - it sucks CPU apparently) and it reduced Enlightenment cpu usage dramatically. But I found significant further savings by tweaking icons. I've been using some Oxygen icons, and because I always have the launcher at 'extra large' (3 icons across in portrait) I started out with the 256x256 oxygen icons. Which are beautiful, but suck resources like crazy. I figured changing to 128x128 would help but the problem was almost exactly the same, while it looked worse on screen. So I did some investigating and testing and found that if I prescale my icons to the actual displayed size on the FR it responds great. In this case, that's 116x116 pixels. (that's the icon itself at 'extra large' - Illume displays the name below that, and the two of them are in IIRC a 162x142 tile) So by prescaling to 116x116 pixel icons in Gimp I get the same memory and CPU (hence UI responsiveness) as with much smaller (blotchier after scaling) images. 'Large' launcher icons appear to be 76x76, and 'medium' 36x36. This is theme-dependent though, as well as preferences dependent - within the edje theme they can be scaled or resized or whatever. So a prepackaged icon theme would probably need to be scaled to match a particular Illume theme's resulting sizes... Even then, if the user has utilized the useful 'scaling' settings it will probably differ. Still pondering the best answer here. So right now, with the rescaled icons, removing excess icon adornments, and disabling dropshadows and battery the SHR Illume is /almost/ as smooth scrolling as 2008.x. I also found that disabling animation of the slipshelf drop-down etc helped significantly in making it feel more responsive. Overall, it feels like a completely different phone when I switch back to the Illume theme. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
> 1. wifi : Wifi Mofi hangs when I run it > 3. SHR Panels : some panels in 'Settings' hang when I click on them > (GSM/operators for example) > 4. Everything is slow Seem better since yesterday evening upgrade, but it still very hard to scroll on desktop. > 2. gps : GPS cannot fix I cannot make it working. Hardware is ok since it worked with Om2008.8, timezone/time is good, but no fix... 'telnet localhost 2947' always output same 'empty' data. Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Carl Lobo wrote: >> Which ones are good candidates? >> - disable drop shadow >> - framerate to 25 or 24 (whar is default for movies?) > > Disabling drop shadow reduced cpu usage for me. But I had to manually > rename (could have deleted it) the module.dropshadow.cfg in both > /usr/share/enlightenment/config and //home/root/.e/e/config (or > similar). After that and restarting the xserver things cpu usage went > down to almost zero while idle. And no noticeable effect on the display either, seems it was all for nothing. Seems the can save a little space in the image by not distributing the dropshadow module. > Framerate for movies in a cinema is 25 I think. It is 24. TV is usually different. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Yorick Moko wrote: >> I (and surely others) am working on a leaner, faster theme - any >> eye-candy that distinctly impacts the user experience should NOT be >> default, and in this case we desperately need a simple and fast theme >> as the default or the immediate impression users will get is: "Damn, >> this is slow!" >> > > nice to hear that > ugly and fast beats pretty and damn slow any day for me > (pretty and fast would also be acceptable ;-)) Pretty and fast should be possible then. There is no need for multiple layers of transparent icons. They can be collapsed into one layer with a single transparent icon, looking _exactly_ the same. Effects when a icon is actually selected is another story, but that sort of thing should not need to impact scrolling. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Russell Hay wrote: > Just FYI - if you use the arrows on either end of the 'submenu' you only > get > > > "Display" "Look" "Screen" "Input" > > ...but you CAN swipe left or right across them to reveal the additional > options.. > > Damn well hidden though! Indeed. I now found the "advanced" setting. The non-functional arrows is a bug then. They did sidescroll one step but not the rest - so I was sure there wasn't any more to be found. Now I see "Language" "Advanced" "Settings" "Extensions" also! Thanks for the tip! Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
> Which ones are good candidates? > - disable drop shadow > - framerate to 25 or 24 (whar is default for movies?) Disabling drop shadow reduced cpu usage for me. But I had to manually rename (could have deleted it) the module.dropshadow.cfg in both /usr/share/enlightenment/config and //home/root/.e/e/config (or similar). After that and restarting the xserver things cpu usage went down to almost zero while idle. Framerate for movies in a cinema is 25 I think. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
> I (and surely others) am working on a leaner, faster theme - any > eye-candy that distinctly impacts the user experience should NOT be > default, and in this case we desperately need a simple and fast theme > as the default or the immediate impression users will get is: "Damn, > this is slow!" > nice to hear that ugly and fast beats pretty and damn slow any day for me (pretty and fast would also be acceptable ;-)) y ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
For those looking for the 'Advanced' settings: Grab and drag the row of icons at the top from right to left and you should find, altogether: Display Look Screen Input Language Settings Advanced Extensions AFAIK the arrows don't even work, when you tap the right-hand arrow you are effectively clicking on the edge of the 'Input' icon. BTW - the speed with which those icons scroll is how fast the main Illume icons /should/ be able to be dragged, but with the Illume theme as it currently stands (with FSO M5 and SHR at least) each 'desktop' icon is adorned with multiple transparent PNG files layered to create pretty buttons, and scrolling becomes dramatically slower than what you are probably familiar with from the base ASU theme with 2008.x. I (and surely others) am working on a leaner, faster theme - any eye-candy that distinctly impacts the user experience should NOT be default, and in this case we desperately need a simple and fast theme as the default or the immediate impression users will get is: "Damn, this is slow!" j On Mon, 23 Feb 2009 15:49:55 +0100 Yorick Moko wrote: > i have shr unstable from 09/02 > and i can confirm that there is no "advance" entry under "screen" > the top bar only shows: > "display" "look" "screen" and "input" > > I know there used to be an option to change the software rendering, > but can't find it on this image... > > y > > > On Mon, Feb 23, 2009 at 3:44 PM, Xavier Cremaschi > wrote: > >> I can hit the wrench and see: > >> > >> "Display" "Look" "Screen" "Input" > >> No "advanced" at all. > > > > You can scroll horizontally. I have lots of item in this bar in my > > SHR (unstable installed yesterday) > > > > Xavier. > > > > > > ___ > > 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
I think that framerate is for the illume and not for media players, right? Pander-2 wrote: > > Which ones are good candidates? > - disable drop shadow > - framerate to 25 or 24 (whar is default for movies?) > - > > ... > > -- View this message in context: http://n2.nabble.com/SHR-first-impression-%3A-it%27s-slow---tp2371204p2373849.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Which ones are good candidates? - disable drop shadow - framerate to 25 or 24 (whar is default for movies?) - Leonti Bielski wrote: > I'm not sure It's a good idea for everyone. > Personally I prefer SOFTWARE engine and not SOFTWARE_16 because of > quality of image. > > Leonti > > On Mon, Feb 23, 2009 at 5:40 PM, Pander wrote: >> Nicola Mfb wrote: >>> 2009/2/23, Johny Tenfinger : >>> [...] About another things - change render mode to software_16, unload drop shadow module and maybe change framerate. >>> This is becoming boring... why is it not the default? >> Could somebody please collect all these optimisations and set them in >> the configs used in the SHR and FSO build process? Thanks >> >>> Nicola >>> >>> ___ >>> 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 >> > > ___ > 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: SHR first impression : it's slow ?
I'm not sure It's a good idea for everyone. Personally I prefer SOFTWARE engine and not SOFTWARE_16 because of quality of image. Leonti On Mon, Feb 23, 2009 at 5:40 PM, Pander wrote: > Nicola Mfb wrote: >> 2009/2/23, Johny Tenfinger : >> [...] >>> About another things - change render mode to software_16, unload drop >>> shadow module and maybe change framerate. >> >> This is becoming boring... why is it not the default? > > Could somebody please collect all these optimisations and set them in > the configs used in the SHR and FSO build process? Thanks > >> >> Nicola >> >> ___ >> 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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Nicola Mfb wrote: > 2009/2/23, Johny Tenfinger : > [...] >> About another things - change render mode to software_16, unload drop >> shadow module and maybe change framerate. > > This is becoming boring... why is it not the default? Could somebody please collect all these optimisations and set them in the configs used in the SHR and FSO build process? Thanks > > Nicola > > ___ > 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: SHR first impression : it's slow ?
Just FYI - if you use the arrows on either end of the 'submenu' you only get > "Display" "Look" "Screen" "Input" ...but you CAN swipe left or right across them to reveal the additional options.. Damn well hidden though! 2009/2/23 Gunnar Aastrand Grimnes > > So I wonder - would it be safe to tell opkg about the FSO repository as > > well, and upgrade to get the newest from both places? Or will that > > likely break most of the stuff I care about, such as phone and gps > > functionality? > > I'm afraid I have no idea. Try it and see? :) > > I wonder if the illume settings can also be simply set in a config file > somewhere, or if everything is in some binary DB? > > > -- > Gunnar Aastrand Grimnes > gunnar.grimnes [AT] dfki.de > > DFKI GmbH > Knowledge Management > Trippstadter Strasse 122 > D-67663 Kaiserslautern > Germany > > Office: +49 631 205 75-117 > Mobile: +49 177 277 4397 > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Russ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
> So I wonder - would it be safe to tell opkg about the FSO repository as > well, and upgrade to get the newest from both places? Or will that > likely break most of the stuff I care about, such as phone and gps > functionality? I'm afraid I have no idea. Try it and see? :) I wonder if the illume settings can also be simply set in a config file somewhere, or if everything is in some binary DB? -- Gunnar Aastrand Grimnes gunnar.grimnes [AT] dfki.de DFKI GmbH Knowledge Management Trippstadter Strasse 122 D-67663 Kaiserslautern Germany Office: +49 631 205 75-117 Mobile: +49 177 277 4397 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Gunnar Aastrand Grimnes wrote: > The UI here is not so intuitive, but you might find that the menu bar > has arrows at the side that brings up more options? I know about those, and I need them to see the "Input" item. There is nothing more hidden to the right of that though. > in either case, the "advanced" thing is a sub menu, have you looked > under screen? "Screen" has two submenus: "Virtual Desktops" and "Screen Resolution". There is no "advanced", and there don't seem to be an "advanced" subsub-menu under the aforementioned two. > I use plain FSO, but I guess illume is the same? SHR is based on FSO. Which means that SHR took FSO at some point in time, and added SHR specific stuff. Perhaps they resynchronize now and then too - but the newest FSO may very well have something SHR haven't got yet. So I wonder - would it be safe to tell opkg about the FSO repository as well, and upgrade to get the newest from both places? Or will that likely break most of the stuff I care about, such as phone and gps functionality? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
i have shr unstable from 09/02 and i can confirm that there is no "advance" entry under "screen" the top bar only shows: "display" "look" "screen" and "input" I know there used to be an option to change the software rendering, but can't find it on this image... y On Mon, Feb 23, 2009 at 3:44 PM, Xavier Cremaschi wrote: >> I can hit the wrench and see: >> >> "Display" "Look" "Screen" "Input" >> No "advanced" at all. > > You can scroll horizontally. I have lots of item in this bar in my SHR > (unstable installed yesterday) > > Xavier. > > > ___ > 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: SHR first impression : it's slow ?
> I can hit the wrench and see: > > "Display" "Look" "Screen" "Input" > No "advanced" at all. You can scroll horizontally. I have lots of item in this bar in my SHR (unstable installed yesterday) Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
The UI here is not so intuitive, but you might find that the menu bar has arrows at the side that brings up more options? in either case, the "advanced" thing is a sub menu, have you looked under screen? I use plain FSO, but I guess illume is the same? - Gunnar Helge Hafting wrote: > Paul wrote: >>> I don't have the freerunner nearby, so I can't check where in the menu >>> you find these things, but I think the framerate is at the bottom of the >>> first menu, the drop shadow under "appearance" or similar near the end, >>> and the render engine in the advance tab of this? Can anyone confirm? >>> >> You can find both in the settings-advanced option, after hitting the wrench. > > nope - there is no such "advanced" option. > > I have shr unstable - I upgraded today (nothing new though), > I can hit the wrench and see: > > "Display" "Look" "Screen" "Input" > No "advanced" at all. > > Is there some extra package repository that all of you use, > that will bring in an enlightenment that has this "advanced" setting? > For it sure isn't in SHR unstable? > > The only extra repository I use, is opkg.org for getting > various games and utilities. > > Helge Hafting > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Gunnar Aastrand Grimnes gunnar.grimnes [AT] dfki.de DFKI GmbH Knowledge Management Trippstadter Strasse 122 D-67663 Kaiserslautern Germany Office: +49 631 205 75-117 Mobile: +49 177 277 4397 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Paul wrote: >> I don't have the freerunner nearby, so I can't check where in the menu >> you find these things, but I think the framerate is at the bottom of the >> first menu, the drop shadow under "appearance" or similar near the end, >> and the render engine in the advance tab of this? Can anyone confirm? >> > > You can find both in the settings-advanced option, after hitting the wrench. nope - there is no such "advanced" option. I have shr unstable - I upgraded today (nothing new though), I can hit the wrench and see: "Display" "Look" "Screen" "Input" No "advanced" at all. Is there some extra package repository that all of you use, that will bring in an enlightenment that has this "advanced" setting? For it sure isn't in SHR unstable? The only extra repository I use, is opkg.org for getting various games and utilities. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
2009/2/23, Johny Tenfinger : [...] > About another things - change render mode to software_16, unload drop > shadow module and maybe change framerate. This is becoming boring... why is it not the default? Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
On Mon, Feb 23, 2009 at 10:14, Xavier Cremaschi wrote: > I have some problems with : > 1. wifi : Wifi Mofi hangs when I run it > 2. gps : GPS cannot fix > 3. SHR Panels : some panels in 'Settings' hang when I click on them > (GSM/operators for example) > 4. Everything is slow 1. Turn on WiFi in shr-settings before starting Mofi. 2. Look at "possible reasons of non-working gps" (or something like that) topic ;) 3. Upgrade, upgrade, upgrade, upgrade! "Operators" was FSO bug - now it's working, and calling it is asynchronous. 4. About shr-settings slowness: upgrade, upgrade, upgrade, upgrade! About another things - change render mode to software_16, unload drop shadow module and maybe change framerate. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
Ah - what I forgot to mention is that this brought illume down to about 5-8% - which is ok-ish, but not great when it's idle and really just sitting there. The rasterman has previously said it has been at about 0.2% when idle. Also, there is a ticket for this: http://shr.bearstech.com/trac/ticket/298 - Gunnar Paul wrote: >> I don't have the freerunner nearby, so I can't check where in the menu >> you find these things, but I think the framerate is at the bottom of the >> first menu, the drop shadow under "appearance" or similar near the end, >> and the render engine in the advance tab of this? Can anyone confirm? >> > > You can find both in the settings-advanced option, after hitting the wrench. > advanced - performance for the framerate > advanced - engine for the software-engine. > It also pays to switch off the animations for things: > display-Animations. > > Paul > -- Gunnar Aastrand Grimnes gunnar.grimnes [AT] dfki.de DFKI GmbH Knowledge Management Trippstadter Strasse 122 D-67663 Kaiserslautern Germany Office: +49 631 205 75-117 Mobile: +49 177 277 4397 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
> I don't have the freerunner nearby, so I can't check where in the menu > you find these things, but I think the framerate is at the bottom of the > first menu, the drop shadow under "appearance" or similar near the end, > and the render engine in the advance tab of this? Can anyone confirm? > You can find both in the settings-advanced option, after hitting the wrench. advanced - performance for the framerate advanced - engine for the software-engine. It also pays to switch off the animations for things: display-Animations. Paul -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -Abraham Lincoln http://www.nlpagan.net Running on Mandriva Linux 2009 and Ubuntu 8.10 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
This is apparently an issue with recent SHR/FSO, my not quite perfect fix was to go into the illume settings thingy (i.e. the wrench menu) and set the framerate to 5 rather than 30, turn off drop shadows, and to change the render mode from software to software_16. I don't have the freerunner nearby, so I can't check where in the menu you find these things, but I think the framerate is at the bottom of the first menu, the drop shadow under "appearance" or similar near the end, and the render engine in the advance tab of this? Can anyone confirm? - Gunnar Xavier Cremaschi wrote: > Hi folks, > > I ruined my OM2008.12 yesterday, trying to put some bad libc6 for > mozilla-fennec. > So I told myself "let's try this SHR everybody is talking about" > > > I have some problems with : > 1. wifi : Wifi Mofi hangs when I run it > 2. gps : GPS cannot fix > 3. SHR Panels : some panels in 'Settings' hang when I click on them > (GSM/operators for example) > 4. Everything is slow > > For 1 to 3 I hope I will find a solution by investigating a bit more, > but these things worked 'as if' with OM2008.12 so I was a bit > disappointed... so many people write "SHR unstable is very stable", but > I find OM2008.12 to be far more stable... > Maybe something is wrong with my install, I don't know. > > For 4 I would need your help, enlightenment eats lots of kernel time in > htop (cpu and memory are still ok), it was 15:00.00 the last time I > checked. I need 2-3 seconds to scroll on desktop, while in enlightement > settings panel (aka the wrench) it is fluid. > > Does anybody have an idea for 4. ? > > Best regards, > Xavier Cremaschi. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Gunnar Aastrand Grimnes gunnar.grimnes [AT] dfki.de DFKI GmbH Knowledge Management Trippstadter Strasse 122 D-67663 Kaiserslautern Germany Office: +49 631 205 75-117 Mobile: +49 177 277 4397 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
SHR first impression : it's slow ?
Hi folks, I ruined my OM2008.12 yesterday, trying to put some bad libc6 for mozilla-fennec. So I told myself "let's try this SHR everybody is talking about" I have some problems with : 1. wifi : Wifi Mofi hangs when I run it 2. gps : GPS cannot fix 3. SHR Panels : some panels in 'Settings' hang when I click on them (GSM/operators for example) 4. Everything is slow For 1 to 3 I hope I will find a solution by investigating a bit more, but these things worked 'as if' with OM2008.12 so I was a bit disappointed... so many people write "SHR unstable is very stable", but I find OM2008.12 to be far more stable... Maybe something is wrong with my install, I don't know. For 4 I would need your help, enlightenment eats lots of kernel time in htop (cpu and memory are still ok), it was 15:00.00 the last time I checked. I need 2-3 seconds to scroll on desktop, while in enlightement settings panel (aka the wrench) it is fluid. Does anybody have an idea for 4. ? Best regards, Xavier Cremaschi. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community