e in framebuffer?
Hi, I was wondering if anybody has tried running enlightenment in framebuffer on the freerunner and what the experience was like? The thought came from the fact that QTE seems faster. So, if X was removed from the equation - how would the freerunner perform? I know this will irritate the purists - but with e providing a reasonable windowing environment, with SHR developing a lot of apps in elementary and with the number of apps written in efl/elementary on the rise - this **could** be a viable solution to get a FSO/e based faster phone now. And with the option of launching x as an alternate - available to the user from within e itself - this will also allow the user to run gtk apps when required (with a little delay). Mostly, this will be feasible only if the performance gain without X is significant enough. Any ideas / experiences? -- View this message in context: http://n2.nabble.com/e-in-framebuffer--tp2738995p2738995.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
On Tue, Apr 28, 2009 at 11:59:28PM -0700, c_c wrote: The thought came from the fact that QTE seems faster. So, if X was removed from the equation - how would the freerunner perform? I tried it and it *didn't* seem faster. The speed bottleneck is that the graphics card doesn't have enough bandwidth for the resolution. I've also read somewhere that Xglamo isn't the most performant right now, and that the Xorg driver is actually faster. I know this will irritate the purists Please avoid insulting people. Rui -- Frink! Today is Prickle-Prickle, the 46th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
On Wednesday 29 April 2009 08:59:28 c_c wrote: I know this will irritate the purists - but with e providing a reasonable windowing environment, with SHR developing a lot of apps in elementary and with the number of apps written in efl/elementary on the rise - this **could** be a viable solution to get a FSO/e based faster phone now. I agree, and I always come back to this idea of delivering a fast all-in-one fb-based telephony app. What's holding it back though is the lack of a softkeyboard. And with the option of launching x as an alternate - available to the user from within e itself - this will also allow the user to run gtk apps when required (with a little delay). Right. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
c_c wrote: The thought came from the fact that QTE seems faster. So, if X was removed from the equation - how would the freerunner perform? I never felt a noticeable speed difference. with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
On Wednesday 29 April 2009 13:04:09 Tilman Baumann wrote: c_c wrote: The thought came from the fact that QTE seems faster. So, if X was removed from the equation - how would the freerunner perform? I never felt a noticeable speed difference. Well, I did some measurements on the GTA01 ages ago -- refer to http://www.vanille-media.de/site/index.php/2007/12/08/framebuffer-vs-x11/ with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. This solely depends on your usecase. If you're in for single-window-single-app paradigm, combined with some clever logic to always show a panel, then you don't really need window management. Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. If you do that, you quickly reinvent X ;) Seriously though, some projects have gone that way (evoak, picogui, ...), but dropped the ball. If you really do need window managment, use X. If not, fb- only could be a very viable alternative -- if only we had illume's softkeyboard working... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
Hi, Michael 'Mickey' Lauer-2 wrote: if only we had illume's softkeyboard working... Wonder how QTE does it. I know this will irritate the purists Please avoid insulting people. @ Rui : None intended. :-) -- View this message in context: http://n2.nabble.com/e-in-framebuffer--tp2738995p2740209.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
Michael 'Mickey' Lauer wrote: with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. This solely depends on your usecase. If you're in for single-window-single-app paradigm, combined with some clever logic to always show a panel, then you don't really need window management. Yes, but this really means always only one app _running_. (or drawing) This would require some extensive framework and very specialised code in the apps. (Apps need to free the fb and save the screen state and there would be some supervision needed for managing accesses to screen resources/and switching windows.) I don't think we have the resources for that. I mean, we just barely manage to make a working phone. :) And just forget about porting apps from any other environment. I could imagine doing this all with a evas (that rendering thingy of E, i always confuse the names) frontend which gets instructed to draw some scenario and connects the signals via rpc to a client... Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. If you do that, you quickly reinvent X ;) My point exactly. Seriously though, some projects have gone that way (evoak, picogui, ...), but dropped the ball. If you really do need window managment, use X. If not, fb- only could be a very viable alternative -- if only we had illume's softkeyboard working... If there is no swap out solution. I would just don't bother. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
On Wednesday 29 April 2009 14:16:09 c_c wrote: Michael 'Mickey' Lauer-2 wrote: if only we had illume's softkeyboard working... Wonder how QTE does it. They have their own, designed to work on pure-fb. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
On Wed, 29 Apr 2009 05:16:09 -0700 (PDT) c_c cchan...@yahoo.com said: Hi, Michael 'Mickey' Lauer-2 wrote: if only we had illume's softkeyboard working... Wonder how QTE does it. qte re-implements a windowing system - like x. they just did their own. I know this will irritate the purists Please avoid insulting people. @ Rui : None intended. :-) -- View this message in context: http://n2.nabble.com/e-in-framebuffer--tp2738995p2740209.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - 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: e in framebuffer?
On Wed, 29 Apr 2009 12:04:09 +0100 (BST) Tilman Baumann til...@baumann.name said: c_c wrote: The thought came from the fact that QTE seems faster. So, if X was removed from the equation - how would the freerunner perform? I never felt a noticeable speed difference. with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. and thus.. you will re-invent x. so... stick to x. dont try re-invent it. e can't run in the fb. it's an x11 window manager. it's for x11. the gfx libs its built on though can draw there.. and then you'd be in the 1 process in fb only - that's it land.. as you have no way to share it... create a way and you re-invent x. xglamo has nothnig to do with the speed. it's fine. the problem is 1. video mem access bandwidth - simply uploading data is slow, 2. evas by default draws in 32bpp internally then converts and dithers to 16bpp. it has a pure 16bpp engine - it's faster, but it also has a significant quality drop. personally its enough to make me prefer slower over uglier. thus the default is to use the 32bpp (default generic software engine). -- - 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: e in framebuffer?
On Wed, 29 Apr 2009 13:20:50 +0100 (BST) Tilman Baumann til...@baumann.name said: Michael 'Mickey' Lauer wrote: with e providing a reasonable windowing environment, Window management on plain framebuffer? Are you sure? I would be very interested in learning more about this. My expectation would be that you still need some fb multiplexer that needs to be relatively smart. This solely depends on your usecase. If you're in for single-window-single-app paradigm, combined with some clever logic to always show a panel, then you don't really need window management. Yes, but this really means always only one app _running_. (or drawing) This would require some extensive framework and very specialised code in the apps. (Apps need to free the fb and save the screen state and there would be some supervision needed for managing accesses to screen resources/and switching windows.) I don't think we have the resources for that. I mean, we just barely manage to make a working phone. :) And just forget about porting apps from any other environment. I could imagine doing this all with a evas (that rendering thingy of E, i always confuse the names) frontend which gets instructed to draw some scenario and connects the signals via rpc to a client... Probably by rendering into a shared mem that gets composed to a fb frame by some central daemon. If you do that, you quickly reinvent X ;) My point exactly. Seriously though, some projects have gone that way (evoak, picogui, ...), but dropped the ball. If you really do need window managment, use X. If not, fb- only could be a very viable alternative -- if only we had illume's softkeyboard working... If there is no swap out solution. I would just don't bother. bingo. stic to x. it buys you gtk, qt, sdl, gl, blah blah blah all at oince with the management environment already known and developed. it's trivial yo develop for ON your desktop.. as thats already your windowing system. no emulators needed. just pretend to have a lower res. -- - 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: e in framebuffer?
Hi, Carsten Haitzler (The Rasterman)-2 wrote: bingo. stic to x. it buys you gtk, qt, sdl, gl, blah blah blah Thanks for clearing that up. So maybe a compiled phone stack will push performance to the next level. -- View this message in context: http://n2.nabble.com/e-in-framebuffer--tp2738995p2741567.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
What about making a kick ass ncurses based interface for the phone, that should be fast enough :) On 4/29/09, c_c cchan...@yahoo.com wrote: Hi, Carsten Haitzler (The Rasterman)-2 wrote: bingo. stic to x. it buys you gtk, qt, sdl, gl, blah blah blah Thanks for clearing that up. So maybe a compiled phone stack will push performance to the next level. -- View this message in context: http://n2.nabble.com/e-in-framebuffer--tp2738995p2741567.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
Should be fast, but how would you control that with a touchscreen (- mouse)? -- Marcel Am Mittwoch, 29. April 2009 20:39:48 schrieb fredrik normann: What about making a kick ass ncurses based interface for the phone, that should be fast enough :) On 4/29/09, c_c cchan...@yahoo.com wrote: Hi, Carsten Haitzler (The Rasterman)-2 wrote: bingo. stic to x. it buys you gtk, qt, sdl, gl, blah blah blah Thanks for clearing that up. So maybe a compiled phone stack will push performance to the next level. -- View this message in context: http://n2.nabble.com/e-in-framebuffer--tp2738995p2741567.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
On Wednesday 29 April 2009 20:47:23 Marcel wrote: Should be fast, but how would you control that with a touchscreen (- mouse)? gpm. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: e in framebuffer?
Am Mittwoch, 29. April 2009 20:56:39 schrieb Michael 'Mickey' Lauer: On Wednesday 29 April 2009 20:47:23 Marcel wrote: Should be fast, but how would you control that with a touchscreen (- mouse)? gpm. Oh. I didn't even think of that may working... *g* -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
