On Sep 15, 2009, at 9:18 AM, Chris Wood wrote:
Sounds like a driver/CI bug -- I'd report it as concisely as
possible, and then shake your fist at the sky in desperation when it
doesn't get resolved ;) workarounds like what you describe are
really annoying simply because when you do get it fixed, they'll fix
it too, and then it'll break your fix. But of course, if you don't
fix it, neither will they... so either way, be prepared to have a
1.1 ready to go on some 10.6.x update ;) (I've experienced this at
least 3 times with 10.5)
Probably a good idea. I came across that on leopard btw - it'll
probably already be fixed in 10.6 leaving me with the headache of
supporting both ;)
Are these built in CI filters or ones which you have written? Sounds
like a missing ROI function.
.xX
>From the GPU engineers I've spoken with (from both ATI and Nvidia),
POT is an ancient relic that doesn't actually help performance
significantly anymore. It can help with some fancy calls, like
automatic mipmap generation, but other than that I don't think it'll
help as much as you're hoping. I'm not sure on requiring POT for
>8bpc modes -- I've never heard that, but I'm oft mistaken on
intricate GL details. hardware-wise, POT+>8bpc only requires a
different multiplier, so it's not like it actually requires any
additional transistors or fanciness -- as long as the multiplier can
handle a number 4x larger (2 extra bits), there's nothing physically
required that isn't already there.
Guess I need to figure out the situation with >8bit textures. I
can't remember now what made me think NPOT wasn't properly
supported, but something did because I'm converting my camera input
to POT sizes before processing. Perhaps I did that while trying to
figure out the >1024 pixels sampling thing though, and it's not
necessary. If it does need POT textures though, tiling will
definitely improve performance because I won't need to run my
expensive filters on the whole image (no need to process the black
bars).
I've not tried the ofType: variant, but I _think_ that lets you
request CGImages. I'd give it a spin.
Oh: On leopard, requesting CGImages would give you BGRA images that
claimed to be RGBA -- I don't think that was ever fixed on leopard,
but maybe it's finally fixed since PPC is dead? you might want to
check on that before jumping in headlong.
Ah, more nastiness ahead it seems. Luckily I have a PPC machine, and
an intel one that's currently dual-booting 10.5/6. Thanks for the
heads up.
Yeah, readpixels is only good for contexts -- I was thinking you
were having the QCRenderer render to the context, not act as an
image filter. I always forget that kind of usage ;)
I'm using it for both: it takes a video input, does lots of
processing, then outputs it back to the app via a published port.
But it's also doing a bit more processing for on-screen preview,
adding overlays etc. End result is that the renderer is running at
maybe 640x480 in part of a window, but it's doing perhaps 1024x1024
processing internally and saves at that res. It makes for a good
image processing setup - better than doing the processing then
passing the image to a separate renderer I think.
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/asabatelli%40apple.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
