On Tue, 13 Dec 2005 12:42:46 +0900 Carsten writes:
> On Mon, 12 Dec 2005 20:41:12 -0500 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> > Ummmm.... Yeah, definitely something amiss here :(
>
> yeah. that was a good start in debugging, finding the algorithm
> issues then
> noting they were in many place then finally reverting.
>
> >
> > I'll take a look at what's going on and get back to you on
> > it.
>
Ok. Let me address this first and then pre-mul alpha :)
It's fairly clear what's going on -- the approximations used
aren't good enough to keep us within the [0-255] cube we want, so
every once in a while the rgb computations overflow and bump the
alpha up by one.. if the alpha was 255, it'll bump it 'up' to 0 :(
Fortunately, there are simple enough solution(s):
1. We can do the computations with the components separately,
as has been done so far... This is fairly painless, just replace
ocurrances of the RGB_JOIN, ARGB_JOIN macros by the set of
corresponding component-wise macros...
Or, we can keep the new approach, which is somewhat faster,
by noting that:
2. Since the only case where we need to worry about the dst
alpha being overflowed is when it's 255, we can simply add one line
wherever there's a switch statement over dst alpha and the case
is 255.. namely we add the line
A_VAL(dst) = 255;
immediately after the RGB_JOIN macro that ocurrs there.
This should solve the problem for rgba dst images.
[ For rgb dst images, if we leave things as they are then
their alphas may actually be changed, which is contrary to the
spirit of things (the current code does this sometimes too), so
if we want to be 'honest' then we should preserve whatever alpha
the dst has.. and again we can first save its alpha and reset it,
or whatever. ]
I tried this just abit ago and... the ecore_evas_test shaped-
evas demo is back to being on par with the mmx version :)
(you only need to do it for the pixel-pixel rgba to rgba blend func
for the demo)
Either way, for the time being, if you feel comfortable with
the mmx versions (and I still haven't really tested those!), then
either of these two approaches, for the c versions, would be a good
idea to put back in :) (the new blend routines do give some *good*
speedups in many cases, not just from the mmx dst-alpha routines).
> sure. though i think what we need iss to instead break out a small
> routine set
> outside of evas for optimising on its own first. i have a small
> routine set of
> more optimised pre-mul alpha c/mmx/sse/sse2 routines (sse3 provoides
> nothing of
> use i can see). they all work on x86 and amd64. it has a good speed
> and
> correctness test harness (write otu resulting png's of every op to
> see if it
> matches). :)
Yeah, and that's pretty much what we've been doing :) I also
wrote some c/mmx pre-mul alpha routines.. back when we first discussed it
and such.. :)
But moving *this* evas to pre-mul alpha is a big, *radical* change!
Not only do all the blending/scaling/pixel-import, etc functions, have to
be checked/changed/adapted, etc. that's just a lot of internals to be
redone..
But every program and lib that's been getting/setting image data is going
to be either broken, or it's going to suffer a major performance hit!
> i actually get some interestign performance profiles
> where
> speedups vary. on amd64 sse2 is faster than sse by a bit (for
> copies) but on my
> p4 sse is faster than sse2 - by a bigger margin. int he end i
> imagine we will
> need a runtime routine check to see whihc is faster on that
> particular cpu
> (likely cache results unless cpu changes).
>
You're a nut!!
But yes, I think a formal test/perfomace suite is an excellent
idea.. clearly :)
-------------------------------------------------------
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
