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.com>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?
>
> 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
