Re: [e-users] Really don't know how to start with
Hello, On Tue, Apr 30, 2013 at 9:48 PM, hYde hyde@gmail.com wrote: that's why I explicitly removed Edje. Edje pulls too much, and will not aggregate that much value for the BIOS case (show menu and similar). Of course it would be nice to have a complete environment with Elementary and all, but I don't think it's doable without LOTS of effort, so stick with Evas first -- particularly pre-Eina Evas. I wouldn't recommend to go so far in the past. EFL 1.7 is the most portable version we did. A lot of effort went in to make it portable. That why exotic, evil and escape where possible with it. Sadly the merge in 1.8 has reduced that portability and it will take month before it get back to the same level. Windows build for EFL was working until a few days ago (Some header mess did bork it). So back to the subject, use 1.7, best portability ever. If you want to go up to ecore, look at what evil, escape and exotic do and do provide a limited wrapper there. Exotic should make your life easier for those kind of wrapper. In Ecore you can override the select inside it and so handle manually a wrapper of it in your own ecore_mybios that could be initialised by the right ecore_evas. Porting to a limited OS that wasn't posix, provided a framebuffer, some file I/O and a way to get event and wait for some time took me 1 month on 1.7. I do think that someone without any experience in EFL will take much more. So start building layer by layer and you need to understand the build system. Play with EFL on Linux and on Windows (I am going to fix again the windows build and I hope to soon get a bot to spank whoever break stuff again). Maybe I misunderstood about Edje, I thought that was some kind of C like meta-language layer to seperate UI and code. I'll try to use pre-Eina Evas though I still couldn't get my Win7 + MinGW right (lots of autotool error) For EFL 1.8 if you want to help on making it back as portable: https://phab.enlightenment.org/w/windows/ For EFL 1.7, https://trac.enlightenment.org/e/wiki/EFLWindowsXP . I should start writing a doc on how to port EFL to your exotic environment. I hope to push back exotic in 1.9 and have a more portable system again. If you need to strip the libraries, I'd recommend to remove the following chunks from Evas: - Gradients: it was removed in current Evas, but the pre-Eina still contained it with lots of useless code; - Textblock: if you don't need text markup or multi-line text, you can remove this and lots of code. I'l need Textblock for further usage. Building all EFL 1.7 with dependencies to the minimum and including up to Elementary will use 5MB. That is with a static build. And of course choose the minimum set of engines and options, I'm not sure the bootloader can use MMX/SSE, then you can compile out those with ./configure flags. Yes, we have SSE2, which is for security check, grab them libs to use will be okay. In UEFI environment we have events and notify, basic Bit blit function to access raw framebuffer, timers..etc. Not much like the OS but will do some good. Do you have a doc to the API you have in that state ? NOTE: which hardware are you using this? It seems like a nice hobby project I'd help on weekends, but I'd need to have a way to test :-) I use coreboot or UDK2010 ( http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) , the later has some NT32 simulation, which can use as a basic test on host machines. But if you are talking about real platform, I almost have everything because I work in a vendor. Not familiar to all of this (toolchain, environment and I don't know how to find E17's writing guide) I have to apologize :( , so t is hard for me to catch up all the information. But my target is to port a open-sourced UI lib for BIOS to use, not only in setup menus, but also some UEFI shell applications, it will magically reduce a lot of working hour, for BIOS / Driver developers to work only on the function, not to take care the unawareness of the UI. I do still believe that the cost to go up to Ecore is not much higher than to stop at Evas and once you have Ecore, Edje and Elementary will come for free. I should really write that doc how to port EFL... -- Cedric BAIL -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Hi,
On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said:
Since my BIOS has only about 8MB of space, I take Evas + Edje.
you'll need ecore, eet and eina too then. (well some of ecore).
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
well you still need eina anyway. so edje adds eet and ecore (ecore, ecore-imf,
ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly
small, and ecore-evas pulls in ecore-con and ecore-ipc.
there likely will be the need for ecore anyway for a mainloop etc. so i'd guess
it doesnt end up too bad, and relying on eet as a way of nicely encapsulating
data into a single file will be helpful. lossy compression for images with
alpha (that jeg doesnt do and png doesnt do) will save you space too if you use
such image data much. so in the end i am not sure it will be too bad.
elementary thought makes things a whole new level.
May I ask what is pre-merge?
efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped
our
dependencies. 1.8 is not out yet.. but release is scheduled for end of may.
Yes, but I'd strongly encourage to find out the Evas version before Eina
was introduced. Then you don't need Eina, just Evas types that were built
in (saves a lib to care and some Kb in the final image).
With Evas all you need is to create an engine similar to FB, give Evas
the framebuffer (pixels) to paint and that's it. If you can configure your
FB, then it should be pretty simple to get it running. You can copy
Expedite's model, that is basically a loop:
while (1) {
event = get_event();
if (event) process_event(event);
evas_render_updates(evas);
}
from process_event() you can arrange your objects as you wish (create,
move, resize...), evas_render_updates() will take care to draw them to
output. Eventually you'd have to ask the FB to update itself, depends on
your setup.
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
NOTE: which hardware are you using this? It seems like a nice hobby project
I'd help on weekends, but I'd need to have a way to test :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] E17 + Full Screen Flash + Secondary Screen
On Sat, 20 Apr 2013 22:28:21 -0500 Jeff Hoogland jeffhoogl...@linux.com said: This could very well just be a flash issue (as I haven't tested it on another DE and flash is crappy software). But I was wondering if anyone has found a method of running full-screen flash video on a secondary screen and mousing off of that monitor without losing the full screen on the video? Right now using E17.2.1 when I mouse off the secondary screen onto my other monitor the video stops playing as full screen. If this isn't possible currently is this something E17 could accomplish or is this just a limitation of the awful software that is flash? flash itself just closes its fullscreen window. there isn't much we can do about it. -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
wow... Looks like I need to dig in more to study more stuff :(
Is it possible to reduce code size to about 400~700KB after all this?
On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Hi,
On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said:
Since my BIOS has only about 8MB of space, I take Evas + Edje.
you'll need ecore, eet and eina too then. (well some of ecore).
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary
and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
well you still need eina anyway. so edje adds eet and ecore (ecore,
ecore-imf,
ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly
small, and ecore-evas pulls in ecore-con and ecore-ipc.
there likely will be the need for ecore anyway for a mainloop etc. so i'd
guess
it doesnt end up too bad, and relying on eet as a way of nicely
encapsulating
data into a single file will be helpful. lossy compression for images with
alpha (that jeg doesnt do and png doesnt do) will save you space too if
you use
such image data much. so in the end i am not sure it will be too bad.
elementary thought makes things a whole new level.
May I ask what is pre-merge?
efl 1.7.x ... from efl 1.8 we have a single build tree and we have
upped
our
dependencies. 1.8 is not out yet.. but release is scheduled for end of
may.
Yes, but I'd strongly encourage to find out the Evas version before Eina
was introduced. Then you don't need Eina, just Evas types that were built
in (saves a lib to care and some Kb in the final image).
With Evas all you need is to create an engine similar to FB, give Evas
the framebuffer (pixels) to paint and that's it. If you can configure
your
FB, then it should be pretty simple to get it running. You can copy
Expedite's model, that is basically a loop:
while (1) {
event = get_event();
if (event) process_event(event);
evas_render_updates(evas);
}
from process_event() you can arrange your objects as you wish (create,
move, resize...), evas_render_updates() will take care to draw them to
output. Eventually you'd have to ask the FB to update itself, depends on
your setup.
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
NOTE: which hardware are you using this? It seems like a nice hobby
project
I'd help on weekends, but I'd need to have a way to test :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? compressed or uncompressed? evas minus all dependencies and zero modules in current dev is 1.4m once stripped. its 570k when compressed (so assuming cramfs or so then its in your size range), but thats just evas. remember this is also with all features on/built in and -O2 with optimization. -Os may do better. so evas+eina alone come out at 744kb compressed (again assuming cramfs) (1.8m uncompressed). this happens to include buffer engine, a whole bunch of image format loaders and more. chances are u can shave off maybe 100-200k by configuring off things (maybe 100-200k compressed savings). problem is at least with current dev (and 1.8) you need to modify configure.ac - we dont have a bios profile currently. :) now if i go disable a bunch of loaders in configure.ac specifically and use -Os... and i compress things down.. including eet suport for loaders, jpeg and png loader, freetype support no fontconfig), frameubuffer enigne (and buffer engine) with small dither array, with eina, eet, evas, and eo... uncompressed its 1.6m, compressed 636kb. thats enough stuff there to do display, build a ui yourself (place text, images, rects etc.), handle input when fed in from code (and route to the right target) load png's and jpgs (assuming u provide libpng and libjpeg), render ttf text with anti-aliasing, handle all common/sane bit depths (from monochrome up to 24bpp), lots of other fun rendering stuff (smooth interpolated scaling), scene graph, text layout and formatting with markup and unicode (no RTL support though), and being able to pack data resources into single eet files for access via key values. you will need in addition libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats actually about it. you dont need much more. so we can get down to about 640kb plus some external deps. remove png and jpeg loader.. if u want to rely on eet entirely and u can save maybe 20k compressed. i am sure we could do there things to trim more, but not a hell of a lot. so is 640k compressed (out of 8mb) worth using for a pretty complete display/rendering subsystem including high level text formatting, image decoding rendering, event routing etc? if i include the deps (freetype, libjpeg and libpng - i am skipping zlib, libc etc. as i assume these will be there no matter what you use for display), your entire footprint (compressed) is 1.1M for everything you need to display. input is still your problem. :) as it creating widgets and doing layout. you dont need full blown widgets for a bios i imagine... i'd say 1.1m of 8mb is a perfectly adequate footprint. you can probably get the rest (kernel, libc base etc) down to about 3m, so as such u'll probably have about 4.. maybe 5m for the core os and what not. that leaves u with 3m for the bios app and data files (jpg's, png's etc.). am i far off the mark here? btw your project is rather fascinating. :) On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Hi, On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said: Since my BIOS has only about 8MB of space, I take Evas + Edje. you'll need ecore, eet and eina too then. (well some of ecore). that's why I explicitly removed Edje. Edje pulls too much, and will not aggregate that much value for the BIOS case (show menu and similar). Of course it would be nice to have a complete environment with Elementary and all, but I don't think it's doable without LOTS of effort, so stick with Evas first -- particularly pre-Eina Evas. well you still need eina anyway. so edje adds eet and ecore (ecore, ecore-imf, ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly small, and ecore-evas pulls in ecore-con and ecore-ipc. there likely will be the need for ecore anyway for a mainloop etc. so i'd guess it doesnt end up too bad, and relying on eet as a way of nicely encapsulating data into a single file will be helpful. lossy compression for images with alpha (that jeg doesnt do and png doesnt do) will save you space too if you use such image data much. so in the end i am not sure it will be too bad. elementary thought makes things a whole new level. May I ask what is pre-merge? efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped our dependencies. 1.8 is not out yet.. but release is scheduled for end of may. Yes, but I'd strongly encourage to find out the Evas version before Eina was introduced. Then you don't need Eina, just Evas types that were built in
Re: [e-users] Really don't know how to start with
On 01/05/2013 18:00, Carsten Haitzler (The Rasterman) wrote: On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? [snip awesome technical stuff] btw your project is rather fascinating. :) I'll say :-) Horribly OT of course but that was my first thought too - a decent looking boot environment driven by EFL? How cool is that! -- Alan McKinnon alan.mckin...@gmail.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. On Thu, May 2, 2013 at 12:00 AM, Carsten Haitzler ras...@rasterman.comwrote: On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? compressed or uncompressed? evas minus all dependencies and zero modules in current dev is 1.4m once stripped. its 570k when compressed (so assuming cramfs or so then its in your size range), but thats just evas. remember this is also with all features on/built in and -O2 with optimization. -Os may do better. so evas+eina alone come out at 744kb compressed (again assuming cramfs) (1.8m uncompressed). this happens to include buffer engine, a whole bunch of image format loaders and more. chances are u can shave off maybe 100-200k by configuring off things (maybe 100-200k compressed savings). problem is at least with current dev (and 1.8) you need to modify configure.ac - we dont have a bios profile currently. :) now if i go disable a bunch of loaders in configure.ac specifically and use -Os... and i compress things down.. including eet suport for loaders, jpeg and png loader, freetype support no fontconfig), frameubuffer enigne (and buffer engine) with small dither array, with eina, eet, evas, and eo... uncompressed its 1.6m, compressed 636kb. thats enough stuff there to do display, build a ui yourself (place text, images, rects etc.), handle input when fed in from code (and route to the right target) load png's and jpgs (assuming u provide libpng and libjpeg), render ttf text with anti-aliasing, handle all common/sane bit depths (from monochrome up to 24bpp), lots of other fun rendering stuff (smooth interpolated scaling), scene graph, text layout and formatting with markup and unicode (no RTL support though), and being able to pack data resources into single eet files for access via key values. you will need in addition libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats actually about it. you dont need much more. so we can get down to about 640kb plus some external deps. remove png and jpeg loader.. if u want to rely on eet entirely and u can save maybe 20k compressed. i am sure we could do there things to trim more, but not a hell of a lot. so is 640k compressed (out of 8mb) worth using for a pretty complete display/rendering subsystem including high level text formatting, image decoding rendering, event routing etc? if i include the deps (freetype, libjpeg and libpng - i am skipping zlib, libc etc. as i assume these will be there no matter what you use for display), your entire footprint (compressed) is 1.1M for everything you need to display. input is still your problem. :) as it creating widgets and doing layout. you dont need full blown widgets for a bios i imagine... i'd say 1.1m of 8mb is a perfectly adequate footprint. you can probably get the rest (kernel, libc base etc) down to about 3m, so as such u'll probably have about 4.. maybe 5m for the core os and what not. that leaves u with 3m for the bios app and data files (jpg's, png's etc.). am i far off the mark here? btw your project is rather fascinating. :) On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Hi, On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said: Since my BIOS has only about 8MB of space, I take Evas + Edje. you'll need ecore, eet and eina too then. (well some of ecore). that's why I explicitly removed Edje. Edje
Re: [e-users] Really don't know how to start with
On Wed, May 1, 2013 at 2:35 PM, hYde hyde@gmail.com wrote: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. sure! once you're fine with that we can help you to get it into upstream-able form, like a new platform efi that can setup the set of loaders/engines for the user. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Thu, 2 May 2013 01:35:47 +0800 hYde hyde@gmail.com said: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. actually i don't think we want a branch. we're happy to work with you and make what you need a profile. right now basically we have a full bloated profile. you want something much more stripped down. you MAY also want to use ecore, ecore_fb and ecore_evas too to save dealing with mainloops, the fb device handling, input (kbd/mouse etc.) (well this is linux kernel fbcon etc.) - but this will add more to what i quoted above, but won't double it. another few hundred kb, but now your mainloop and input infra is done too. if you don't need png then of course that saves a little bit too (and eet itself handles lossless images with alpha as well as lossy, tho eet does still need zlib and libjpeg). i think the best thing you can do is go through some iterating of modifying configure.ac and turning off what you don't need and making it a profile, then feeding that back to us and so on - we can advise you on the next step etc. and pretty much end up with a lean result and it'll then become probably a few simple configure options and then some post-install script that maybe strips out a few extra build outputs like .la files, includes and other things you wont need at runtime. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. On Thu, May 2, 2013 at 12:00 AM, Carsten Haitzler ras...@rasterman.comwrote: On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? compressed or uncompressed? evas minus all dependencies and zero modules in current dev is 1.4m once stripped. its 570k when compressed (so assuming cramfs or so then its in your size range), but thats just evas. remember this is also with all features on/built in and -O2 with optimization. -Os may do better. so evas+eina alone come out at 744kb compressed (again assuming cramfs) (1.8m uncompressed). this happens to include buffer engine, a whole bunch of image format loaders and more. chances are u can shave off maybe 100-200k by configuring off things (maybe 100-200k compressed savings). problem is at least with current dev (and 1.8) you need to modify configure.ac - we dont have a bios profile currently. :) now if i go disable a bunch of loaders in configure.ac specifically and use -Os... and i compress things down.. including eet suport for loaders, jpeg and png loader, freetype support no fontconfig), frameubuffer enigne (and buffer engine) with small dither array, with eina, eet, evas, and eo... uncompressed its 1.6m, compressed 636kb. thats enough stuff there to do display, build a ui yourself (place text, images, rects etc.), handle input when fed in from code (and route to the right target) load png's and jpgs (assuming u provide libpng and libjpeg), render ttf text with anti-aliasing, handle all common/sane bit depths (from monochrome up to 24bpp), lots of other fun rendering stuff (smooth interpolated scaling), scene graph, text layout and formatting with markup and unicode (no RTL support though), and being able to pack data resources into single eet files for access via key values. you will need in addition libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats actually about it. you dont need much more. so we can get down to about 640kb plus some external deps. remove png and jpeg loader.. if u want to rely on eet entirely and u can save maybe 20k compressed. i am sure we could do there things to trim more, but not a hell of a lot. so is 640k compressed (out of 8mb) worth using for a pretty complete display/rendering subsystem including high level text formatting, image
