[GEM-dev] Next week?

[IOhannes m zmoelnig]

chris clepper wrote:
> On May 7, 2004, at 12:50 PM, IOhannes m zmoelnig wrote:
> 
> It's ARGB but submitted as BGRA only reversed using the _REV_ GL flags. 
>  Confusing, but I guess concessions to the PC world were needed.

ah alright.
i think i was a bit tired and it had puzzled me (among  other things) 
for hours.

> 
> Here's the current state of Pete's plugs for me:
> 
> pix_colorreduce - just crashes on any YUV data I try.  It's not a very 
> good solution to do the conversions just to get it to work.  Even if it 
> did work, I would vote to just not have it process YUV since it would be 
> so slow.
i agree that it is not a good solution.
anyhow, it was simple to do, it worked on my PC and (i think) a lot of 
video-programs use this trick to use effects for images in the "wrong" 
colourspace (which doesn't make it *any* faster)
i have noticed myself that it is so crashy on macs; so i would agree to 
get it out again.
as for slowness: it is slow on both RGBA and YUV-images.


> 
> pix_halftone - doesn't really produce very meaningful output in YUV.  It 
> makes the dot patterns but it's not nearly as legible as the RGB.  I 
> fixed the shifts for OSX so now it's not just green, but maybe that 
> screws up the x86 code so I put a little ifdef around it.
and it still works on x86 ;-)

> 
> pix_kaleidoscope - output is different, but hey it's about 3x faster in 
> YUV.  Will anyone complain?
fine

> 
> pix_levels - doesn't seem to do any sane YUV processing at all.  The 
> code obviously just applies RGB transforms without regard to the chroma 
> offset.  This needs a rewrite for YUV (it might work for gray as well).
at least the luminance-channel is processed correctly ;-)
grayscale works too


> 
> pix_lumaoffset - now crashes religiously when using smooth and YUV (the 
> version I committed did not), and the RGB code crashes no matter what 
> when the offset and gap get too high.  Some sort of bounds checking is 
> either not in place or failing.


> 
> pix_metaimage - sometimes using YUV and not 'cheap' there is a green 
> Also, when size = 0 
> CPU load skyrockets and things start to turn into a slideshow.  Should 
> that value be trapped and just bypass the effect altogether?
yes, i think so.

> 
> pix_refraction - this seems to work pretty well for both RGB and YUV, 
> but the output is different.  Does that matter?
not for me

> halftone - I don't know where this one is going wrong.
hmm, it works on x86.
and jamie has been working on this too almost getting it to work on mac 
(i think).

> lumaoffset - I could have sworn there was some sort of sanity check for 
> pixel coordinates, but now I just don't know.  The crash is always at 
> the smoothing conditional and one of the attendant pointer operations.  
> I checked out the version I committed a few days ago and now it crashes 
> and it did not before (or else I wouldn't have committed it).

i am not that sure about it (the crashes are there, alright; but why).
i have numerous crashes when trying to re-create pete's objects which i 
cannot track down (debugging is not helpful as crashes appear rather 
randomly)
probably there is a stupid bug like the un-initialized GemState hidden 
elsewere.


> 
> The real question to me is how much effort do these really warrant?  
> Sure some of them look quite nice, but none of the objects are 
> particularly essential, and the original Pete code performs terribly.  
> Also, I can't recall anyone ever posting about these objects apart from 
> the Linux compile problems caused by kaleidoscope.  It's starting to 
> irritate that these are holding up the show.

i agree.

mfg.a.dr
IOhannes