On Mon, 12 Dec 2005 21:27:56 +0900 Carsten writes:
> On Mon, 12 Dec 2005 05:12:11 -0500 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> > On Mon, 12 Dec 2005 17:39:29 +0900 Carsten writes:
> > > On Mon, 12 Dec 2005 03:31:32 -0500 Jose O Gonzalez
> > > <[EMAIL PROTECTED]> babbled:
> > >
> > > > They'll remain in deep freeze til you let me know
> > > otherwise :)
> > > >
> > > > As far as the blend functions...
> > > >
> > > > From that one screenshot, it's unlikely that the
> dst-alpha
> > > > blend functions are causing what is seen, since the areas
> where
> > > > the src (icon and text) images are being drawn to, seem to be
> > > opague,
> > > > and there the dst-alpha blend funcs just do non-dst-alpha
> > > blending..
> > > > Also, the corners aren't being touched by any src data, I
> presume,
> > > > and yet they are not transparent, etc.. But I can't say much
> more
> > > > from just that screenshot (I don't have the 'theme' or its
> > > images).
> > >
> > > trust me - it was dst alpha calls - i had other exmaples too to
> work
> > > with. i
> > > know what fn was causing troubles in one example - and the same
> > > logic was in
> > > all the dst alpha blend routines.
> > >
> > I guess I'll have to take your word for it :) But in all
> the
> > tests I ran (which, again, were rather few) no problems arose.
> Also,
> > the code logic for the c and mmx versions are not the same, so
> it's
> > unlikely
> > that one would encouter the same problem with both (assuming you
> had
> > problems with both).
>
> they weren't the same - but i endede up backing it all out as i'd
> instead end
> up spedning a day on it piecemeal fixing it :) u should have tried
> ecore_evas_test - hit the "s" key for a shaped canvas (destination
> alpha) AND
> disabled the mmx and sse routines (so it used the c routines
> only).:)
Ok, just now being able to get back to it :)
No, I never tried running the ecore_evas test at all.
I'll try it right -- now.......
With mmx default..
Pretty nice demo. I presume the bitmasking from the images'
non-255 alpha values is correct?
Recompiling with c as default......
Ummmm.... Yeah, definitely something amiss here :(
>
> > Note that the new blend functions are much more strict
> about
> > wether or not an image (src or dst) has-alpha.
>
> it's not that :)
>
No, I don't think it is either :(
> >
> > > > I thus took a bit of time to run some tests on the
> blend
> > > funcs.
> > > > Not exhaustive by any means, but a few... Blending to dst
> images
> > > > with alpha, with src images with/without alpha, and with alpha
>
> > > masks
> > > > plus colors with/without alpha, for both the c and mmx
> versions,
> > > and...
> > > >
> > > > I sure don't see any problems.
Never did two or more images blended onto a dst-alpha image,
overlaping each other, and this is what seems to bring out the problem.
> > > >
> > > > But, you seem certain, and could well be right...
> > >
> > > i am very certain :)
> > >
> > Yeah, but... we've been down this road once before... :)
> >
And you may well be on the right side of the road :)
I'll take a look at what's going on and get back to you on it.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
