On Sat, 17 Dec 2005 10:00:53 -0500 Jason Tackaberry <[EMAIL PROTECTED]> babbled:
> On Sat, 2005-12-17 at 18:27 +0900, Carsten Haitzler wrote: > > technically - yes. it's a bug. it's due to the fact that the routines dont > > have a special case for multiple when alpha doesnt contain sensible data > > (filling it in with an assumed 0xff) :) > > I argued this on mplayer-dev, and provided a trivial patch to change > swscaler to fill alpha channel with 0xff for conversions to (RGB|BGR)32. > My argument was basically what you just said: that 0xff is a more > sensible default. also if you assume it (and ignore it merely as an optimisation mechanism) then life is easier - it also works much better when flippign alpha channel on/off - ie turn it on and the image is - well solid, like it was before, but NOW u can start fiddling with alpha values. :) anyway - it just depends how you VIEW it :) > http://itdp.fh-biergarten.de/~itdp/html/mplayer-dev-eng/2005-05/msg00398.html > > Ultimately my patch was never merged. Instead they suggested that the > library I was working with (evas) should have a way to ignore the alpha > channel. I knew that it had (evas_object_image_alpha_set), but it > didn't work properly when alpha < 255. I didn't want to mention that > fact, because once I indicated there was a problem with the library I > was using, they'd just ignore me. :) Well, they ignored me anyway ... happens often :) even here! :) > However, I've also noticed the same behavior in xine's yuv2rgb > scaling/conversion code. Also, my ultimate goal is to get mplayer's > swscaler into xine as an optional shared library, and when my > application uses that, I'd simply be back to square one. but where does evas fit in there? evas has its own yuv (yv12) import mechanism and eventually i want to merge all that down into the engine level so in theory it can hw accel if possible or simply sw convert - so you just provide yuv and evas "deals with it" as bes possible given the hw etc. > So it'd be nice to fix the issue within evas. I suspect this won't > really be a simple change. It's not really acceptable to add > has_alpha==false comparisons in the inner blending loops, so really what > you're looking at is a separate code path for the case where > has_alpha==false that simply doesn't multiply with the image's alpha > channel. The blending code would be _almost_ the same as the existing > routines (a bit simpler) but that's a lot of extra code. That could > possibly be mitigated with macros, but that always uglifies things. :) well the rgb mul blend calls need to be modified to insert artificial 0xff's for alpha (in fact simply use the alpha value of the multiplier color directly). that actually is harder than it looks with the mmx as it literally multipleis everything in simd :) the c is easier :) > Anyway, I haven't actually looked at the code yet, so I'm just making > educated guesses. I first wanted to see if such a patch would be > accepted, or perhaps if someone else who's far more familiar with evas > was motivated to do it. :) it would be accepted :) > Cheers, > Jason. > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
