[GEM-dev] FSAA 8 window without gemheads leads to currupted contents. (OSX)
B. Bogart
ben at ekran.org
Sun Mar 21 04:39:42 CET 2004
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
>
More information about the GEM-dev
mailing list