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 speed of the jvm. it's 40x faster
than
python. 20x faster than perl or
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Mon, 02 Mar 2009 11:44:12 +0100 Helge Hafting helge.haft...@hist.no 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 launcher's icon collection is a specific case though. The icons seem to be static,
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Tue, 3 Mar 2009 00:44:01 +1100 Carsten Haitzler (The Rasterman) ras...@rasterman.com (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, 2 Mar 2009 20:01:51 +0100 Petr Vanek van...@penguin.cz said: On Tue, 3 Mar 2009 00:44:01 +1100 Carsten Haitzler (The Rasterman) ras...@rasterman.com (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 ?)
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: 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 Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting helge.haft...@hist.no said:
Joel Newkirk wrote:
On Wed, 25 Feb 2009 12:43:59 +0100
Helge Hafting helge.haft...@hist.no 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 to date those
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Wed, 25 Feb 2009 23:43:00 -0500 Joel Newkirk freerun...@newkirk.us said:
On Wed, 25 Feb 2009 12:43:59 +0100
Helge Hafting helge.haft...@hist.no 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, it gets the glass
effect. It appear with a slight delay, but there is
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 Fri, Feb 27, 2009 at 11:35 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting helge.haft...@hist.no 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: 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: SHR first impression : it's slow ?
On Fri, Feb 27, 2009 at 21:26, Marco Trevisan (Treviño) m...@3v1n0.net 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 ?
2009/2/27, Johny Tenfinger seba.d...@gmail.com: On Fri, Feb 27, 2009 at 21:26, Marco Trevisan (Treviño) m...@3v1n0.net 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: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Fri, 27 Feb 2009 15:13:39 -0300 robert lazarski robertlazar...@gmail.com said: On Fri, Feb 27, 2009 at 11:35 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Thu, 26 Feb 2009 11:31:43 +0100 Helge Hafting helge.haft...@hist.no 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: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Fri, 27 Feb 2009 17:16:39 +0100 Flemming Richter Mikkelsen quat...@gmail.com 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: 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: 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 ?
On Thu, Feb 26, 2009 at 10:49, Pander pan...@users.sourceforge.net 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 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: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Joel Newkirk wrote:
On Wed, 25 Feb 2009 12:43:59 +0100
Helge Hafting helge.haft...@hist.no 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: 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 helge.haft...@hist.no 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 ?)
On Thu, 26 Feb 2009 11:31:43 +0100
Helge Hafting helge.haft...@hist.no wrote:
Joel Newkirk wrote:
On Wed, 25 Feb 2009 12:43:59 +0100
Helge Hafting helge.haft...@hist.no 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-dialer and kin, paroli, Raster's alarm, shr-config,
etc all use
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
2009/2/26 Helge Hafting helge.haft...@hist.no:
Joel Newkirk wrote:
On Wed, 25 Feb 2009 12:43:59 +0100
Helge Hafting helge.haft...@hist.no 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. (Illume in
our case) It also uses 'pager_base2.png' which is defined in a
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 ?)
Joel Newkirk wrote: On Wed, 25 Feb 2009 09:19:37 +0800 HouYu Li kara...@gmail.com 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: GUI responsiveness (was Re: SHR first impression : it's slow ?)
Joel Newkirk wrote: On Tue, 24 Feb 2009 12:32:09 +0100 Helge Hafting helge.haft...@hist.no 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: 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: SHR first impression : it's slow ?
On Wed, Feb 25, 2009 at 12:50, Helge Hafting helge.haft...@hist.no 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 ?
On Wed, 25 Feb 2009 13:10:12 +0100 Johny Tenfinger seba.d...@gmail.com (JT) wrote: On Wed, Feb 25, 2009 at 12:50, Helge Hafting helge.haft...@hist.no 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 13:18, Petr Vanek van...@penguin.cz 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:24:18 +0100 Johny Tenfinger seba.d...@gmail.com (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 ?
Finally I found a repo with working links-x11! Dziękuję indeed. On Wed, Feb 25, 2009 at 2:25 PM, Petr Vanek van...@penguin.cz wrote: On Wed, 25 Feb 2009 13:24:18 +0100 Johny Tenfinger seba.d...@gmail.com (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 ?
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: GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Wed, 25 Feb 2009 12:43:59 +0100
Helge Hafting helge.haft...@hist.no 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 looking forward to see all this. :-) It should definitely
improve the user
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 ?
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 ?
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 ?
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
GUI responsiveness (was Re: SHR first impression : it's slow ?)
On Tue, 24 Feb 2009 12:32:09 +0100 Helge Hafting helge.haft...@hist.no 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 ?
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
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 freerun...@newkirk.us wrote: On Tue, 24 Feb 2009 12:32:09 +0100 Helge Hafting helge.haft...@hist.no 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 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 ?)
On Wed, 25 Feb 2009 09:19:37 +0800 HouYu Li kara...@gmail.com 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
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
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
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 ?
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 ?
On Mon, Feb 23, 2009 at 10:14, Xavier Cremaschi omega.xav...@gmail.com 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 ?
2009/2/23, Johny Tenfinger seba.d...@gmail.com: [...] 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 ?
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 ?
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 ?
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 ?
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 omega.xav...@gmail.com 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 ?
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 ?
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 ?
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 gunnar.grim...@dfki.de 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 ?
Nicola Mfb wrote: 2009/2/23, Johny Tenfinger seba.d...@gmail.com: [...] 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 ?
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 pan...@users.sourceforge.net wrote: Nicola Mfb wrote: 2009/2/23, Johny Tenfinger seba.d...@gmail.com: [...] 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 ?
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 pan...@users.sourceforge.net wrote: Nicola Mfb wrote: 2009/2/23, Johny Tenfinger seba.d...@gmail.com: [...] 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 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 ?
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 yorickm...@gmail.com 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 omega.xav...@gmail.com 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 (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
