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

[B. Bogart]

Hey Chris,

As for FSAA the same thing happens with FSAA 2|4|6 The window is 
currupted even after the render message is sent if there are not 
gemheads. Did you try my example patch?

I don't understand how I've been using FSAA 8 the whole time and I've 
always gotten an AA render window?! I guess it was using FSAA 6 internally?

Since pix_rgba is unneeded, how can I use pix_mask? I simply get errors 
that pix_mask cannot process two YUV streams... Has this object not been 
updated yet?

I thought it maybe QT grabbing the device. I'll have to think around a 
solution. I have multiple pix_video objects because they are different 
instances of the same abstraction. I would like each instance to be able 
to grab the video... I'll have to do some more dynamic routing stuff.

Off for dinner.

Thanks,
Ben

chris clepper wrote:

> 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
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>