On Mon, 10 May 2004 19:44:14 +0200 [EMAIL PROTECTED] babbled:
> > 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.
well i'm sorry to say - that's not going to be me! :) i do all my stuff in C. i
don't mind having to compile things. :)
> > 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 ...
well really with 128bits.. you could increase speed even more by doing 2 pixels
at once... assuming u have a full 8x16 set of commands (ie add/sub/mul/shift the
8 16bit words within the register, just like mmx/altivec can do it in 64bit
registers with 4x16... :) ) i'd go for the speed myself :)
> 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 ...
just because it uses up ram doesn't mean its a LEAK. a LEAK detected by a leak
detector will find memory where the code has LOST the pointer TO that memory.
this could be memory the code still has pointers TO (it hasn't lost it) so what
you NEED is a memory PROFILER. something that tracks every allocation and there
it was allocated (ie the call tree and line number/file) and then you look at
the profile and see where the largest amount of memory is being allocated and
then you know what it is thats eating up the memory (for example a large list of
images that just keeps being appended to) and you can track further and find why
it isn't being cleaned up.
> > > consuming functions), apart from the malloc/free routines that come here
oh - forgot to mention, the EFL stuff is VERY heavy on free/malloc - evas too. i
would consider trying to optimise this and reduce free/malloc's - maybe move a
lot of mallocs to calloc (ie allocate on the stack) or remove the need entirely,
introduce some more optimal memory pools for things like evas_list to use for
list nodes etc. but gnu libc malloc/free seem very fast and i haven't seen a
need to do a lot of work on this yet. this may not be the case for macosx
though.
> > > 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 have no objections to a quartz native engine at all. i think it would be great
actually. but i possess no mac boxes and don't really have any incentive to work
on it myself :)
> Now I got a checkout from 2 weeks ago, this should be ok. But for now my patch
> need some cleanup.
2 weeks is probably ok - but the more up-to-date the checkout the better, so
update as often as you can. :)
> > 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)
yes. there are people from all over the world here - english is the de-facto
language for lists (luckily for me!) :) but i understand that many people dont
speak english natively - i only speak english and german natively. i studied
french but never get any chance to practise so it is very rusty these days, and
i'm learning japanese right now (since i live in tokyo now it's a necessity) :)
but there are many langauges in the world and no one speaks all of them - so
don't worry - if i spoke french as well as you speak english - i'd be a lot
happier :) (or at the moment if i spoke japanese as well as you speak english!)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
