Re: [E-devel] X11 dependencies hardcoded in ecore_evas
Hi Carsten, Thanks for all the time you take, answering questions about glamo in this list, i really appreciate it. I am sure i don't understand half of the technology bottle necks that the glamo has, but if the limit is 512x512 for 3D and 2D, would it be possible to just use 480x512 on the FR? or even 480x480? 480x512 would leave +/- 12 mm screen unused, but i think that could be a fair trade-off if the rest of the screen is much faster ( for video and such ) And perhaps the unused space could be used as status bar or top shelf. Is this at all possible? i have no deep knowledge about graphic chips, so the simpler the answer, there more likely it is that i will understand it :-) Kind regards, Ed On 04/18/2010 03:53 AM, Carsten Haitzler (The Rasterman) wrote: On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil m...@mobiphil.com said: Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. dfb isnt common to fb and x11 - it is an enitre display system of its own. there is a specific xdirectfb server on top of dfb. but it is not a common component. i think you misunderstand directfb... :) but - you'd need all the acceleration written and even then the chip simply is not capable of many ops you need or it makes them needlessly complex (you will need to go via the 3d unit and that limits all pixel primitives to 256x256 as a source and output cant be more than 512x512 for any buffer - you'd need to do complex tiling of all input and output and that will wreak havoc on things like transforms/scaling to make it look right - and effectively make it impossible). trust me - have full hw docs. had them from the day i started with glamo long before gta02 came out. after some reading i went from excited to despondent. glamo does not live up to what it seems to appear reading its checklist features. sure - it's possible to go accelerate some things and get some benefit. for each of those you now have a downside as u need a software fallback for the ones you can't - and... those now get more complex WITH more overhead. you make operation a 2x faster and operation b gets half the speed. and so on. my bet is that even if you do it all as optimally as possible with glamo+gta02 arch - you will have spent a mountain of effort going nowhere. ie not be able better in general. some things improved, some worse. and now you have a monster of complexity that has no future. glamo is a dead end chip. openmoko a dead end product line. a source base that will not be useful for any future hardware developed nor even todays hardware. the future is mostly opengl-es2 based with the ability to punt off preparation pipeline stages to multiple cpu cores - or if you are lucky, some dsp cores. as such even without this punting off to multiple cores, with gl-es2 - things work damned well - silky smooth on a modern soc. thats including rendering everything at 32bpp, compositor in x11, and more. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. :) But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... i disagree. how do u think you get a vkbd up on screen separate to the app, or the top-shelf (place for app name, battery, reception etc.) ? i think you are under the illusion also that somehow windows have some massive overhead in x11 - they don't - they are simply clipping regions for doing draws - that go to the framebuffer (with compositing - different story with redirection but you end up producing the same design no matter the display system). clip regions are just a list of rectangles only draw within this region when drawing. you ask x11 to do the drawing to the fb for you to make sure all of this is co-ordinated and the clip regions obeyed. x11 is also asynchronous and buffers so its NOT: draw thing, wait for x, x sends draw done,...
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
On Sun, 18 Apr 2010 11:22:24 +0200 Ed Kapitein e...@kapitein.org said: Hi Carsten, Thanks for all the time you take, answering questions about glamo in this list, i really appreciate it. I am sure i don't understand half of the technology bottle necks that the glamo has, but if the limit is 512x512 for 3D and 2D, would it be possible to just use 480x512 on the FR? or even 480x480? 480x512 would leave +/- 12 mm screen unused, but i think that could be a fair trade-off if the rest of the screen is much faster ( for video and such ) And perhaps the unused space could be used as status bar or top shelf. Is this at all possible? i have no deep knowledge about graphic chips, so the simpler the answer, there more likely it is that i will understand it :-) i didn't look that far. if you can't use all of the tiny 2.8 u have - it's useless. imho. waste of time. you could try rendering in multiple passes with 2 buffers and piece them together i guess - but by that stage it was plain - glamo wasnt intended for vga. qvga was its intended resolution. run at qvga and you'll be ok. but that will be the case with software rendering too. Kind regards, Ed On 04/18/2010 03:53 AM, Carsten Haitzler (The Rasterman) wrote: On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil m...@mobiphil.com said: Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. dfb isnt common to fb and x11 - it is an enitre display system of its own. there is a specific xdirectfb server on top of dfb. but it is not a common component. i think you misunderstand directfb... :) but - you'd need all the acceleration written and even then the chip simply is not capable of many ops you need or it makes them needlessly complex (you will need to go via the 3d unit and that limits all pixel primitives to 256x256 as a source and output cant be more than 512x512 for any buffer - you'd need to do complex tiling of all input and output and that will wreak havoc on things like transforms/scaling to make it look right - and effectively make it impossible). trust me - have full hw docs. had them from the day i started with glamo long before gta02 came out. after some reading i went from excited to despondent. glamo does not live up to what it seems to appear reading its checklist features. sure - it's possible to go accelerate some things and get some benefit. for each of those you now have a downside as u need a software fallback for the ones you can't - and... those now get more complex WITH more overhead. you make operation a 2x faster and operation b gets half the speed. and so on. my bet is that even if you do it all as optimally as possible with glamo+gta02 arch - you will have spent a mountain of effort going nowhere. ie not be able better in general. some things improved, some worse. and now you have a monster of complexity that has no future. glamo is a dead end chip. openmoko a dead end product line. a source base that will not be useful for any future hardware developed nor even todays hardware. the future is mostly opengl-es2 based with the ability to punt off preparation pipeline stages to multiple cpu cores - or if you are lucky, some dsp cores. as such even without this punting off to multiple cores, with gl-es2 - things work damned well - silky smooth on a modern soc. thats including rendering everything at 32bpp, compositor in x11, and more. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. :) But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... i disagree. how do u think you get a vkbd up on screen separate to the app, or the top-shelf (place for app name, battery, reception etc.) ? i think you are under the illusion also that somehow windows have some massive
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
The target device of my experiments is the openmoko. For this reason I put the openmoko-dev list to cc, maybe somebody is interested there. oddd. lossy uses libjpeg. BOTH use eet. eet uses jpeg compression for lossy and zlib for comp. there is also raw that doesnt compress at all. well.. then I do not understand why it crashes I use libjpeg.7 .. Anyway it is not the main point now. I changed to COMP and it works. anyway ... my experiment was not really successful... support for sdl and directfb seems to be broken at elementary lib level... tried to add myself the different cases in elm_wind_add and brohters, but did not work, I found a a patch on a a thread here to make directfb working, but it did not. The intention of my experience was to see if evas/ecore would behave better on top of a potentially accelerated directfb backend. However as far I understood from the code evas/ecore would have zero benefit from a 2d accelerated directfb driver. My question is: 1. as was reading on some other threads that one wants to get rid of Xrender. Would however efl be able to use some 2d acceleration (blit from videa ram to videa ram, draw/fill rectangle etc.) 2. is there any interface to inject some 2d accelerated code into the fb driver? For example the most annoying on openmoko freerunner is slow scrolling. For example your map example becomes the same sluggish. This could be probably solved by scrolling through a temp invisible video memory buffer. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
On Sat, 17 Apr 2010 20:27:06 +0200 mobi phil m...@mobiphil.com said: The target device of my experiments is the openmoko. For this reason I put the openmoko-dev list to cc, maybe somebody is interested there. oddd. lossy uses libjpeg. BOTH use eet. eet uses jpeg compression for lossy and zlib for comp. there is also raw that doesnt compress at all. well.. then I do not understand why it crashes I use libjpeg.7 .. Anyway it is not the main point now. I changed to COMP and it works. ess is there is something my guess odd in your build environment - i assume its some sort of cross-compile setup. as suc openembedded builds a non-x11 efl as native binaries to get to have edje_cc work. and it all worked last i looked. anyway ... my experiment was not really successful... support for sdl and directfb seems to be broken at elementary lib level... tried to add myself the different cases in elm_wind_add and brohters, but did not work, I found a a patch on a a thread here to make directfb working, but it did not. if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. for that matter if its sdl on x11 - evas's own software-x11 layer will do much better. sdl doesnt offer anything here. opengl support for sdl doesnt do anything accelerated either except set up and sdl buffer with a gl context attached - all the acceleration comes from using opengl. as such directfb is little-loved and not maintained. as and engine. sdl is being loved/used on the palm pre (webos) and it works there, so no idea what's up with you there, but they seem to be having some fine success. The intention of my experience was to see if evas/ecore would behave better on top of a potentially accelerated directfb backend. However as far I understood from the code evas/ecore would have zero benefit from a 2d accelerated directfb driver. in theory they would - fact is directfb won't be accelerated. all the rendering is done by evas - ecore isn't involved there beyond providing events and mainloop. but dfb is not maintained and behind. as such it's very little used in real life and not worth the trouble. nothing dfb does can't be done in x11. My question is: 1. as was reading on some other threads that one wants to get rid of Xrender. Would however efl be able to use some 2d acceleration (blit from videa ram to videa ram, draw/fill rectangle etc.) useless when all the other ops are slow. waste of time and effort. i've been wasting and waiting for a decade. i've had enough of it. xrender engine is already partly broken as it doesn't support some of the modern things like map. note that on glamo xrender als is not accelerated and in fact is not able to be properly accelerated and you will have lots of software fallbacks doing read/modify/write across the anemic video bus to glamo. i've been here. long ago. i have the full glamo hw docs. i read them in entirety and made decisions off that. what you see in the checkbox list of features vs what glamo actually does makes you think again about it as a useful chip. 2. is there any interface to inject some 2d accelerated code into the fb driver? no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you will create something very complex that is actually no faster. you will win on operation a and then lose on operation b. glamo's problem is its operations are asymmetric. you can use rgba as src - but never create rgba as a dest - only rgb565. pointless for intermediate buffers than now need fallbacks. also leads to cumulative rendering error when dropping down to rgb565 and quality will suffer badly. For example the most annoying on openmoko freerunner is slow scrolling. For example your map example becomes the same sluggish. This could be probably solved by scrolling through a temp invisible video memory buffer. the freerunner itself is slow - it's a very poor piece of hardware. it''s the worst one i've ever working with in a decade. the original ipaq3660 i worked on at the start of my embedded games was far better performance-wise. you can polish a turd - but a turd is still a turd. all you will do is create a mess that is simply not maintainable in the long run in the name of a broken bit of hardware. been there. done that. :) scrolling in efl is a redraw. why? because doing otherwise is nuts - especially if you want to support things like opengl. also in the need when people want their translucent list items with static bg's etc. - you do redraws anyway. you can cut out some redraw with intermediate buffers - but then you pay a price in memory usage. you can do this via map... but.. gasp.. that needs an intermediate buffer and... glammo cant generate those other than in
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... I wonder if anybody from the openmoko community can confirm that efl would be faster with accelerated X, what I doubt... probably the opposite, at least what concerns loading times, as less binary has to cross the narrow channel. as such directfb is little-loved and not maintained. as and engine. sdl is being loved/used on the palm pre (webos) and it works there, so no idea what's up with you there, but they seem to be having some fine success. Honestly I just discovered, that you guys do a superset of directfb features. And directfb did not evolve the last 4-5 years since I keep an eye on it.. The intention of my experience was to see if evas/ecore would behave better on top of a potentially accelerated directfb backend. However as far I understood from the code evas/ecore would have zero benefit from a 2d accelerated directfb driver. Sorry.. what do you mean as far as I understood ... you did not write that part? in theory they would - fact is directfb won't be accelerated. all the rendering is done by evas - ecore isn't involved there beyond providing events and mainloop. but dfb is not maintained and behind. as such it's very little used in real life and not worth the trouble. nothing dfb does can't be done in x11. My question is: 1. as was reading on some other threads that one wants to get rid of Xrender. Would however efl be able to use some 2d acceleration (blit from videa ram to videa ram, draw/fill rectangle etc.) useless when all the other ops are slow. waste of time and effort. i've been wasting and waiting for a decade. i've had enough of it. xrender engine is already partly broken as it doesn't support some of the modern things like map. note that on glamo xrender als is not accelerated and in fact is not able to be properly accelerated and you will have lots of software fallbacks doing read/modify/write across the anemic video bus to glamo. i've been here. long ago. i have the full glamo hw docs. i read them in entirety and made decisions off that. what you see in the checkbox list of features vs what glamo actually does makes you think again about it as a useful chip. 2. is there any interface to inject some 2d accelerated code into the fb driver? no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you will create something very complex that is actually no faster. you will win on operation a and then lose on operation b. glamo's problem is its operations are asymmetric. you can use rgba as src - but never create rgba as a dest - only rgb565. pointless for intermediate buffers than now need fallbacks. also leads to cumulative rendering error when dropping down to rgb565 and quality will suffer badly. hm... did not know this issue with rgb565... You mean I cannot blit from an unvisible VRAM area to the visible one? The idea was, when scrolling (like when moving maps) to redraw only new parts, and the rest do by two copies inside the VRAM. I wonder if there is sthg. similar implemented for scrolling in Xglamo.. For example the most annoying on openmoko freerunner is slow scrolling. For example your map example becomes the same sluggish. This could be probably solved by scrolling through a temp invisible video memory buffer. the freerunner itself is slow - it's a very poor piece of hardware. We know that... And the most annoying is the scrolling when everything has to be redrawn, whereas only parts should be. Well.. in the worst case I will understand that it is impossible (hower it does not seem to be).. scrolling in efl is a redraw. why? because doing otherwise is nuts - especially if you want to support things like
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil m...@mobiphil.com said: Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. dfb isnt common to fb and x11 - it is an enitre display system of its own. there is a specific xdirectfb server on top of dfb. but it is not a common component. i think you misunderstand directfb... :) but - you'd need all the acceleration written and even then the chip simply is not capable of many ops you need or it makes them needlessly complex (you will need to go via the 3d unit and that limits all pixel primitives to 256x256 as a source and output cant be more than 512x512 for any buffer - you'd need to do complex tiling of all input and output and that will wreak havoc on things like transforms/scaling to make it look right - and effectively make it impossible). trust me - have full hw docs. had them from the day i started with glamo long before gta02 came out. after some reading i went from excited to despondent. glamo does not live up to what it seems to appear reading its checklist features. sure - it's possible to go accelerate some things and get some benefit. for each of those you now have a downside as u need a software fallback for the ones you can't - and... those now get more complex WITH more overhead. you make operation a 2x faster and operation b gets half the speed. and so on. my bet is that even if you do it all as optimally as possible with glamo+gta02 arch - you will have spent a mountain of effort going nowhere. ie not be able better in general. some things improved, some worse. and now you have a monster of complexity that has no future. glamo is a dead end chip. openmoko a dead end product line. a source base that will not be useful for any future hardware developed nor even todays hardware. the future is mostly opengl-es2 based with the ability to punt off preparation pipeline stages to multiple cpu cores - or if you are lucky, some dsp cores. as such even without this punting off to multiple cores, with gl-es2 - things work damned well - silky smooth on a modern soc. thats including rendering everything at 32bpp, compositor in x11, and more. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. :) But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... i disagree. how do u think you get a vkbd up on screen separate to the app, or the top-shelf (place for app name, battery, reception etc.) ? i think you are under the illusion also that somehow windows have some massive overhead in x11 - they don't - they are simply clipping regions for doing draws - that go to the framebuffer (with compositing - different story with redirection but you end up producing the same design no matter the display system). clip regions are just a list of rectangles only draw within this region when drawing. you ask x11 to do the drawing to the fb for you to make sure all of this is co-ordinated and the clip regions obeyed. x11 is also asynchronous and buffers so its NOT: draw thing, wait for x, x sends draw done,... draw next thing, wait for x, x sends draw done... that'd be stupid. you CAN write code that works like that with x11 - but then i'd shoot you to save the world a little more oxygen as you'd be using up too much of it. :) (joking! but you would be stupid) :) in x11 (with efl) it's like this: prepare stuff locally, send draw, send draw, send draw, prepare locally, send draw, send draw, send draw, frame finished at frame finish it waits for x (to syncronise and make sure app doesnt go and queue many frames ahead of what x has managed to draw/copy to the screen). all those prepare/send happens in the app without context switching to x11 - there is no overhead compared to anything fb oriented. I wonder if anybody from the openmoko community can confirm that efl would be faster with accelerated X, what I doubt... probably the opposite, at
