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 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
>
--
------------- 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
