Re: Centralization of graphical awesomeness
On Wed, Oct 28, 2009 at 08:45:08PM +0300, Paul Fertser wrote: Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. Following the instructions in this thread gives me a somewhat graphically intact screen. But the touchable area is -- like stated before -- reduced to the upper left quarter of the screen. But this quarter scales to the whole screen: touching upper left corner is a click in the upper left corner, touching the lower right corner of the upper left quarter results in a click on the lower right corner of the whole screen. Is this the problem with the touchscreen driver mentioned by Raster? And how could this be resolved? I still consider speed one of the usability issues of the FR. And I think it is responsiveness shiny things. ;-) pgpzz9EqQ3Gyf.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On 11/4/09, Ole Kliemann ole-om-community-2...@mail.plastictree.net wrote: On Wed, Oct 28, 2009 at 08:45:08PM +0300, Paul Fertser wrote: Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. Following the instructions in this thread gives me a somewhat graphically intact screen. But the touchable area is -- like stated before -- reduced to the upper left quarter of the screen. But this quarter scales to the whole screen: touching upper left corner is a click in the upper left corner, touching the lower right corner of the upper left quarter results in a click on the lower right corner of the whole screen. Is this the problem with the touchscreen driver mentioned by Raster? And how could this be resolved? I still consider speed one of the usability issues of the FR. And I think it is responsiveness shiny things. ;-) If you're using Xglamo, then it's known and it's already fixed in Xorg. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, Nov 04, 2009 at 03:41:47PM +0100, Sebastian Krzyszkowiak wrote: On 11/4/09, Ole Kliemann ole-om-community-2...@mail.plastictree.net wrote: On Wed, Oct 28, 2009 at 08:45:08PM +0300, Paul Fertser wrote: Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. Following the instructions in this thread gives me a somewhat graphically intact screen. But the touchable area is -- like stated before -- reduced to the upper left quarter of the screen. But this quarter scales to the whole screen: touching upper left corner is a click in the upper left corner, touching the lower right corner of the upper left quarter results in a click on the lower right corner of the whole screen. Is this the problem with the touchscreen driver mentioned by Raster? And how could this be resolved? I still consider speed one of the usability issues of the FR. And I think it is responsiveness shiny things. ;-) If you're using Xglamo, then it's known and it's already fixed in Xorg. I see. Well... how do I get Xorg then? ;-) I am using the latest SHR-unstable image with latest updates from the feeds. I cannot find Xorg in the unstable feeds. I read that it was so far only integrated into some other branch of SHR? But I cannot find anything more recent than the unstable, although it hasn't been updated for over a month now as far as I can see. pgpy6J4a8A12a.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, Nov 04, 2009 at 05:16:08PM +, Ole Kliemann wrote: If you're using Xglamo, then it's known and it's already fixed in Xorg. I see. Well... how do I get Xorg then? ;-) I am using the latest SHR-unstable image with latest updates from the feeds. I cannot find Xorg in the unstable feeds. I read that it was so far only integrated into some other branch of SHR? But I cannot find anything more recent than the unstable, although it hasn't been updated for over a month now as far as I can see. It's being merged, it would seem that it's really close now, though :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Evgeniy Karyakin wrote: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of data flowing through it? Sure you can lower the amount of data flowing through it. Lowering the resolution is one option that several has mentioned. Another way is to draw less stuff overall: * Don't draw anything that need several passes, i.e. transparency * Don't draw anything unnecessary, i.e. cute animations * Don't ecen think of 3D. * Optimize the user interface. Never redraw the screen when drawing a smaller portion will suffice. Don't highlight an icon by changing the background color. (Lots of pixels).- Just draw a 1-pixel wide square around it, for example. (And make sure your drawing library doesn't do anything excessive behind your back, such as drawing the entire icon with that border - because that was simpler to implement. The situation is not hopeless. The entire 640x480 16-bit display is 614400 byte, or 0.6MB. 7MB/s means the entire display can be updated 11 times per second if need be. In theory, anyway. Anything updating a smaller portion of the screen could be even more responsive. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 02 Nov 2009 14:26:24 +0100 Helge Hafting helge.haft...@hist.no said: Evgeniy Karyakin wrote: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of data flowing through it? Sure you can lower the amount of data flowing through it. Lowering the resolution is one option that several has mentioned. Another way is to draw less stuff overall: * Don't draw anything that need several passes, i.e. transparency * Don't draw anything unnecessary, i.e. cute animations * Don't ecen think of 3D. * Optimize the user interface. Never redraw the screen when drawing a smaller portion will suffice. Don't highlight an icon by changing the background color. (Lots of pixels).- Just draw a 1-pixel wide square around it, for example. (And make sure your drawing library doesn't do anything excessive behind your back, such as drawing the entire icon with that border - because that was simpler to implement. The situation is not hopeless. The entire 640x480 16-bit display is 614400 byte, or 0.6MB. 7MB/s means the entire display can be updated 11 times per second if need be. In theory, anyway. Anything updating a smaller portion of the screen could be even more responsive. 11 fps assumes zero cpu left to actually do the drawing. -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Carsten Haitzler (The Rasterman) schrieb: On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. why do you think so ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
2009/10/31 Carsten Haitzler ras...@rasterman.com you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. What's the pressure level? Is it in the the hardware? Is it possible to adjust it? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 09:34:17 +0100 Laszlo KREKACS laszlo.krekacs.l...@gmail.com said: On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. no you didnt. your stroke would go from the dotty broken one to a continuous one - like your finger actually traced on the screen. the sensors just didnt pick it up. -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 09:21:13 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Carsten Haitzler (The Rasterman) schrieb: On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. and that's what i told you e and elementary have too. the problem is your finger moves the entire length of that line. the actual input events you see are the discontinuous stutters as above. see the + by itself? that's a press +release on the same spot. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. that's what i said... and it should be done in tslib/x - every toolkit and app should not have to go implement this again and again. the lower layers should sanitise input by the time it gets to x clients. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. well not wm. wm's dont intercept or modify events in any way. each x app (the wm, or the app listening to the events on the window where the events are going) gets them. so the choice is. 1. every toolkit+app does it (every game using sdl, every GL app (tho this is hypotherical - this is just the general case, not gta02), elementary, e, gtk, qt - they all need to repeat the same logic to filter these. elementary and e have logic to know the difference between a tap and a drag. the values are configurable and tunable. the problem is all the dirty input. -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 11:38:59 +0100 Michal Brzozowski ruso...@poczta.fm said: 2009/10/31 Carsten Haitzler ras...@rasterman.com you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. What's the pressure level? Is it in the the hardware? Is it possible to adjust it? nothing in software i have seen. if it was possible it would have been adjusted long ago... the driver already has code to de-jitter the input (smooth it out) it may as well de-jitter the temporal information too. -- - 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: Centralization of graphical awesomeness
Am Mittwoch, den 28.10.2009, 09:36 -0400 schrieb Ken Young: Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
2009/10/29 Ken Young r...@cfa.harvard.edu: 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. no. you're right, the fr has one feature better than any other smartphone, but it's not the screen. it's not any of the hardware, it's far more important than that it's the openness give the user a choice, let them decide if they want pixels or speed. that's what open is about ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Michael 'Mickey' Lauer schrieb: , since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. when i understand you right, you think, the dbus concept is wrong ? and if so, could you please explain deeper, why you think so ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Fri, 2009-10-30 at 16:18 +0100, Matthias Huber wrote: Michael 'Mickey' Lauer schrieb: , since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. when i understand you right, you think, the dbus concept is wrong ? and if so, could you please explain deeper, why you think so ? I think it's just the reverse: he saw too late that dbus is really good. Xav ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... How lucky you are ! I still wonder why dbus was invented in the first place :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Am Freitag, den 30.10.2009, 16:36 +0100 schrieb ri...@happyleptic.org: You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... How lucky you are ! I still wonder why dbus was invented in the first place :-) Hehe, coming from a strong background in CORBA on one hand, but pure bare-metal unix domain socket IPC on the other hand, I have to admit that while dbus lacks a lot, it * (pretty much) ends the horror of proprietary IPC protocols, thus * enabling interconnecting components, hence * bringing interoperability. * It also comes with an interactive scripting console (read: Python). And that's what I'm all glad for. But now we went really off topic considering the original thread :) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ if you dont press firmly with a sharp point (stylus, fingernail etc.). you can go to every app and start trying to add filtering to close such gaps, but now you duplicate that code everywhere. IMHO tslib/x should filter it so the input to clients is the intended input by the user. also you will have unintended clicks (drawing press/release over time): + +-+ +-+ you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. imho there should be some filtering on the input events that patches these gaps. and that filtering should go in x or tslib. capacitivie screens are much more sensitive and have a different problem - but their events are filtered too as you dont get a point - you get an area that is pressed, so they have a hysterisis on how big the area has to be first to start a press registering and then it has to get much smaller that this area to stop. eg: press start @ 8x8 pixels, press stop at 3x3 pixels. as long as your press area, once registered, is 3x3 pixels, it will continue to be pressed until it gets below. -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 20:42:16 +1100 Carsten Haitzler (The Rasterman) ras...@rasterman.com (CH(R) wrote: On Wed, 28 Oct 2009 11:27:03 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de said: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? good words mickey. good words. :) (i have a todo item for the scrole rto have a page mode. it already has a page mode actually - but its a scrolling one much like iphone's N pages of icons - but it's infra to simple provide some theme elements that you press and they jump up/down/left/right a page and then do the jump - so it's mostly there. it just hasn't been any priority for me - am working on an oldie request to get rotatable objects.. which now works. under flux.. but works and renders... image and text objects so far are working. in theory all other basic object types too, but smart objects - not yet). While i agree i still wonder. i tried latest android on freerunner yesterday - most scrolling nice and smooth. had qtmoko on last week - the same (yes, i read the explanation why it works, but it works). now, in order not to put anybody down, i must say that for example scrolling in shr contact list IS smooth. so my question is: where exactly do we have scrolling issues? think about it. Then i tend to think about the Illume desktop, that is so much unfriendly to scrolling. Raster, i meant to ask before but had no time: if we take etk toolkit and E window manager as for granted for SHR (hopefully with some choices, but still), is there any other desktop module we could use instead of Illume? In your no-speak project, is there anything being developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? Thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Petr Vanek wrote: lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:37:06 +0100 Petr Vanek van...@penguin.cz said: @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... i have been trying gry* lately and more less like it. btw can you already change the background image in Illume settings? i still get the Enlightenment was unable to import the image due to conversion errors ? u are probably missing edje_cc from the distro -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:12:29 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Petr Vanek wrote: lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you 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 -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
CH(R btw can you already change the background image in Illume settings? i CH(R still get the Enlightenment was unable to import the image due to CH(R conversion errors ? CH(R CH(R u are probably missing edje_cc from the distro thanks, this was it. i have already reported it distro maintainers. Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Carsten Haitzler (The Rasterman) wrote: gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. rater, would you mind to elaborate? (is outline the fastest effect if you want to enable the user to set a custom background while maintaining the labels readable?) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
2009/10/28 Michael 'Mickey' Lauer mic...@vanille-media.de: Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? Excellent idea. Certainly as far as the Illume launcher is concerned, I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same and as for switching between apps. (i.e. each icon page acts like another app) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, Oct 29, 2009 at 4:46 PM, Neil Jerram neiljer...@googlemail.com wrote: I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same and as for switching between apps. (i.e. each icon page acts like another app) To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app 2. sliding left/sliding right would change the current page. I would also suggest different background image for each virtual desktop. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 2009-10-28 at 12:51 +0100, DJDAS wrote: otherwise I would by an HTC with Android if I only wanted a Linux-phone carefull...everything is non-standard Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, Oct 28, 2009 at 5:44 AM, ri...@happyleptic.org wrote: Reading an ebook or looking a webpage or a map is better with scrolling I guess. I've been using my FR with ePdfView to read books quite a bit lately, and I always read a full screen of text and then click on the scrollbar to move to the next screen of text. I find it hard to track text on the screen if you are continuously scroll - I think paging is a much better metaphor, at least for ebook reading. A map might be one situation where incremental scrolling is better than paging - I certainly use it a lot on my desktop when using google maps, for instance. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: On Thu, Oct 29, 2009 at 4:46 PM, Neil Jerram neiljer...@googlemail.com wrote: I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same and as for switching between apps. (i.e. each icon page acts like another app) To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. 2. sliding left/sliding right would change the current page. I would also suggest different background image for each virtual desktop. sliding between desktops is very interesting for me too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 15:38:46 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Carsten Haitzler (The Rasterman) wrote: gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. rater, would you mind to elaborate? (is outline the fastest effect if you want to enable the user to set a custom background while maintaining the labels readable?) yes, but it's still 5x slower to draw than no outline. a suggestion: just put a semi-translucent black box under the text and have white test. this will be readable everywhere and be fastest. -- - 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: Centralization of graphical awesomeness
-[ Tue, Oct 27, 2009 at 04:42:21PM +1100, Carsten Haitzler ] but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. It might be dead, but as there is no other free phone I have no choice but to use this one. I can live without fancy graphics anyway (although I can remember a time when I was coding 3d eye candy on much less powerfull hardware, but that's another story). it has no evolution path. You seam to consider gta03 community project as unable to produce anything ? I don't think so. you don't build your world around your first bit of hardware. (...) most games i know of are written to work on the highest end graphics cards at the time. why? by the time the game is out and is selling - everyone has finally upgraded to those cards. We are dealing with 2 different ideas here I believe : what hardware you target when you plan the feature of a future product, and what hardware is required to run a given set of features. You designed E to give good results on bigger hardware (due to the ambitious theme engine if I understood correctly) ; and I believe you that it's probably honestly optimised. You targeted more capable hardware when designing E and I believe it was probably the good choice ! For instance, if I were designing a rendering toolkit now I would certainly not consider anything but OpenGl capable hardware :) I've seen E at work on bigger hardware too, and it seamed allright. The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. Kindly, ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
Carsten Haitzler (The Rasterman) wrote: with linux i'm not lumping in uclinux, elks, etc. as they do come under different names :) notice.. i included desktop... and at least i'd hope to imply that would be the desktop he speaks of... ie how great compiz is and so much better than e17. :) (just using context). Please don't lock on my comparing E vs. Compiz, it was just an example to show how things could be done in different manner, the same as you don't consider uclinux as linux... I didn't say Compiz is better than E per se, I just said on *my* desktop systems E never run as smooth as you claim (and show on your videos) BUT Compiz do. Given that I don't use compiz because simply I don't need fancy windows to browse the web, developing apps and see movies ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. my 2 cents: we can have lighter themes in E (as for example gry is, thanks the author for that!), but then need to have the X11-16 working - at this point, it has been recommended by Raster not to use it and even the new SHR phoneui apps cannot work with X11-16. So we are going back to the even slower engine. Could this be looked at and revised? We need X11-16 for the Freerunner, the 32bit rendering is way too slow on Freerunner. Illume is absolutely unmaintained - as Raster pointed, it hasn't been actively touched for a long time. Please see list of Illume immediate issues [1]. Raster, are you using Illume yourself somewhere? Could Illume get some attention? Otherwise it's going to die with the Freerunner users getting another phones (Pré etc). As i see it, if the above will not happen, users will slowly drift away to solution perhaps not so optimized but feeling lighter and maintained. So the wish for E being THE toolkit for mobile devices will disappear. And we can see this already. SHR has been asked several times for more options in window managers. And as SHR has no manpower to provide this, Debian might start gaining attention, proper deb packaging of FSO will help this a lot. Petr [1] http://wiki.openmoko.org/wiki/Illume#Issues ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: well.. you're telling the one that wrote the graphics code, that has read the glamo hw docs, has worked on it long before freerunner was on sale, who has written graphics code for many platforms, manye cpus of many varying levesl of speed (from 7mhz 68k up), many gpu's from old console hardware to 3d gl... that he's talking bullshit (and being very rude about it, providing no evidence, numbers or anything else to back anything you say up) about exactly the things he's deeply involved in. thus.. you must be an expert beyond my experience and abilites. No and...NO I said I read too much bull**it regarding the approach used when users complains about graphic speed. I didn't say you are a liar or incompetent just your system is not the one, there are many different choices so if another system is faster than yours MAYBE there should be a reason and obviously it's not only Glamo issue. You said E does many more calculations than Qt not me so I simply pointed this doesn't mean me (as a user) MUST accept perfect-fancy-heavy background calculations at the cost of speed and responsiveness. And for this I pointed (yes I was rude but 2 years of the same shut-up you bought a looser device so don't complain messages altered my patience ;) ) that your approach of porting a desktop system to an embedded one it's not as easy as ./configure make make install cross compiling.and for this I talked as a bit competent in embedded devices (not on graphics) development. As a GUI designer and technician you should very well know users perceive responsiveness and usability not background calculation so *seeing from the end user point of view* I can tell Qt is way far faster than E (even if it does less things...) if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... i have been factual, realistic and constructive. i have stated that freerunner is a limited platform. it's one of the slowest (if running at its native resolution i have ever worked on, and i've worked on a fair few. Several months ago I saw a rootfs image you provided as a proof-of-concept of you new gadgets (clock, buttons) and keyboard (IIRC) why simply you didn't ever provide a rootfs with a 240x320 configured screen to show the 4x speed enhancement? I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) ... the users and developers that insist on vga, that they are paying a high price for their insistence. the hardware simply wasnt designed to be optimal on vga. trust me. i've read the glamo docs. vga is the top LIMIT of its capabilities. it's being stretched. these developers ALSO decide the themes they use as part of building SHR for example. the default is a generic default - it's not tuned for really slow systems. Why don't you? You are the only one (and I sincerely believe this) who can know how to optimize things, why don't you show users what they can do instead of telling it's limited, stop? as for e17 not runing on any desktop acceptably. i really have to laugh at that, as i have had it run acceptably on an hp mini-note 2133. 1 ghz via c3. really slow. e is just fine on it. just compile and run. compiz doesn't even start on it. so don't get me started in how wrong you are there. e runs on beagleboards (omap3 - 600mhz) just fine. this is roughly an equivalent machine to the netbook (give or take). I'll send you my desktop PC :P it is all factual and based on imperative results and engineering work. not being an it manager and being rude. you have implicitly called me a liar and have also implicitly claimed i know not of what i speak. No, please read my previous posts, I claimed your approach to end users complaints is of closure. Sorry if you interpreted this as a personal offense. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Xavier :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 28 Oct 2009 10:09:36 +0100 Petr Vanek van...@penguin.cz said: As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. my 2 cents: we can have lighter themes in E (as for example gry is, thanks the author for that!), but then need to have the X11-16 working - at this point, it has been recommended by Raster not to use it and even the new SHR phoneui apps cannot work with X11-16. So we are going back to the even slower engine. you dont need it for lighter themes to work. it wont have as good an effect though. but see below. Could this be looked at and revised? We need X11-16 for the Freerunner, the 32bit rendering is way too slow on Freerunner. i'm not going to do anything to the 16bit engine. why? it's 100% parallel code to the 32bit. and it's more work to do it as the format is more complex. every operation is in 16bit or 16bit + alpha plane mask. it doubles maintenance work. i have enough work just making 1 engine fast and maintaining accelerated engines (xrender, gl, ...). :( 32bit engine is much mroe stable and more capable. it is slower. but unless someone steps up to the plate and does the work, it's not going to get done. 16bit engine was never complete from the start, as it was written to make 1 specific app fast, and only what it used was implemented. Illume is absolutely unmaintained - as Raster pointed, it hasn't been actively touched for a long time. Please see list of Illume immediate issues [1]. correct. as it simply hasnt been on a list of priorites in the last year. it's far backburner stuff :) Raster, are you using Illume yourself somewhere? Could Illume get some attention? Otherwise it's going to die with the Freerunner users getting another phones (Pré etc). no it isn't :) trust me on that one. :) nothing to do with freerunner. as for illume - i am not using it. there is an illume2 module in svn that is a skeleton rewrite that just does window arrangement in a very primitive way right now. i don't have time to work on it right now either. As i see it, if the above will not happen, users will slowly drift away to solution perhaps not so optimized but feeling lighter and maintained. So the wish for E being THE toolkit for mobile devices will disappear. And we can see this already. SHR has been asked several times for more options in window managers. And as SHR has no manpower to provide this, Debian might start gaining attention, proper deb packaging of FSO will help this a lot. from that point of view... i'll disagree. you'll know why at some point. :) it'd love to chat about it... but i can't. :( Petr [1] http://wiki.openmoko.org/wiki/Illume#Issues ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 11:27:03 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de said: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? good words mickey. good words. :) (i have a todo item for the scrole rto have a page mode. it already has a page mode actually - but its a scrolling one much like iphone's N pages of icons - but it's infra to simple provide some theme elements that you press and they jump up/down/left/right a page and then do the jump - so it's mostly there. it just hasn't been any priority for me - am working on an oldie request to get rotatable objects.. which now works. under flux.. but works and renders... image and text objects so far are working. in theory all other basic object types too, but smart objects - not yet). -- - 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, Oct 28, 2009 at 10:27 AM, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? Or discrete scrolling. (ie. only scroll by lets say 48px height). Also text only scrolling would be useful to speed up. (most of our scrolling happens on the text). Or dont load the whole text only the first 20 lines of it, and when you hit at the bottom, load the rest of the text. (Im implementing this approach, and I expect better speed of this *workaround* then what elementary provides by default) I do believe that scrolling can be speedup. Especially for texts. I also think that a zoom in/zoom out interface can be also speedier than what the current scrolling is. Ie.you zoom out the texts, and zoom in the other part of it... What I think our hardware shows really its limitation is the animations. But I dont think scrolling falls in that category. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
-[ Wed, Oct 28, 2009 at 11:27:03AM +0200, Michael 'Mickey' Lauer ] [scrolling] There are other metaphors available that would fit the device's strengths much better. What about paging? Reading an ebook or looking a webpage or a map is better with scrolling I guess. Apart from that, you are right that paging is easier than scrolling for the hardware and for the user as well (scrolling with a finger is fun but not very precise nor fast - I remember having difficulties with H1 scrolling application list, looking for tangogps ; it requires too much attention, especially while driving :)...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Xavier :) Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS a écrit : Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Bye. No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? That as Raster correctly said, default is something that should do everything as-best-as-possible, and default in all E distros is a pain-in-the-a** This is a distro maintainer issue ok but remember I'm talking from the user's point of view and from this point of view it's a matter of E not distro maintainer configuration (given both distros suffer the same problem). And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
This discussion is _very very_ interesting! And for sure we'll have progress... quote: if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... OK, we -as freerunner users- have a lot of patience, we'll see (we need manpower (community power)! wtf!). d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 28 Oct 2009 11:15:46 +0100 Davide Scaini dsca...@gmail.com said: This discussion is _very very_ interesting! And for sure we'll have progress... quote: if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... hehehe :) OK, we -as freerunner users- have a lot of patience, we'll see (we need manpower (community power)! wtf!). d indeed. indeed. :) -- - 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: Centralization of graphical awesomeness
On Wed, Oct 28, 2009 at 11:00 AM, DJDAS dj...@djdas.net wrote: Xavier Cremaschi wrote: DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. -- Cedric BAIL ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Cedric BAIL wrote: Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). I don't have time too!!! I don't want to write a theme that REMOVES ALL THE FUNCY STUFF! I'd like (did I ever say that?) AS AN END USER to have something by default that demonstrates its capabilities. And at the moment it simply doesn't! As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience. If you are happy to be fooled after believing in this fantastic project, spending money, spending a lot of time you are welcome, I don't and I'll look for everything doable to make this device (and if ever will be another one in the future) better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
-[ Wed, Oct 28, 2009 at 11:38:22AM +0100, DJDAS ] Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience (...) and I'll look for everything doable to make this device (and if ever will be another one in the future) better. Yet somehow tuning illume theme seams too much ? :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, Oct 28, 2009 at 11:38 AM, DJDAS dj...@djdas.net wrote: Cedric BAIL wrote: Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). I don't have time too!!! I don't want to write a theme that REMOVES ALL THE FUNCY STUFF! I'd like (did I ever say that?) AS AN END USER to have something by default that demonstrates its capabilities. And at the moment it simply doesn't! So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. Choice has been make that people prefer fancy stuff over speed, and you are one of them apparently, so the compromise make sense. If you want better perf, switch to another theme and E will feel faster. As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience. If you are happy to be fooled after believing in this fantastic project, spending money, spending a lot of time you are welcome, I don't and I'll look for everything doable to make this device (and if ever will be another one in the future) better. You don't want to solve the problem. You want the world to be like you dream it. But this hardware has limitation that you should take into account, if you don't, you will wast your energy and the energy of others for nothing. And yes, it costs to accept that the hardware we have is not as powerfull as we would like it to be. And yes, it costs to accept compromise. Welcome to the real world. So now, I ask you, what do you propose ? At least raster give you a few possibility. -- Cedric BAIL ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Cedric BAIL wrote: So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. That's exactly what I said in my previous post it's not me that is saying E is the best piece of software, all the others are sh*t and I'm not crying, I worked to optimize my personal distribution based on an old FDOM and it's quite responsive and daily since september 2008, I try always to optimize things and some time share my knowledge with other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Did you see any other posts from me crying my FR is slow and unstable and unresponsive and shi**y and so on? No! I simply wrote yesterday because I saw since last year only messages like you have a bad hardware so what you want? and I don't think it's a good promotion to achieve new customers or developers to the community...so if you tell me that this is the approach I take it on account and will do my work for myself not trying to share my knowledge with a community which rounds only around Raster and SHR like Gods I want to be proactive not simple yell, but I see only people who say Raster is right not trying to study or thinking in a different way... Can you point me at someone who is different from this approach? Choice has been make that people prefer fancy stuff over speed, and you are one of them apparently, Maybe you missed my previous posts, I said exactly the opposite: I don't NEED nor want fancy stuff at the price of speed this is why I don't consider E *FOR ME* a good piece of softwarebecause I prefer to have something responsive and written to be to, especially if its aimed at an embedded device with low capabilities (in general but especially the FR). You don't want to solve the problem. You want the world to be like you dream it. I want a world in which a community shares its thoughts and discovers, not a community which depends on 3-4 people who say I'm right you're wrong, stop! and think them as God in EarthPassiveness is bad, EVER! But this hardware has limitation that you should take into account, if you don't, you will wast your energy and the energy of others for nothing. And yes, it costs to accept that the hardware we have is not as powerfull as we would like it to be. And yes, it costs to accept compromise. Welcome to the real world. I perfectly know this and if you read carefully my previous posts you see exactly what you're writing So now, I ask you, what do you propose ? At least raster give you a few possibility. I'm not a graphic expert, I'm trying to test some stuffs and looking for alternatives, when I'll reach a milestone if you'll be interested I'll share my thoughts... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) So why don't we talk about future? What are we going to do with our brick? d ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Davide Scaini wrote: DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Simply because ATM our work (it's not ONLY mine but we are a team of about 10 people) it's not more than a simple prototype, we are hardly working but obviously in our spare time so we prefer to achieve almost an alpha stage before sharing our ideas ;) they're too much a WIP... Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) I'm too interested in what works but more in what we can do to let it work better, it's not a competition, it's a matter of research, sharing ideas and propose, not stopping at what we have here, whining and nothing more (otherwise I would by an HTC with Android if I only wanted a Linux-phone) So why don't we talk about future? What are we going to do with our brick? I think we could do very beautiful things, we need only a couple of months, as I said previously, and then we could speak about how push forward our work :) ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. Personally I don't, but world is beautiful because it's various :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Finally came round to want to try this... :) Am Dienstag, den 27.10.2009, 02:21 +0300 schrieb Paul Fertser: Marcel tan...@googlemail.com writes: I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Manually altering state is needed because you're using deprecated Xglamo. True - I don't want to reflash, so I'm waiting for SHR merging the new stuff into the unstable feed. (Hope opkg doesn't mess up my system during the upgrade then...) - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
ha ha ok, i'll wait. But please, share ;-) ciao d On Wed, Oct 28, 2009 at 12:51 PM, DJDAS dj...@djdas.net wrote: Davide Scaini wrote: DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Simply because ATM our work (it's not ONLY mine but we are a team of about 10 people) it's not more than a simple prototype, we are hardly working but obviously in our spare time so we prefer to achieve almost an alpha stage before sharing our ideas ;) they're too much a WIP... Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) I'm too interested in what works but more in what we can do to let it work better, it's not a competition, it's a matter of research, sharing ideas and propose, not stopping at what we have here, whining and nothing more (otherwise I would by an HTC with Android if I only wanted a Linux-phone) So why don't we talk about future? What are we going to do with our brick? I think we could do very beautiful things, we need only a couple of months, as I said previously, and then we could speak about how push forward our work :) ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. Personally I don't, but world is beautiful because it's various :P ___ 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Hi [scrolling] There are other metaphors available that would fit the device's strengths much better. What about paging? +1 for paging. mind you, I dont need a button for paging, a gesture could do it. which makes it feel very much like scrolling again, but then more solid. $2c, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS dj...@djdas.net wrote: [...] I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) OK, I was going to try to control myself, but I just can't. I'm one of the people who always pops out of the woodwork to scream when someone suggests that switching to QVGA is a good idea. 1) The iPhone is not QVGA. It's HVGA. Try running a web browser on an iPhone with the bottom half of the display covered with black tape. 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. You are suggesting that feature should be downgraded so that it is effectively worse than what is found virtually every smart phone being currently manufactured. Every other feature of our phones is either no better than average (the GPS, the accelerometers), worse than average (USB 1.1, GPRS), or fucked up by firmware problems (WiFi). Yes, let's make sure the display is substandard too! Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. They did not have access to the hardware components. They did not have a legion of engineers to work on it.There is even less chance that gta02-core or gta03 will have state-of-the-art graphics capabilities. It will be nothing short of a miracle if a community hardware effort ever produces a usable phone, available to the full OM community, at all. IMO the OM software should try to differentiate our device from other smart phones, not produce a half-assed iPhone clone. Forget smooth graphics. Forget kinetic scrolling. Forget transparency. Show a simple, clean array of icons representing the applications which can be launched. Allow the user to set the brightness, screen blank time and suspend time. Stop there. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Ken Young wrote: DJDAS dj...@djdas.net wrote: [...] I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) OK, I was going to try to control myself, but I just can't. I'm one of the people who always pops out of the woodwork to scream when someone suggests that switching to QVGA is a good idea. 1) The iPhone is not QVGA. It's HVGA. Try running a web browser on an iPhone with the bottom half of the display covered with black tape. 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. You are suggesting that feature should be downgraded so that it is effectively worse than what is found virtually every smart phone being currently manufactured. Every other feature of our phones is either no better than average (the GPS, the accelerometers), worse than average (USB 1.1, GPRS), or fucked up by firmware problems (WiFi). Yes, let's make sure the display is substandard too! Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. They did not have access to the hardware components. They did not have a legion of engineers to work on it.There is even less chance that gta02-core or gta03 will have state-of-the-art graphics capabilities. It will be nothing short of a miracle if a community hardware effort ever produces a usable phone, available to the full OM community, at all. IMO the OM software should try to differentiate our device from other smart phones, not produce a half-assed iPhone clone. Forget smooth graphics. Forget kinetic scrolling. Forget transparency. Show a simple, clean array of icons representing the applications which can be launched. Allow the user to set the brightness, screen blank time and suspend time. Stop there. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Neo graphics is certainly not as wonderful as you can get with iPhone like devices, but it is certainly far from a disaster. Only real problem I have found is the rate at which images can be displayed, which appears to be related more to SD card and memory access speed than anything else. Still, its usable for looping through pictures. The VGA resolution makes the device as far as I am concerned. Lots of space for a nice application UI, good scrolling, scalable fonts, nice color handling. I do think, however, that its never going to be more than an interesting toy and test platform for ideas for mobile applications. To me, the most interesting feature is it can be used as a portable office, as it can hold quite a bit of data, connects to anything, and when forwarded to a display with modern graphics capabilities, is quite fast and smooth on many applications. Instead of hauling about a portable, you can pop the Neo in your pocket, and not worry about it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS wrote: Xavier Cremaschi wrote: No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? That as Raster correctly said, default is something that should do everything as-best-as-possible, and default in all E distros is a pain-in-the-a** This is a distro maintainer issue ok but remember I'm talking from the user's point of view and from this point of view it's a matter of E not distro maintainer configuration (given both distros suffer the same problem). And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) i'll tell you something about e themes: so you have teh possibility to make everything constist of what you want ant look like you want it. if i have the time i will make you an e theme that uses hardly äny images and as little layers as possible it will be very fast in comparison. best example for single layer atm should be the toolbars in elm and illume using gry* theme, which can be made even faster if you use some tricks (yes i have something specific in mind but i dunno if i'll actually impelent it (no the user wont SEE any desing difference, but the code-wise design would get ugly and i dont think i want that). if you want to theme e you will probably need more time to get into it, but a soon as you are in it you can radiacally change the way it behaves and the way it looks. you have much more possibilites which means moch more potential for optimization the gtk will ever give you, because the desing of gtk limits you VERY MUCH, edje doesn't. i've wrote 3 themes until now (of which 2 have been released third one was playground for exploiting how far one can go using edje, when you see it you'll shit bricks!). i can make gry* even faster, but the them is still in development and there still soem decisions to make before i can start to kick out even the last bit of unneeded stuff (also it gets a little tricky if you try not to use any images and still want to make it look good also testing is required to find out what gives you ultimate speed with nice looks...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On 10/28/09, DJDAS dj...@djdas.net wrote: And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Also light themes which already exist - niebiee, nEo and gry* - are available in repositories) Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Wow, I'm surprised nobody in this thread has been throwing Hitler insults around yet [1]. Changing the default resolution on the FR to QVGA is a good idea if it means a more responsive UI. Assuming that bpp and fps parameters stay the same, that would mean 1/4 of the current glamo-bus traffic. Personally, I'm more interested in running Android on my FR, so even changing the framebuffer resolution statically in the kernel source would be fine by me. C [1] http://en.wikipedia.org/wiki/Godwin's_law ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Sebastian Krzyszkowiak wrote: But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. Sorry other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. Sorry How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Maybe a contest asking if users wanted to launch opkg upgrade without messing their system at random one day yes and the following no? Maybe asking if the unstable or stable o testing branches could be useful for ALL instead of deciding to break things without any advice? I think community driven means we want to decide one thing do you agree with us or suggest something better? not we decide to do something and you are only passive testers simply because even the Freerunner is a high end user device, not every high end user is a Linux system expert or able to fix something...But maybe I'm wrong so sorry again... Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). It's not trolling, I never trolled or wanted to, but asked questions and told my opinion (I was rude in my first post but I explained why), if this is not acceptable only because I don't fully agree with Raster or SHR devs it's not my problem and I'll continue to work by myself and (if possible) share my results with anyone interested in, otherwise it's really not a problem and my life will go on as ever :) my way of thinking the Freerunner is written in the little green card I found in its box... So sorry again and good bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS wrote: Cedric BAIL wrote: So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. That's exactly what I said in my previous post it's not me that is saying E is the best piece of software, all the others are sh*t and I'm not crying, I worked to optimize my personal distribution based on an old FDOM and it's quite responsive and daily since september 2008, FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On 10/28/09, DJDAS dj...@djdas.net wrote: Sebastian Krzyszkowiak wrote: But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. Sorry other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. Sorry How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Maybe a contest asking if users wanted to launch opkg upgrade without messing their system at random one day yes and the following no? Maybe asking if the unstable or stable o testing branches could be useful for ALL instead of deciding to break things without any advice? I think community driven means we want to decide one thing do you agree with us or suggest something better? not we decide to do something and you are only passive testers simply because even the Freerunner is a high end user device, not every high end user is a Linux system expert or able to fix something...But maybe I'm wrong so sorry again... Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). It's not trolling, I never trolled or wanted to, but asked questions and told my opinion (I was rude in my first post but I explained why), if this is not acceptable only because I don't fully agree with Raster or SHR devs it's not my problem and I'll continue to work by myself and (if possible) share my results with anyone interested in, otherwise it's really not a problem and my life will go on as ever :) my way of thinking the Freerunner is written in the little green card I found in its box... So sorry again and good bye. Well, don't be sorry. Just please, be little more friendly when expressing your opinions, as discussing when being close to insults isn't nice ;) That's all. Personally I think you're wrong, but I'm not God, not even Flying Spaghetti Monster, so we both can be wrong ;) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wednesday 28 October 2009, DJDAS wrote: Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... FDOM display is faster mainly because it uses a relatively simple theme. Bernd's lightweight themes should give a similar speedup. Another factor is that some iterations of the fso daemons have been occasional resource hogs, causing display slowdowns whichever toolkit you use. This has been addressed partly by bugfixes in the python implementations, and for the future by the ongoing move to vala implementations of the daemons, starting with the most resource-hungry. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On p. 1. Why not to make some 'viewport' instead of moving objects? This way, it is possible to render whole background, then whole moved 'contents', and finally scrolling we'll have only one blit operation per redraw. To take care of animation, it's possible to store list of 'animated' areas, where rendering must be redone each time, and this will slow down things only then that animation really needed. So, by 'pre-render' I mean rendering 'contents' in advance. I looked to qt and see that it is almost as compicated as E: a. background is not moving b. the 'selected' item in list is highlighted with transparent gradient rectangle which is fading from black to green on selection. c. if i launch something I would get transparent 'clock' with animation, with menu still moving behind it. d. It slows much then moving selection. On p. 2. I wish someone who knows hardware to answer. Why memory copy looks so slow? Is this situation will be same on gta02-core? I've run test on nokia 710 and got 400Mb/s... On p. 3.: Really, such behavour of sliding top item (having noting below it while it desappears) is 100% visual bug. Will you handle it? How within current concept of 'clearing cache'? Sure I know from where everything came from on any computer :) But you want to tell that redecoding and rereading png from slow device worth it? Which memory footprint will have E it we'll completely desable removeing things from that cache until they will be destroyed by their owners? And btw, how to change size of cache? On p. 5: Really, we have kernel which operates at 200Hz, so per slice we can work with according to my computation - 34Mb/200 170Kb of memory, or 400Mhz/200 = 2 millon operations. This enough to make context switching cache cleanup important. People report as 0.25% runtime. [http://lwn.net/images/conf/rtlws11/papers/paper.01.html] On p. 7: 'Work on' and 'have target' are different things in many cases. :) On p. 8: All this is about making money, not good things. Crap :) On p. 9: As I already wrote, it's never 'doesn't matter', at least for me. I am still using wmaker on 2Ghz Xeon at home. Why? Because it has latency Xms, while gnome have 10*X ms. And, unfortunately for me, I can notice this. :) Gennady В Срд, 28/10/2009 в 01:58 +1100, Carsten Haitzler пишет: On Tue, 27 Oct 2009 17:11:08 +0300 Gennady Kupava g...@bsdmn.com said: I am sorry, but my letter is not about trolling and blaming but about optimization, qt and e, speed is interesting for me, not blaming. Calm down guys! I've numbered separate points overwise my letter will look endless :) 1. First, bit about qt scrolling - It's not so simple Carlsen want it to be. I see background image, rendered text and 1-2 relativaly small image each line. Apllications menu have ~40 entries. All scrolling very smooth, and no rectangles where. Carlsen, have you run qtmoko? Buttons are changing only then you press them. What prevents E from prerendering contents of scrollable area, it is not changing on the fly? Lack of this optimization makes menus and scrollable areas much slower. scrolling isnt any special operation in efl. it's moving some objects around. that's all it is. a scroller just moves its child around. moving an object queues redraws for previous and current positions. evas' merges all redraws at render time and just does them. it will avoid drawing things that will be later overwritten by solid pixels. as long as it knows that they are solid (eg solid rect, image without an alpha channel etc.) scrolling is done very differently. you can't pre-render as they get rendered on the fly. everythign does. evas has caches to save copies of scaled images (if smooth scaled) to save computation making the smooth when scaling on every redraw. but it's still a draw. this is done this way because it is increidbly flexible. you get the ability to have translucent items and all sorts of goodies. a draw in the end is a copy from some source and a write to a dest in evas. the more reads you do and writes - the worse it gets. worse is alpha blend as its read source, dest then write to dest (after some calculations). now... if your list in elementary had NO backgroun except the selecte item ALL it woudl do it draw the changes in test items - ie fill in the background (solid color would be writes onlt, image woudl be read then write) and then draw text on top (an alpha blend op with source data being only 8bit alpha). and this only for where the text is. for qte/qtopia/qtwhatever it is called now, if you have a background that moves with the text that scrolls, then it is a simple copy (copy current area up N pixels or down) thus a read and write, then draw new area. if the display is with a static bg and scrolling text - it's the same as evas. evas's scroling is ONLY this method. if you configured the theme to be the same as qt (from memory it was solid black bg's etc.) you'd end up
Re: Centralization of graphical awesomeness
Al Johnson wrote: On Wednesday 28 October 2009, DJDAS wrote: Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... FDOM display is faster mainly because it uses a relatively simple theme. Jesus, this world is so crazy, it is actually true what five people already said, thanks Al for confirming. so much craziness in this world... i'm gonna look out the window to watch for flying pigs. oink oink, notch notch, grunz grunz! Bernd's lightweight themes should give a similar speedup. Another factor is that some iterations of the fso daemons have been occasional resource hogs, causing display slowdowns whichever toolkit you use. This has been addressed partly by bugfixes in the python implementations, and for the future by the ongoing move to vala implementations of the daemons, starting with the most resource-hungry. ** _ `,\) `--==\\ / `--==\\/ .--.Y|\\_ @_// 66\_ |\ \ _() \ /-| ||'--' jgs \_\ \_\\ ** ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
This thread is getting kinda strange... But funneh if one doesn't take people too serious who think they are :D Am Mittwoch, den 28.10.2009, 23:07 +0100 schrieb Bernd Prünster: Al Johnson wrote: On Wednesday 28 October 2009, DJDAS wrote: Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... FDOM display is faster mainly because it uses a relatively simple theme. Jesus, this world is so crazy, it is actually true what five people already said, thanks Al for confirming. so much craziness in this world... i'm gonna look out the window to watch for flying pigs. oink oink, notch notch, grunz grunz! Bernd's lightweight themes should give a similar speedup. Another factor is that some iterations of the fso daemons have been occasional resource hogs, causing display slowdowns whichever toolkit you use. This has been addressed partly by bugfixes in the python implementations, and for the future by the ongoing move to vala implementations of the daemons, starting with the most resource-hungry. _ `,\) `--==\\ / `--==\\/ .--.Y|\\_ @_// 66\_ |\ \ _() \ /-| ||'--' jgs \_\ \_\\ ___ 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: Centralization of graphical awesomeness
The problem is that playing movies is only one of the FR uses (one I have never done by the way - I suspect its actually a minor use for most people) - I love the FR's high res screen that can make legible quite small text and details. So, I would be quite unhappy to have QVGA as the default when I dont use anything that would benefit. That being said, it would be a nice option if it can be made both selectable and non-buggy - I do have a mythbox and FR/myth integration would be a wow factor thing, though not very useful otherwise. BillK On Wed, 2009-10-28 at 13:58 -0400, Christopher Friedt wrote: Wow, I'm surprised nobody in this thread has been throwing Hitler insults around yet [1]. Changing the default resolution on the FR to QVGA is a good idea if it means a more responsive UI. Assuming that bpp and fps parameters stay the same, that would mean 1/4 of the current glamo-bus traffic. Personally, I'm more interested in running Android on my FR, so even changing the framebuffer resolution statically in the kernel source would be fine by me. C [1] http://en.wikipedia.org/wiki/Godwin's_law ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Thu, 29 Oct 2009 00:19:26 +0300 Gennady Kupava g...@bsdmn.com said: On p. 1. Why not to make some 'viewport' instead of moving objects? This way, it is possible to render whole background, then whole moved 'contents', and finally scrolling we'll have only one blit operation per redraw. To take care of animation, it's possible to store list of 'animated' areas, where rendering must be redone each time, and this will slow down things only then that animation really needed. i could add such objects, but i'm not going to. why? because the don't work well with opengl for starters, and because it will be a LOT of work changing everything to sue them AND they will consume more memory. and finally... the time for needing to do so for me has long passed. i am busy enough with evas and efl and just don't have this time. i have to prioritize what i do and this is low on a priority list. So, by 'pre-render' I mean rendering 'contents' in advance. I looked to qt and see that it is almost as compicated as E: a. background is not moving b. the 'selected' item in list is highlighted with transparent gradient rectangle which is fading from black to green on selection. c. if i launch something I would get transparent 'clock' with animation, with menu still moving behind it. d. It slows much then moving selection. so it has its slownesses too (move the selection). :) but all the items drom memory are BLANK except the selected one. not so in the themes for SHR and default. make themes equal and then we can compare. On p. 2. I wish someone who knows hardware to answer. Why memory copy looks so slow? Is this situation will be same on gta02-core? I've run test on nokia 710 and got 400Mb/s... http://images.google.com/imgres?imgurl=http://img.gsmarena.com/vv/pics/vodafone/vodafone-710-1.jpgimgrefurl=http://www.gsmarena.com/vodafone_710-pictures-2459.phpusg=__rwvEEFAU5J0nv5LCRl6UnqmHIZ4=h=529w=546sz=58hl=enstart=1um=1tbnid=d0i6EqQQVDA8eM:tbnh=129tbnw=133prev=/images%3Fq%3Dnokoa%2B710%26hl%3Den%26sa%3DN%26um%3D1 thhttp://images.google.com/imgres?imgurl=http://img.gsmarena.com/vv/pics/vodafone/vodafone-710-1.jpgimgrefurl=http://www.gsmarena.com/vodafone_710-pictures-2459.phpusg=__rwvEEFAU5J0nv5LCRl6UnqmHIZ4=h=529w=546sz=58hl=enstart=1um=1tbnid=d0i6EqQQVDA8eM:tbnh=129tbnw=133prev=/images%3Fq%3Dnokoa%2B710%26hl%3Den%26sa%3DN%26um%3D1at one? can't comment on the 710 - but 400m/s seems pretty high to me. for that level of device. something doesn't seem right in the benchmark / timing etc.? (even the s3c56410 i have clocks in at 150 or 170m/s memcpy() speeds (according to lmbench - you should try lmbench. at least its a good standard that runs pretty much everywhere) On p. 3.: Really, such behavour of sliding top item (having noting below it while it desappears) is 100% visual bug. Will you handle it? How within current concept of 'clearing cache'? as i said before alreayd... its a CONFIG VALUE - its configuration. it's not hard coded! you can determine how long between flushes and how big caches are! little sliders to do it all for you under settings-advanced-performance (advanced mode). i won't handle anything as its already a user tunable configuration value. if the delays are not the re-loading from disk (io) then they may be in-memory cache population (eg of scaled versions of images) to speed up future draws - though these also get flushed in the above flushing... but.. if it's not.. then its either the xserver pausing/halting internally for some reason or the kernel hiccuping handling some interrupts etc. i don't know which it is and i don't intend to sit down and find out. i'm pointing at likely candidates. i don't have the time here to sit and trace at the code level kernel, xserver, and app thats drawing when i am pretty certain such pauses are not my bug. if its cache flushing - it's tunable. if its something else... Sure I know from where everything came from on any computer :) But you want to tell that redecoding and rereading png from slow device worth it? Which memory footprint will have E it we'll completely desable removeing things from that cache until they will be destroyed by their owners? And btw, how to change size of cache? ugh.. see above... it's a config value it's tunable. you can ask for 50mg of cache and set flushes to every few hours instead of 60 seconds! meemory footprint will expand by the size of the cache set. if 50 m - then e will grow by that amount. well actually more as the scale cache also shares size with the normal cache - so possibly 100m). it depends on thhe theme, and how much data is actually loaded and uses. On p. 5: Really, we have kernel which operates at 200Hz, so per slice we can work with according to my computation - 34Mb/200 170Kb of memory, or 400Mhz/200 = 2 millon operations. This enough to make context switching 1hz != 1 operation. :) eg a divide may be 50 or 100x slower than an add. a bitshift often comes for free
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: Also, I installed Qtv14 (thanks to Radek for that distribution), and that I see? I is fast enought, scrolls fast, react fast, and so on. So, scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. if you make the theme SIMPLER with just solid rectangles, like qt - efl will begin to be closer to the same speed. all that pretty stuff comes at a cost. and people want their pretty. tone down the theme to bare rectangles and text and it'll be faster. comparing qt and efl is apples vs oranges. efl simply does a hell of a lot more in the graphics department. and people are using that hell of a lot more AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... E and E's programs just need optimizations. Openembedded in all sucks, as it brings no benefit (same glibc and kernel) with bunch of drawbacks - no easy way to compile for it, so (for me) it's uneasy to figure out that's going on with E. No oprofile where. you have no idea how many optimisations they have. saying they need them is like saying linux needs virtual memory! it just needs it!. it HAS it. in spades. read the code. you wont find routines for rendering faster in most of the world. (when it comes to software). the other engines can full offload to a subsystem (gl, xrender, etc. etc.) *IF* it is there. WHAT e is doing is different to qt because thats how it is being used. if you reduce what its doing to be the same as qt, you will find the speed becomes similar. the reason qt looks faster is that it is simply doing less. So E it's not as optimized ;) I prefer to reduce that doing-thing but have a responsive device instead of have to read the code to look how much is optimized to render like a Commodore 64 I wish E to be faster! Gennady. I wish E to be fired ;) I consider Glamo the worthiest thing Sean and his staff ever thought to add on the Freerunner but Qt with framebuffer are the proof that optimized and well written code is possible and even with Glamo some smooth and fancy GUI are possible... Nothing personal... Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 10:01:58 +0100 DJDAS dj...@djdas.net said: AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. -- - 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: Centralization of graphical awesomeness
DJDAS a écrit : It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I beg to differ, your personal experience is not mine (E17 being damn fast comparing to xfce). E17 is fuck**g fast on limited hardware. I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... I think you miss the point : - qtmoko/qtopia is pretty because of good skin and good uniformity - qt in qtmoko is very simple (for example no transparency, no fancy controls...) - E17 as used in shr/om200x uses more advanced things than qt in QtMoko - E17 as used in shr/om200x is not as pretty as qt in qtmoko (well done qtopia team !) If you put the same things in both qt and E17 -- for example if you try to mimic qtmoko gui with E17 and if you disable everything in E17 that is useless in order to produce qtmoko gui-- E17 will be faster. A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. Xavier Cremaschi. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Thanks Xavier, for stopping what was going to be a flamefest. On Tue, Oct 27, 2009 at 10:23 AM, Xavier Cremaschi omega.xav...@gmail.comwrote: DJDAS a écrit : It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I beg to differ, your personal experience is not mine (E17 being damn fast comparing to xfce). E17 is fuck**g fast on limited hardware. I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... I think you miss the point : - qtmoko/qtopia is pretty because of good skin and good uniformity - qt in qtmoko is very simple (for example no transparency, no fancy controls...) - E17 as used in shr/om200x uses more advanced things than qt in QtMoko - E17 as used in shr/om200x is not as pretty as qt in qtmoko (well done qtopia team !) If you put the same things in both qt and E17 -- for example if you try to mimic qtmoko gui with E17 and if you disable everything in E17 that is useless in order to produce qtmoko gui-- E17 will be faster. A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. Xavier Cremaschi. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. Given that I never said to be an expert but simple telling my point of view as an end user, and given that I don't want to start a flame, I simply say that I work as an IT manager on embedded system since 2001, I wrote code for palmtops, mobile phones and more embedded devices like POS terminals and custom cards (always in C/C++), so I think I can speak with a bit of knowledge. I'm NOT a graphic expert (never said this) so all my respect to people who carve the bits and write graphic drivers and all the stuff rounding graphic world. My considerations were a bit of business-like words, because I think too many times you shut people complaints saying you bought a shit*y hardware so don't bother me and I don't think it's a winning approach (I won't say to a customer you fool, you bought a bad phone so my fantastic program doesn't work because of you). Technically speaking I didn't look at your code (and won't) so I don't criticize how it's written/commented/optimized and so on, I criticize your approach and, let me say, I would prefer you said something like I preferred to write some *specifically* for the Freerunner but someone told me not to because of business choices instead of I tried to adapt something working perfectly (which is not for me, indeed) on a loser device :) It's simply a matter of approach. I repeat nothing personal, just some suggestions ;) Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
I think this post should be very helpful in optimizing our distros (SHR first - 'cause i seems to be the most used). Thanks for the helpful hints, but maybe now we should move in producing something that works for all, something as a click and enjoy approach. Thanks (hope that some shr-dev are listening) d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Regarding the whole discussion. I would rather have a glamo chip that's 10x slower and be able to receive phone calls and text messages. Seriously, the whole software stack all the way from the bootloader to the GUIs (ok not all of them) is in alpha stage. Why bitch about slow hardware? 2009/10/27 Davide Scaini dsca...@gmail.com I think this post should be very helpful in optimizing our distros (SHR first - 'cause i seems to be the most used). Thanks for the helpful hints, but maybe now we should move in producing something that works for all, something as a click and enjoy approach. Thanks (hope that some shr-dev are listening) d ___ 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: Centralization of graphical awesomeness
Bah, I write too slowly. Started when this mail arrived, didn't read the other responses yet... This seems to be, in part, an issue of talking about different things... (see below) On Tuesday 27 October 2009 10:01:58 DJDAS wrote: Carsten Haitzler (The Rasterman) wrote: scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. if you make the theme SIMPLER with just solid rectangles, like qt - efl will begin to be closer to the same speed. all that pretty stuff comes at a cost. and people want their pretty. tone down the theme to bare rectangles and text and it'll be faster. comparing qt and efl is apples vs oranges. efl simply does a hell of a lot more in the graphics department. and people are using that hell of a lot more AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Your wording is far nastier than needed, but you're still sort of correct - E works *like Qt* only if you don't use those parts of E that Qt doesn't have (or doesn't use). However, in this case, people are doing things with E that they aren't doing with Qt (possibly because Qt can't do those things?), leading to more work for E than for Qt, and do you *really* believe that it's possible to do more work in the same or less time, all other things being equal? Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). You seem to be the one comparing desktop and embedded performance here... And if Compiz+XFCE is so much better than E, why aren't you using that instead of E on the FR? Oh, right... Compiz doesn't work there, does it? Yet, E does. I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card That's not what he seems to be saying to me. Seems more like with this badly performing device, you can still use the features if you want, but don't expect it to be fast - if you want fast, don't use the fancy features. Basically, there's a tradeoff between fancy features and speed. Fancy features = more work, and more work = more time used. The way I see it, if Qt was configured to do the same things as E is doing in the current GUI (assuming it's even capable of doing those things), it would be at least as slow as E is. Conversely, if E was configured to only do the things Qt is, it would do them as fast as Qt is. Qt being fast thus being a result of it not using the fancy features, such as alpha blending with a background image (which E is doing). Be serious please... Same to you. To me, you don't seem to be acting very seriously in this mail. you have no idea how many optimisations they have. saying they need them is like saying linux needs virtual memory! it just needs it!. it HAS it. in spades. read the code. you wont find routines for rendering faster in most of the world. (when it comes to software). the other engines can full offload to a subsystem (gl, xrender, etc. etc.) *IF* it is there. WHAT e is doing is different to qt because thats how it is being used. if you reduce what its doing to be the same as qt, you will find the speed becomes similar. the reason qt looks faster is that it is simply doing less. So E it's not as optimized ;) I prefer to reduce that doing-thing but have a responsive device instead of have to read the code to look how much is optimized to render like a Commodore 64 You're comparing apples to oranges - optimized code with optimized-for-the- device GUI. The two are vastly different things, with different solutions. Configuring which features to use is an issue of optimization - optimizing the GUI for the (limitations of the) device and the desires of the users. An example of a GUI optimization that could be done here, is dropping the background image (the gradient) from the launcher, and using a solid color instead - if done
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: I beg to differ, your personal experience is not mine (E17 being damn fast comparing to xfce). E17 is fuck**g fast on limited hardware. World is beautiful because it's various ;) I think you miss the point : - qtmoko/qtopia is pretty because of good skin and good uniformity Because it's well studied and designed - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) - E17 as used in shr/om200x uses more advanced things than qt in QtMoko At which cost? - E17 as used in shr/om200x is not as pretty as qt in qtmoko (well done qtopia team !) You answered yourself ;) If you put the same things in both qt and E17 -- for example if you try to mimic qtmoko gui with E17 and if you disable everything in E17 that is useless in order to produce qtmoko gui-- E17 will be faster. My experience in embedded devices is don't disable something, REMOVE it because it costs CPU, memory and can cause more bugs, or better rewrite it in order to squeeze that fuc*ing hardware A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. This doesn't mean E17 is written better than qt, but the exactly opposite ;) Please consider I don't want to start a flame war, listen to my previous answer to Raster for many comments to my previous words :) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009 11:47:22 DJDAS wrote: Xavier Cremaschi wrote: A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. This doesn't mean E17 is written better than qt, but the exactly opposite I think there's a terminology problem here, that probably causes some confusion. E17 is not the name of the interface. It is the name of the libraries used to build the interface. The standard home interface on SHR, which uses E17, is called Illume, I believe. Thus, what I think you mean, is that while E17 may have faster code than Qt, *Illume* (the interface) is not written better than the Qt-based interface, because it uses too many of the features (such as the earlier mentioned transparency), instead of being well adapted to the FR (to be responsive). -Frode ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... To compare, let's take ( for example :) ) Qalee it run a Qt over Xorg with transparency, ... When developing it I've made some tests, everything that's move on the screen is slooow and it's even more slow when we have transparency effect applied. So during the development I've banned scrolling and thinks that are moving. The feedback I received is that it's more fast than other thinks ( except Qtmoko, no X ). I personally think the problem is not the toolkit ( but no, I don't like E ), I think Qt can do the same thinks (or more?) as fast as Enlightenment It's the way it's developed. We have an hardware that is slow for some reason ( graphic drivers ?, hardware problem?, ... ), we have to work with it ( and think how get can improve it ), so don't take an application that work on other hardware and push it as it on the phone and complain it's slow, if you like E, just remove thinks that doesn't work on the freerunner ... or use Qalee :) Christophe -- -- Openmoko phone gui : http://www.qalee.org ( Last alpha before first stable core release coming soon ) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 11:11:04 +0100 DJDAS dj...@djdas.net said: Carsten Haitzler (The Rasterman) wrote: you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. Given that I never said to be an expert but simple telling my point of well.. you're telling the one that wrote the graphics code, that has read the glamo hw docs, has worked on it long before freerunner was on sale, who has written graphics code for many platforms, manye cpus of many varying levesl of speed (from 7mhz 68k up), many gpu's from old console hardware to 3d gl... that he's talking bullshit (and being very rude about it, providing no evidence, numbers or anything else to back anything you say up) about exactly the things he's deeply involved in. thus.. you must be an expert beyond my experience and abilites. you, sir, are rude. that much i definitely know about you. the rest. you have no idea of what you speak. you showed it in your previous mail. your opinions on this are the equivalent of me giving my opinions on tcp stack design. worthless. the other people in this thread have actually read what i said and gotten it right. but you, have not. you have simply resorted to an incredibly rude and disrespectful outburst. with no provocation. if you are an IT manager, i am amazed you got that far and stayed. it's one thing to be frank and be factual. it's another to behave like you. if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. i have been factual, realistic and constructive. i have stated that freerunner is a limited platform. it's one of the slowest (if running at its native resolution i have ever worked on, and i've worked on a fair few. there is a limited amount you'll get out of it. and it's not an architecture you're going to see again. so how much effort do you put into a 1 -off that will not gain more units in the general user population over time? you find quick ways to make it do what you want. i have constructively suggested those - 1. simplify theme so its solid rects and text and it will look like qtopia.. and begin to run like qtopia does. but it is NOT being used like that. people are using themes that have scaled image backgrounds and buttons and list items with multiple layers of graphics rendered on top of eachother. make this simple and.. speed will follow. no one has to go change their toolkits and listen to you. the other easy and feasible option is lower resolution - draw fewer pixels and you'll get more speed. these are developers talking to other developers. i am telling 1. the users and developers that insist on vga, that they are paying a high price for their insistence. the hardware simply wasnt designed to be optimal on vga. trust me. i've read the glamo docs. vga is the top LIMIT of its capabilities. it's being stretched. these developers ALSO decide the themes they use as part of building SHR for example. the default is a generic default - it's not tuned for really slow systems. tune away for what you have. i havent shut anyone up. i have told them they are stuck with slow hardware. don't expect miracles. make a sacrifice. the device, the theme or the resolution. choose the lamb for the slaughtering. enlightenment and illume have seen pretty close to zero attention since i left openmoko. it's a BUSINESS CHOICE. no one is paying me to work on it. i am getting paid to put EFL on significantly superior devices that handle it wonderfully. everyone i talk to in the world of actually producing products, and with whom i work, aim far beyond openmoko. they want gui's that are smooth, silky, fluid and beautiful. they have ui designer requirements for things like translucent lists with static backgrounds. EFL does for them what no other toolkit can do. MEET BUSINESS REQUIREMENTS. if you like to use that word. and it's doing that wonderfully for them. the benefit to the openmoko users and community is that the work to improve things there gives them improvements too. it also paves the way for when SHR and so on are fully ported to better devices, like the palm pre for example. GTA02 in comparison to a palm pre is a very very very weak device... except in 1 respect. screen resolution. as for e17 not runing on any desktop acceptably. i really have to laugh at that, as i have had it run acceptably on an hp mini-note 2133. 1 ghz via c3. really slow. e is just fine on it. just compile and run. compiz doesn't even
Re: Centralization of graphical awesomeness
On Tue, Oct 27, 2009 at 04:42:21PM +1100, Carsten Haitzler wrote: On Tue, 27 Oct 2009 06:31:26 +0100 ri...@happyleptic.org said: -[ Tue, Oct 27, 2009 at 11:52:04AM +1100, Carsten Haitzler ] E is nice thing, but it look like highly unoptimized. i beg to differ. it's more optimised than pretty much anything out there. scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. So, probably unoptimized is not the right term. Maybe it's just _inapropriate_ to do these things on such a device, and that E, because it does so many things, is not such a good choice however optimized it may be ? Or maybe people really want it that way, unusable but good looking ? well as i said. it works fine and fluidly on many other devices. you are free to ditch efl and use gtk or qt if you want. it's your choice. of course if you are not developing apps... it's kind of not your choice :) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. I personally belive that the gta02-core project is a wonderful idea and that Openmoko Inc should have done it that way from the start. So in terms of openness and freedom this is a big step forward and I hope we will eventually see a gta03 (even a gta02 without glamo as the current plan is should improve graphic performance as you previously explained). Besides there are no real alternatives which provides the same kind of openess. So all in all I think we should focus on getting the best out of our current open platform this will at the same time guarantee that it will be lightening fast on a newer device. Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009 12:46:01 Marc Andre Tanner wrote: but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. I personally belive that the gta02-core project is a wonderful idea and that Openmoko Inc should have done it that way from the start. So in terms of openness and freedom this is a big step forward and I hope we will eventually see a gta03 (even a gta02 without glamo as the current plan is should improve graphic performance as you previously explained). +1 Besides there are no real alternatives which provides the same kind of openess. So all in all I think we should focus on getting the best out of our current open platform this will at the same time guarantee that it will be lightening fast on a newer device. +1 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, Oct 27, 2009 at 6:42 AM, Carsten Haitzler ras...@rasterman.com wrote: I would only rise couple of points here: Scrolling is not optimized at the maximum. Look at ipod or nintendo DS, they do *discrete* scrolling and it is amazingly fast. They dont do kinetics, or pixel perfect scrolling like iphone. Also on a side note if the content is a bit bigger, the scrolling is exponentially slows down... but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. Lets count the elementary apps here. How many of them written for the Freerunner? Sad true: almost all usable elementary app are written for the Freerunner. Where are the other future devices to developing for? There is none. Maybe Palm Pre reverse engineering will change things a little, but its only a hope right now. (and also a dead-end, as the Palm Pixi is a no-go, and probably the future devices will be also) So fixing some annoying things because of the Freerunners actually makes sense, as we are a huge e userbase with a couple of *usable* real world apps. Not demos;-) In my personal view, even the Freerunner would be 10 times better hardware-wise, would not change to many things. As the lowlevel apps is getting in usable shape just now. I can use my phone like a month *reliably* thanks to frameworkd. I think in a year or so we will grow out the Freerunner. But until then there is a lot of small usable apps to write!;-) Best regards, Laszlo ps: Im still figthing with the bad audio experience after 7(!) months... Yeah, the Freerunner could be better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009, DJDAS wrote: Xavier Cremaschi wrote: - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) Then use a theme that doesn't use transparency! Bernd Prünster has done great work on producing themes that run much faster than the default while still looking good. They don't degrade with the 16 bit renderer either, and that runs even faster. The themes should be in the shr repos by now. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, Oct 27, 2009 at 10:01 AM, DJDAS dj...@djdas.net wrote: AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Dude, what is lacking in your comment is some respect. Raster has some deep knowledge in graphical libraries, and more then 10 years of experience. So raster knows more then most of us will ever learn in his whole life...;-) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
I am sorry, but my letter is not about trolling and blaming but about optimization, qt and e, speed is interesting for me, not blaming. Calm down guys! I've numbered separate points overwise my letter will look endless :) 1. First, bit about qt scrolling - It's not so simple Carlsen want it to be. I see background image, rendered text and 1-2 relativaly small image each line. Apllications menu have ~40 entries. All scrolling very smooth, and no rectangles where. Carlsen, have you run qtmoko? Buttons are changing only then you press them. What prevents E from prerendering contents of scrollable area, it is not changing on the fly? Lack of this optimization makes menus and scrollable areas much slower. 2. Second point of my letter was that Glamo seem should not be blamed for everything. I wrote simple program to measure simple memcpy speed on om... This program just allocates 2 buffers of defined size and outputs count of memcpys of defined size it did in 1 second (interrupt via alarm()). Initally I want to see how arm cache cleanup and task switch influences parallel memory access tasks. Result were surprising for me: OM: buffer_size average_number computed_throughput 128 1260880 153Mb/s 256 540900 132Mb/s 512 252399 123Mb/s 1024 121988 119Mb/s 2048 58827 114Mb/s 4096 29000 113Mb/s 8192 14000 109Mb/s 16384 3660 57Mb/s 32768 1105 36Mb/s 65536 553 34.5Mb/s 131072 274 34.2Mb/s 262144 135 33.7Mb/s 524288 69 34.5Mb/s I did same test on my very-old-Celeron 600 router: 256 2522958 615Mb/s 512 2088723 1019Mb/s 10241554162 1571Mb/s 20481019996 1992Mb/s 3072762667 2234Mb/s 4096109489 427Mb/s 16384 27389 427Mb/s 262144 318 79Mb/s 524288 151 75Mb/s 1048576 76 76Mb/s On desktop (xeon 2Gz): x64 binary: 26214400 74 1850 Mb/s 262144 31971 7992 Mb/s 256 5399451213232 Mb/s x32 binary: 2621440059 1475 Mb/s 262144 29068 7267 Mb/s 256 20810406 5080 Mb/s Old arm-based device at my work (at91rm9200, 180Mhz) 256 16 39Mb/s 256000 167 40Mb/s 256 418044 102Mb/s So, we can see that we have speed of 34Mb/s (it's ever only 5 times declared 7Mb/s for Glamo!) can someone comment? why memcpy is so slow - it is 2 times slower than ancient celeron, and on par with very old arm-based machine, it is not related to glamo anyhow! We can even skip results with cache, where om 10 times slower old machine. 3. ... e - every N seconds (see config dialogs for what it is set to there, but let's say 60 seconds) will flush caches. ... and things are having to be repopulated from disk ... From disk?! This is cost or having small memory footprint? This looks very wrong. 3. ... Actually, yes the GTA01 is very noticeably faster in graphics. ... Can you expose a bit more details: How much it is faster: x2 times, x3, x1.5, x1.2? 4. ... for every second spent uploading contents to glamo, you CANNOT spend it calculating a new fram. ... Yes, this is bad... But qt works :) 5. ... that's because you have 2 processes competing for the cpu to render. ... My measurements of parallel memcpy showed that this is neglibible. 6. ... you wont find routines for rendering faster in most of the world. ... I will. I can recall you previous posts on the topic. 7. but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Frankly speaking you never developed for GTA02, yes? you aim seem always were in future, and this is ok. I am sure that for example scrolling area pre-rendering if good for future. 8. ... most games i know of are written to work on the highest end graphics cards at the time. why? ... Best games are written with other objectives in mind, this games are really interesting for anyone from time to time and for sure will live in ages (chess, nethack and so), our grandchilds will play nethack, be sure. Is it better to make pefrect things? And optimization is always good - you can feel that 10ms latency and 100ms latency is different even both are more than enoght for UI, but you feel that 10ms latency is much better. 9. ... BUSINESS CHOICE ... Everyone here follows it's goals. Carlsen make E. Other want to do hardware. Others want to use free hardware. Others want to increase development skills and hack that HW. Others just feel fun reading this book. Others have this job. Someone even makeing money from OM. ;) All this is ok, and I see nothing bad on making some great E developer to think a bit about optimizations - nobody loose from
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: well as i said. it works fine and fluidly on many other devices. Even Windows Vista works fine and fluidly on 3000$ desktops this doesn't mean it's optimized ;) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Let me you know that in nowadays payments system about 70-75% POS terminals run on Z80 processor or Motorola 68k family...when you stripe your card the system reads the magnetic stripe/microchip (handling security encryption stuff) calls the banking server, communicates with the cash register shows you the PIN request and prints the receipt...there is no need for a quad core to do these things concurrently ;) Personally, before buying the Freerunner I had a Nokia 3650 for 4 years, so I'm not one of those who need the latest hardware to run the latest software which does nothing more than add fancy icons providing the same functionalities and costing double than the previous one...so when I'll have the need to buy a new device probably OM or someone else will provide me a new OPEN hardware (this is what I really need, nothing more) to develop, and use, OPEN software :) why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop is another thing, I don't need compiz or E to show a window with two buttons to connect my wifi or calculate my monthly expenses, this is only a commercial stuff, not for me ;) because hardware moved on. most games i know of are written to work on the highest end graphics cards at the time. why? Because software houses and hardware manufacturers have to sell something to stay on business ;) we are talking about an open platform to develop and use open software on, not on selling an iPhone ;) by the time the game is out and is selling - everyone has finally upgraded to those cards. they were top end 3 years ago when game design started. now they are low to middle end. gta02 is a a middle end device that came out 4-5 years after its components were middle end - except the LCD. you have a 4-5 year old set of components driving a high end screen. you will pay a cost. the developers are smart if they look forward to where hardware will be in N years and make sure they are on the right path for that. if it works now with some tuning and simplification of things like themes - then great. their code, apis and logic dont need a rewrite every few years. This is only commercial stuff, I don't want to sell nothing to anyone, just develop for fun and use my Freerunner as a phone without the need to wait 3 seconds to answer a call... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Laszlo KREKACS ha scritto: Lets count the elementary apps here. How many of them written for the Freerunner? Sad true: almost all usable elementary app are written for the Freerunner. I think in a year or so we will grow out the Freerunner. But until then there is a lot of small usable apps to write!;-) Best regards, Laszlo +100 ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Christophe M wrote: Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... Not true, because if Raster was right the only problem would be the Glamo chip so I would like to say why there are so many differences between Qt and E ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Al Johnson wrote: On Tuesday 27 October 2009, DJDAS wrote: Xavier Cremaschi wrote: - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) Then use a theme that doesn't use transparency! Bernd Prünster has done great work on producing themes that run much faster than the default while still looking good. They don't degrade with the 16 bit renderer either, and that runs even faster. The themes should be in the shr repos by now. I Fixed nEo theme bubbles, but i will have to write phoneui themes (saill waitin for mrmoku to implement themability in phoneui) gry* was adapted to work with new elm version. nEo and gry is in the mrmoku feeds, so just wait for the new unstable and you'll have fast themes in shr repo (i am going to ask mrmoku to put the current version of nEo and gry* theme into current shr-u feeds. the nEo theme has some problems (badly designed edc code to begin with, complicated installation because libframeworkd-phonegui-efl is not really themable.) by the way gry* is even closer to what raster said use rects without scaled images gry* doesn't even use images to render buttons, the are drawn on the fly and look better than anythign i ever seen using software_16. the default theme is simpyl nto optimized for slow devices like the freerunner (i think i counted 5 layers including text for something as simple as a button and not just 4 layers of somethung but 4 layers of which 4 use translucency, of which at least 1 is animated) if you want to know what happens if you kick all that stuff out try the nEo theme or the gry* theme, which both still can be optimized (current gry* version in development has even faster scrolling!) elementary apps are faster than gtk apps, the render faster, they scroll faster (using a proper theme), so i think i can say that raster cannot be talking plain bullshit! (although in the past i was really pissed at him for a couple of things he said and HOW he said it, so i am not his biggest fan, but i can only bow if i look at how powerful the tools are efl puts into my hands and how little ressources they use) and for xfce+compiz compared to efl: ever wondered why the rendering engines are called SOFTWARE? and why compiz requires opengl? go figure! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 17:11:08 +0300 Gennady Kupava g...@bsdmn.com said: I am sorry, but my letter is not about trolling and blaming but about optimization, qt and e, speed is interesting for me, not blaming. Calm down guys! I've numbered separate points overwise my letter will look endless :) 1. First, bit about qt scrolling - It's not so simple Carlsen want it to be. I see background image, rendered text and 1-2 relativaly small image each line. Apllications menu have ~40 entries. All scrolling very smooth, and no rectangles where. Carlsen, have you run qtmoko? Buttons are changing only then you press them. What prevents E from prerendering contents of scrollable area, it is not changing on the fly? Lack of this optimization makes menus and scrollable areas much slower. scrolling isnt any special operation in efl. it's moving some objects around. that's all it is. a scroller just moves its child around. moving an object queues redraws for previous and current positions. evas' merges all redraws at render time and just does them. it will avoid drawing things that will be later overwritten by solid pixels. as long as it knows that they are solid (eg solid rect, image without an alpha channel etc.) scrolling is done very differently. you can't pre-render as they get rendered on the fly. everythign does. evas has caches to save copies of scaled images (if smooth scaled) to save computation making the smooth when scaling on every redraw. but it's still a draw. this is done this way because it is increidbly flexible. you get the ability to have translucent items and all sorts of goodies. a draw in the end is a copy from some source and a write to a dest in evas. the more reads you do and writes - the worse it gets. worse is alpha blend as its read source, dest then write to dest (after some calculations). now... if your list in elementary had NO backgroun except the selecte item ALL it woudl do it draw the changes in test items - ie fill in the background (solid color would be writes onlt, image woudl be read then write) and then draw text on top (an alpha blend op with source data being only 8bit alpha). and this only for where the text is. for qte/qtopia/qtwhatever it is called now, if you have a background that moves with the text that scrolls, then it is a simple copy (copy current area up N pixels or down) thus a read and write, then draw new area. if the display is with a static bg and scrolling text - it's the same as evas. evas's scroling is ONLY this method. if you configured the theme to be the same as qt (from memory it was solid black bg's etc.) you'd end up with approximately the same speed. evas would do a bit more work as it'd alpha blend the text, but it would avoid copying areas of the list that didnt change (eg strings dont fill the entire line and only part of it). it's Carsten btw. t not l :) and i have run qtmoko... before the freerunenr was even out. i tememebr it being orange for selected list items (rectangle), empty if not (just text) and a greyish qt logo background with some visible dither patterns on scale up. 2. Second point of my letter was that Glamo seem should not be blamed for everything. I wrote simple program to measure simple memcpy speed on om... This program just allocates 2 buffers of defined size and outputs count of memcpys of defined size it did in 1 second (interrupt via alarm()). Initally I want to see how arm cache cleanup and task switch influences parallel memory access tasks. Result were surprising for me: glamo is one of the big problems. a write to video memory - eg a new screen fram is.. based on your numbers below, about 1/5h the speed. it is as IF you copied 5x the data from memory to memory. thats a heavy cost. OM: buffer_size average_number computed_throughput 128 1260880 153Mb/s 256 540900 132Mb/s 512 252399 123Mb/s 1024 121988 119Mb/s 2048 58827 114Mb/s 4096 29000 113Mb/s 8192 14000 109Mb/s 16384 3660 57Mb/s 32768 1105 36Mb/s 65536 553 34.5Mb/s 131072 274 34.2Mb/s 262144 135 33.7Mb/s 524288 69 34.5Mb/s only the last really counts. the first are just caching effects. I did same test on my very-old-Celeron 600 router: 256 2522958 615Mb/s 512 2088723 1019Mb/s 10241554162 1571Mb/s 20481019996 1992Mb/s 3072762667 2234Mb/s 4096109489 427Mb/s 16384 27389 427Mb/s 262144 318 79Mb/s 524288 151 75Mb/s 1048576 76 76Mb/s yes. better. the 2442 in the gta02 is an ooold arm cpu. it's not too modern. given when the gta02 was released... it'd like making a pentium4 laptop and releasing it and selling it as new in todays shops. On desktop (xeon 2Gz): x64 binary: 26214400 74 1850 Mb/s 262144 31971 7992 Mb/s 256 5399451213232 Mb/s x32 binary: 2621440059 1475 Mb/s 262144 29068
