On Sat, Oct 10, 2009 at 02:51:12AM +1100, Carsten Haitzler wrote:
> On Fri, 9 Oct 2009 17:14:30 +0200 Marc Andre Tanner <openm...@brain-dump.org>
> said:
>
> > On Sat, Oct 10, 2009 at 12:14:02AM +1100, Carsten Haitzler wrote:
> > > On Fri, 9 Oct 2009 13:00:12 +0200 Marc Andre Tanner
> > > <openm...@brain-dump.org> said:
> > > > On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote:
> > > > > On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner
> > > > > > - GUI based on elementary with framebuffer support?
> > > > As a said this is without any optimization, no special compilation
> > > > flags,
> > > > nothing. I should try to link everything statically which has 2 main
> > > > advantages:
> > >
> > > you will save very little with things like -Os. maybe 5-10%. on a good
> > > day.
> > > that ballpark.
> >
> > Newer gcc's support whole build optimization that is you basically compile
> > an
> > entire project with one gcc inovacation. It will use lots of memory at
> > compile
> > time but because it has more knowledge about the whole project and how the
> > different parts work together it can use more advanced optimization
> > techniques
> > which should result in smaller/more efficient code. Anyway this is the
> > theory
> > I will see how this works in practice. There are enough other things to
> > improve before I even want to start with this kind of thing.
>
> thats possible when making 1 executable. it's not possible to strip shared
> libraries of code "not used by apps" as these are completely separate builds,
> elements and more. example - evas will hve code for handling 8bit color
> displays. nothing will ever make gcc get rid of it ... unless you statially
> compile. even then it wont as evas runtime will chose conversion code based on
> screen configuration... which gcc doesnt know. this is why evas has so many
> --enable and --disable options for configure - uc an disable vast blobs of
> support for things you dont need - like 8 bit and 24/32, 15bit, 12bit and
> 18bit
> displays. look at configure --help for evas.
Yeah I have read that and evas README unfortunately I don't really know what is
needed and what not. I currently configure evas like this:
--enable-fb \
--disable-directfb \
--disable-sdl \
--enable-buffer \
--disable-evas-cserve \
--disable-software-ddraw \
--disable-software-qtopia \
--disable-software-xlib \
--disable-software-16-x11 \
--disable-software-xcb \
--disable-gl-x11 \
--disable-xrender-x11 \
--disable-xrender-xcb \
--disable-glitz-x11 \
--enable-image-loader-eet \
--disable-image-loader-edb \
--disable-image-loader-gif \
--disable-image-loader-png \
--disable-image-loader-pmaps \
--enable-image-loader-jpeg \
--disable-image-loader-tiff \
--disable-image-loader-xpm \
--disable-image-loader-svg \
--enable-cpu-c \
--disable-evas-magic-debug \
--disable-fontconfig \
--enable-font-loader-eet \
--disable-scale-sample \
--enable-scale-smooth \
--enable-convert-yuv \
--enable-small-dither-mask \
--disable-no-dither-mask \
--disable-convert-8-rgb-332 \
--disable-convert-8-rgb-666 \
--disable-convert-8-rgb-232 \
--disable-convert-8-rgb-222 \
--disable-convert-8-rgb-221 \
--disable-convert-8-rgb-121 \
--disable-convert-8-rgb-111 \
--enable-convert-16-rgb-565 \
--disable-convert-16-rgb-555 \
--disable-convert-16-rgb-444 \
--disable-convert-16-rgb-ipq \
--enable-convert-16-rgb-rot-0 \
--enable-convert-16-rgb-rot-90 \
--disable-convert-16-rgb-rot-180 \
--enable-convert-16-rgb-rot-270 \
--enable-convert-24-rgb-888 \
--enable-convert-24-bgr-888 \
--enable-convert-32-rgb-8888 \
--enable-convert-32-rgbx-8888 \
--enable-convert-32-bgr-8888 \
--enable-convert-32-bgrx-8888 \
--enable-convert-32-rgb-rot-0 \
--enable-convert-32-rgb-rot-90 \
--disable-convert-32-rgb-rot-180 \
--enable-convert-32-rgb-rot-270 \
--disable-doc \
--without-x &&
Could I disable some more settings? Another thing which worries me a little is
that the dialog application segfaults in evas_object_color_set if evas is
compiled with the folowing CFLAGS:
-Os -pipe -march=armv4t -mtune=arm9tdmi
I disabled these for now. Have you an idea what the problem might be?
> > > > - the linker should be able to remove any code paths which aren't
> > > > actually used.
> > >
> > > not from share libraries. only if you statically compile with executables.
> >
> > That's what I meant. I would statically compile my bootmenu app and just
> > copy
> > that over to the rootfs.
>
> then you wont need libevas etc. - it'd end up being a single binary.
>
> > > > - at runtime the dynamic linker doesn't have to load all the libraries
> > > > (less I/O + code relocation) which should speed up the application
> > > > start.
> > > >
> > > > > > I am not familiar with the EFL code base but what I have seen
> > > > > > so far seems like it isn't really optimized for size. So there
> > > > > > could be some potential although it would require some work and
> > > > > > upstream approval.
> > > > > >
> > > > > > Maybe the idea to use elementary is overkill but what are the
> > > > > > alternatives?
> > > > >
> > > > > i'll shime in here. yes. efl has grown over the years, and well - the
> > > > > more functionality you want, the more space it will take. if you are
> > > > > hell-bent on smallest size you possibly would just write your own fb
> > > > > gui that is very simple and ugly (with white/black boxes for
> > > > > example).
> > > >
> > > > I know that elf provides a lot of features and is rather small for what
> > > > it
> > > > does (don't get me started on gtk or qt). But what suprised me for
> > > > example
> > > > was that although I had compiled elementary with just the framebuffer
> > > > backend it nevertheless tried to use the X backend unless it was told to
> > > > not do so (with ELM_ENGINE=fb). So there apparently is code there which
> > > > strictly speaking doesn't has to be there.
> > >
> > > x11 engine is the default. thats just how the code is. :) if its not
> > > coimpiled in you just get stubs trying to use the engine and returning 0
> > > saying they cant (ie nothing compiled in) you wont save more than a dozen
> > > or 2 bytes by trying to remove these stubs entirely. its not worth it.
> >
> > Ok that's probably true, I was just arguing from the busybox mindset where a
> > few bytes are actually a worthwhile saving ;)
>
> i am happy to spend bytes when it makes life simpler and easier in the bigger
> picture. :)
>
> > > > Another thing is the lua/embryo thing. If I am not mistaken they
> > > > basically do the same thing so it should be possible to only use one of
> > > > the two. Lua was added recently and should become the default, right? So
> > > > embryo will go away in the long run, correct? But I guess it will be
> > > > needed for backwards compatibility anyway so in my opinion it should be
> > > > possible to disable lua at compile time.
> > >
> > > there .. no. embryo is there because it is a default feature of edje. lua
> > > is as of recently also a default feature. it is required because all edje
> > > files are equally capable. i do not want an edje that "might not work with
> > > some edje files". it's not going to happen because as policy i want all
> > > edje files and themes to work the same everywhere. not fail or work
> > > stangely because someone happend to build without the support somewhere.
> > > thus you will need both. note. embryo is TINY. its runtime library is on
> > > the order of about 40kb. thats the footprint. the bits in edje that hook
> > > to
> > > it might be another 10kb of code at worst. lua is much bigger - but we are
> > > now using it because it saves us work and adds more power. it's not fully
> > > up and ready yet, but it will be. so you're getting both embryo and lua.
> > > one way or another.
> > >
> > > (not embryo script is compiled to bytecode and put into the .edj files.
> > > its
> > > is VERY fast to execute. about 2x faster than java. it wil be many times
> > > faster than lua to execute the same logic, so as long as you want just
> > > simple logic - use embryo script. if u want to get more complex and
> > > imaginative.. then u want lua - so there is a very good reason to keep
> > > both. efficiency)
> >
> > Again thanks for the clarification. I understand your point of view
> > regarding
> > ejde files which should work everywhere to a certain degree. On the other
> > hand I think that the peoples who actually use lua could enable it on their
> > own, or there should at least be the possibility to disable it. Afterall
> > special environments like the one we are talking about here don't need it.
>
> but that's not going to happen. :) not for edje. i dont want it becoming that
> where some feature may or may not work depending on how it was compiled.
> people
> will download themes, icons, wallpapers etc. and find they appear nothing like
> advertised, break, do bizarre things just because some feature was not
> compiled
> in. i dont intend to make it easy by making it optional. i highly discourage
> it
> being patched out.
Well you could enable it by default so people would have to explicitly disable
it. Add a big warning to configure/README, create a FAQ entry on the homepage
etc. Or just plain refuse to support setups which don't have lua support
compiled in kind like linux's kernel tainted flag.
> i have been doing open source, linux and e for more than a
> decade and i know where many of the questions end up - they end up on my table
> asking about something someone else patched and modified. to simply avoid the
> pain of having to 1. figure why things are not working 2. having to explain
> what may have been done, and 3. have to finally redirect the queries to the
> people doing the patching. :)
That's the beaty of open source, it's so flexible ;)
Just point the people to a FAQ entry and send the rest to /dev/null.
> lua and embryo are non-negotiable features of
> edje. jut like text, images and rectangles are non-optional features of evas,
> etc. etc. :)
>
> > I guess I could either use an older svn snapshot before the lua merge (I
> > don't
> > like this option because it of course means bugs wont be fixed in my
> > version)
> > or patch it manually out (don't know how complicated that would be).
>
> as above. you will create problems for yourself. you use elementary.
> elementary
> has themes. themes are edje files. they are designed and intended to be
> replaceable. people can/will replace do it. and they will then complain why
> theme x, y, z etc. that uses lua "has bugs". from upstream it will be
> documented that all edje files can do this. all. no conditions. :)
I can see that it's annoying if you are dealing with the users of a project with
the size of enlightenment but for something like a highly specialized bootmenu
app that isn't really a problem.
[ snip ]
> > > now elementary's default them
> > > can be very much trimmed. it has images - a fair few in it. if you used
> > > fewer images and smaller ones that were much simpler and re-used a lot,
> > > it'd make it smaller. you could get that default theme down to maybe
> > > 50-100k without much trouble.
> >
> > As my designer skills are < 0 I will leave this as is for now.
>
> welljust lettign u know there is space to be saved. and be prepared - the
> elementary theme WILL getbigger over time. the default theme is expected to
> provide every feature elementary has. thus everything elm can have - it will
> get. :)
Ok so I will put it on my list for future optimizations.
Would be nice if you don't pull in lua ;)
Thanks,
Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
_______________________________________________
devel mailing list
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
