Re: [e-users] Really don't know how to start with

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Thu, 2 May 2013 01:35:47 +0800 hYde <hyd...@gm...> 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 <ra...@ra...>wrote:
> 
> > On Wed, 1 May 2013 22:59:43 +0800 hYde <hyd...@gm...> 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 <ra...@ra...
> > >wrote:
> > >
> > > > On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri
> > > > <bar...@pr...> said:
> > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > > On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler <
> > ra...@ra...
> > > > >wrote:
> > > > >
> > > > > > On Tue, 30 Apr 2013 18:03:21 +0800 hYde <hyd...@gm...> 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: bar...@gm...
> > > > > 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
> > > > > enl...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> > > > >
> > > >
> > > >
> > > > --
> > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > --------------
> > > > The Rasterman (Carsten Haitzler)    ra...@ra...
> > > >
> > > >
> > >
> > ------------------------------------------------------------------------------
> > > 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
> > > enl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> > >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    ra...@ra...
> >
> >

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...