> > A last topic I would like to discuss is FPU need by Edje.
> > Right now without hardware floatting point, Edje could loose
> > around 30% of time in soft float when you have many objects
> > on the screen. I don't know what would be the best solution to
> > this problem, doing some fixed point calculation or caching
> > result, updating them when required. If people have idea on this
> > I would like to ear as it is something I want to fix.
>
Some actual use-case profiles of this would be good.. How
many objects and which calculations show significant performance
loss due to floats vs. some fixed point version?
> Good point, floating point operations can be emulated through
> fixed point, enesim has a directory utils with several routines
> that are useful not only for enesim but for other projects /
> project types, one of them is a small (incomplete) collection a
> header files with inline functions for fixed point math, of course
> im not telling that adding enesim as a dependency to edje is an
> option, it is not, but my plan with enesim's utils was to actually
> merge them at some point with edata as a common place for data
The actual use of floats in edje that might be a source of
'slowdowns' would need to be determined first, and if there is a
problem of some sort there, it should be fairly easy to replace
with fixed point calculations without having to use a separate
lib that provides utilities for that - unless those utilities are
already part of evas (or something else edje would depend on).
> containers/operations. I wont start the discussion about splitting
> ecore_data from ecore, mainly because edje already depends on ecore,
> so the logical option if fixed point math is needed is to add that
> to ecore, but then enesim (and evas in case we replace the fixed
> point algorithms: line drawing, etc with a known implementation
> which is good) will depend from ecore which is again not an option
> (recursive dependencies, etc)...
Too much fine-grained splitting of things is not that great
a help if in the end you just need to include all of them anyway for
anything to work.. or if you start running into issues with circular
dependencies. Splitting really needs to be organized according to
more-or-less logically separate domains and more-or-less commonly
used ones as well -- eg. one large 'split' that people often have
is "gui" vs "non-gui", even though that's not always so clear.
If indeed it would be useful to split-up ecore, then something
like that, ie. a base non-gui part and a gui one that would depend on
the base one, might be a good way to do it. Wether or not the gui one
itself should be split into sub-parts, or if the base one should allow
for further modularization, is yet another question.
Right now, things are convoluted in places, but it's not clear
though that doing this, without first looking into those aspects in
more detail, would be necessary right now.
jose.
_____________________________________________________________
Get DVDs Delivered to your Door. Click Here.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nSQh6yVOE8DWIJd1n4QIje14KcYlyVd4lmECpqy38jQvlKQ/
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
