[GEM-dev] FSAA 8 window without gemheads leads to currupted contents. (OSX)

[chris clepper]

On Mar 20, 2004, at 7:12 PM, B. Bogart wrote:

> Hey all,
>
> Attached is an example patch of a bug I found with chris's current gem 
> compile (march 16th).
>
> If you create a window with FSAA 8, with no gemheads in it, or with 
> only gemheads that are not processing the window does not seem to 
> start rendering, and apears currupted. Without FSAA 8 the window 
> behaves as normal.

I don't think FSAA 8X exists yet, so the bug is that numbers above 6 
aren't trapped.  Try 2, 4 or 6X.

> Also with this same compile pix_yuv seems to be the only object that 
> passes texture properly. pix_grey and pix_rgba seem to only pass a 
> still image in a moving video source. See "pix_rgba_bug.pd" This is 
> anoying because I'm trying to use live video with a pix_mask but 
> cannot since it only seems to accept two RGBA streams, but I can't get 
> video passing through as RGBA! (or grey)

I have no idea about this one as I haven't used pix_yuv or pix_rgba 
since we removed the need for them long ago.

> Last and certainly least...
>
> Looks like the first pix_video object one creates grabs the 1394 
> device. Any subsequent pix_video's get created, but can't grab the 
> device so they just sit there sending (green).

Yes, this is perfectly acceptable behavior.  Why are you using multiple 
pix_video objects anyway?  The best solution is to use pix_separator 
and route the video that way.

> I could use dynamic patching to re-instanciate the "right" pix_video, 
> but that is really ugly... I'm thinking of pix_video as a catch~ for 
> one particular video stream sent through throw~ I think this only 
> effects pix_video since all other pix_ objects can have a local copy 
> of a pix...

Sorry, this isn't going to happen.  QT grabs the component instance for 
each device and that's it.  Why not make your own catch and throw using 
separator and send and receive?  That seems to be what Pd is all about 
right?

cgc

> Thanks
> Ben