Selon Carsten Haitzler <[EMAIL PROTECTED]>:
> On Fri, 7 May 2004 13:19:33 +0200 [EMAIL PROTECTED] babbled:
>
> > Hello everyone on the list,
>
> ooh this one it long! :)
>
Yes, I had prepared it for some time ... :) now trying to shorten it.
> > The first one, that is now a bit on stand by, is python bindings for the
EFL
> > (or, for the begining, for evas only).
[...]
> > And I didn't get very
> > in touch with it for now, and is not in the top of my priority list for
now,
> > as I got bored of working on it.
>
> maintaining bindings for other languages is a LOT of work. i am not sure you
> want to do it unless you are REALLY keen on using them and maintaining them
> all
> the time - thats a LOT of work... LOT! but i can understand your problems.
> callbacks particularly! :(
>
Sadly that's right. Moreover I'm *a bit* lazy and my projects always get
stopped because of lack of maintaining. But I could contribute if someone
maybe more experienced in python bindings would like to look at it. There
already were 2 attempts to write python bindings, that both were left
unmaintained, and I'm feeling like mine will too.
> > So after that long talk on python and evas, let's talk about my second
projet:
> > altivec optimizations for evas.
>
> aaah all good - you should talk with nathan (rbdpgn) - he's done some
> altivec
> optimisations for evas already :)
>
I'm looking at his answer right now...
> > I've got one little thing to say about blending, as the the precision
concern
> > was discussed on this list (about the division by 255): the mmx version
> > doesn't give at all the same result as the C one ("not at all" doesn't
mean
> > they're totally different, but lots of results are off by 1), and neither
does
> > my altivec version. So maybe a common algorithm should be decided to avoid
the
> > effects that could arise when lots of partially transparent layers get
stacked
> > (I didn't test it but it would be a good visual accuracy test); I read in
the
> > evas manual that the software renderer was the reference for all the
engines
> > about rendering quality. If the software engine gives differents results
> > depending on the optimization activated... But I know that algorithms for
SIMD
> > may be very different from classical one, so I can't find a good solution.
>
> well in my experience, doing things with SIMD involves getting "off by 1"
> errors
> in return for speed. if we didn't "live with this" we wouldn't get the
> speedups
> we do. mmx2 and altivec can do better with 128bit registers - but we have no
> code to make use of that at the moment. i personally am willing to live with
> this minor error in return for the speedup. you CAN disable mmx, sse (and
> altivec) to get the raw C version which is pretty accurate :)
>
I'm ok with leaving these computations like that if you are ;) I'd like to
improve precision by fully using the 128 bits altivec registers, but i admit i
didn't get all the "tricks" you used to do the division by 255 in the mmx
version. As altivec instructions differ from mmx one, i found my way by
testing some code and looking at the result, and keeping the formula that
suited the best ... yes that's not the best way to code, but as I was a SIMD
newbie at this time ...
> > They're still some problems that make me not very happy with this altivec
> > version; these aren't related to the altivec optimizations, but with
Darwin, I
> > think (oh, I forgot to mention that I'm working on MacOSX, not Linux for
PPC;
> > but these optimizations should work on it as well as they're not using
Apple's
> > library but gcc pseudo C routines that produce altivec assembly code).
> > The first problem is the memory consumption: I know that evas doesn't leak
> > memory, I tested every Apple's tool to look at memory leaks, and I didn't
find
> > anythink, but the evas test app is *filling up all the memory* !!! Not
even
>
>
> there is a tool called "memprof". i don't know if it works under darwin -
> but
> its X (gtk) based and gives you a visual memory profiler letting you see
> where
> all the memory is being allocated (and possibly leaked) but this is strange
> and
> i havent seen this happen on x86 ever - and others using evas on ppc dont
see
> it
> either. you may have found a buggy check-out of the cvs tree that got fixed
> very
> quickly.
I just looked at memprof : it seems to be very linux specific. But I'll try it
soon, as can't test it while at work ...
But this problem doesn't seem to come from evas: I tried MallocDebug and other
MacOSX tools that say that there's no leaks ! It's really strange, and i first
would like to know if it happens only on my mac or not ...
> > The second one, is that in the top of the gprof results (i.e. the most
time
> > consuming functions), apart from the malloc/free routines that come here
> > because of the 1st problem I described, are functions related to the X
Window
> > display. On MacOSX, X runs on top of Quartz, Apple's graphical engine, and
I
> > think this slows all the thing down a bit. Well, evas' test app is very
> > graphic intensive, at least for the first part, and maybe that's why X
drawing
> >
> > routines come first, but this may be a problem when the others will be
solved.
> basically x uses up about 15-20% of the display pipeline with doing copies
> from
> client memory to the framebuffer. that is about the fastest i have managed
> to
> get it. thats how it is on native x86 and native xservers.
>
I thought one day I could try looking at Quartz and maybe do a Quartz-evas
engine for it, but Apple hasn't got very detailled doc on low-level graphics.
And as one would say on linuxfr.org, "sapusaipalibre".
> > I forgot one thing: I've got no "direct" access to the net, so the CVS
version
> > I'm working on dates from about 6 months ago (well, it was from the SPLIT
> > branch, but still..). I'll try to get up to date, before sending the
patches,
> > hoping that everything didn't change...
>
> evas is in HEAD these days, not split - in fact SPLIT was abandoned
> something
> like a year ago. i would suggest getting a fresh cvs tree snapshot and going
> from there - you may be surprised with speedups, improvements, etc. :)
>
Now I got a checkout from 2 weeks ago, this should be ok. But for now my patch
need some cleanup.
> > benoar
> >
> > P.S.: And sorry for my english ...
>
> no problems. its good! i wish i spoke other langauges as well as you spoke
> english! :) well maybe german is ok :) but hey! never mind about language!
> :)
> mon francais n'est pas bien! :)
>
Well, i try to make my best when i write to mainling lists where not all
subscribers are native english speakers. (that's just a guess, but by looking
at anyone's email, contributors are coming from everywhere ... open source is
cool)
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
