July 2011 - Pro-apps-dev - lists.apple.com

Re: Poor performance on software rendering generator
by Pierre Jasmin 31 Jul '11

31 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Organization: RE:Vision Effects User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 We're seeing that software rendering for a generator is extremely slow. All these are on a Motion 5 project at 1920x1080, 29.97fps, progressive at full res. step 1: checking timing on our plug-in Drawing takes 10-11ms RGBA->ARGB conversion takes 20-28ms Motion playback rate is 10-11fps step 2: removing RGBA->ARGB code Motion playback rate is still 10-11fps step 3: removing ALL code from renderOutput method Motion playback rate is 12fps step 4: changed from software to hardware rendering, still with empty renderOutput method Motion playback rate is 30fps So even before we add any custom code we're hampered by using software rendering, and this is just a simple generator with an output only not a filter with input/output. Thoughts? Martin Baker www.digital-heaven.co.uk www.twitter.com/digitalheaven www.videospaceonline.com www.finalcutters.com ------------------------------------------------------ Digital Heaven Ltd is registered in England and Wales Company registration number: 3628396 Registered address: 55 Lynwood Drive, Worcester Park, Surrey KT4 7AE VAT registration number: GB 736 0989 03 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/jasmin%40revisionfx.com This email sent to jasmin(a)revisionfx.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Poor performance on software rendering generator
by Martin Baker 30 Jul '11

30 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=hIEfI5xjc3nGwCRRXL9J7Gv1MMVqwHs0X4MK+zQ4tVo=; b=eOyxKgN/uGixtcaGTAtFxo/ehJWR7Zk0/z67EIxHBRWiDuL0ujcKjm5cYzI1DoyK8x WcdvDnlHCUC2EFLoap3hngpgbNYHFSxYWmwZVXTyix+CcaPLEtuKXgWo38OX6GzCzOzv rcqLK+9uT2M0JnaZVSgyMlCWkkSNTSokoN7Js= We're seeing that software rendering for a generator is extremely slow. All these are on a Motion 5 project at 1920x1080, 29.97fps, progressive at full res. step 1: checking timing on our plug-in Drawing takes 10-11ms RGBA->ARGB conversion takes 20-28ms Motion playback rate is 10-11fps step 2: removing RGBA->ARGB code Motion playback rate is still 10-11fps step 3: removing ALL code from renderOutput method Motion playback rate is 12fps step 4: changed from software to hardware rendering, still with empty renderOutput method Motion playback rate is 30fps So even before we add any custom code we're hampered by using software rendering, and this is just a simple generator with an output only not a filter with input/output. Thoughts? Martin Baker www.digital-heaven.co.uk www.twitter.com/digitalheaven www.videospaceonline.com www.finalcutters.com ------------------------------------------------------ Digital Heaven Ltd is registered in England and Wales Company registration number: 3628396 Registered address: 55 Lynwood Drive, Worcester Park, Surrey KT4 7AE VAT registration number: GB 736 0989 03 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

setWidth deprecated warning
by Martin Baker 30 Jul '11

30 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=X46/Fa7UWPrDSp+FCD++wIAnIz/X55PqjUA5tEQKoP4=; b=uIyPe8io9Pe0c2wmLOPTxbI1qB/doja5CxSr0iHH67F82Ny0s3Gdq8NQptx75KLeoG G1EHsTkMBltsBth534suYwhqUI+gNjZ96KnzfHu/aL+sXxw9RLevw0RgJsmAeJGMgX3a lZfliovtOD74oyhftE7bl2RlXqEAam30lxYn8= Everytime I call FxImage.width, Xcode throws up a warning that "setWidth is deprecated". Why? Martin Baker www.digital-heaven.co.uk www.twitter.com/digitalheaven www.videospaceonline.com www.finalcutters.com ------------------------------------------------------ Digital Heaven Ltd is registered in England and Wales Company registration number: 3628396 Registered address: 55 Lynwood Drive, Worcester Park, Surrey KT4 7AE VAT registration number: GB 736 0989 03 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Motion templates and keyframing
by Peter Litwinowicz 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-topic: Motion templates and keyframing User-agent: Microsoft-MacOutlook/14.12.0.110505 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

KeyFrame API question/problem
by Peter Litwinowicz 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-topic: KeyFrame API question/problem User-agent: Microsoft-MacOutlook/14.12.0.110505 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resolution
by Peter Litwinowicz 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-topic: Resolution User-agent: Microsoft-MacOutlook/14.12.0.110505 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resolution
by Peter Litwinowicz 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-topic: Resolution User-agent: Microsoft-MacOutlook/14.12.0.110505 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resolution
by Peter Litwinowicz 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-topic: Resolution User-agent: Microsoft-MacOutlook/14.12.0.110505 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: [FCP FxPlug 1.2] Using FxTexture by modifying his pointer
by Paul Schneider 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Max, An oddity of the FxPlug API is that when you are running on the GPU (using textures), the drawing destination is the current GL context. The output FxTexture doesn't represent the destination buffer; it's mostly used to tell you the drawing coordinates. To get your modified pixels to appear in the destination, you'd want to draw a rectangle textured with your modified texture into the current GL context. The example projects included with the SDK demonstrate this. Also, it looks like you're modifying the image on the CPU, not the GPU. The code you show here downloads the pixels from the GPU, changes them in main memory using the CPU, then uploads the result back to the GPU. This isn't always the most efficient way to go. You might want to consider using FxBitmaps instead. If you set "canRenderHardware" to NO in your -frameSetup method, you'll receive FxBitmaps instead of FxTextures. - Paul On Jul 29, 2011, at 9:08 AM, Gohin Julien (Neo-Soft) wrote: > Hello, > > I'm new on developping FCP Plug-Ins (my configuration FCP 7.0, SDK 1.2). > > I'm trying to use FxTexture input pointer data, modify it (change somes RGBA pixels) and restore the new pointer to the FxTexture output but it in FCP, a black picture appears in the canvas. > > In the RenderOutput : > > > FxTexture *texture = (FxTexture*)inImage; > > GLubyte *inPtr = (GLubyte*)[texture createData:GL_RGBA withType:GL_UNSIGNED_BYTE]; > > //get the contains of "inPtr", put it into my engine which will modify it > > > FxTexture *texture = (FxTexture*)outImage; > > GLubyte *outPtr = (GLubyte*)[texture createData:GL_RGBA withType:GL_UNSIGNED_BYTE]; > > > //copy inPtr into outPtr > > All seems good at this step, outPtr is well set with the new value. > > And finally, i tried to set the new modified pointer in the output Texture but it don't work in the canvas ? > > > [texture setData:(GLubyte *)outPtr]; > > Maybe i miss something ? Any ideas ? Thank you for your help. > > Max Canet, > Technicolor, France > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com > > This email sent to pschneider(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resolution
by Nathan Weston 29 Jul '11

29 Jul '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 ARGH. Typos… Use this email instead! I think you're seeing a bug here. The easiest solution is to make your templates at 1920x1080. All of the templates we ship are at this size and work properly for smaller frame sizes. It appears that when you make a smaller template and attempt to use it at a larger size, some bugs show up. (Feel free to file bugs on this.) Okay I will try this. So I made a 1920x1080 template and applied it to a 1280x720 piece of footage in FCP. I get that the input is 1920x1080 and that the output image is 1280x720. So, in order to hand me the *1920x1080* image, do you pixel replicate? Scale using a bicubic? Etc.? What this test shows me is that I can't get the original pixels, which means that either (a) pixels will be replicated by FCP/Motion in order to give me the template size, in which case can you send the math about how you scale up so that I can pull the original pixels out of the bigger buffer; or (b) pixels will be scaled up using some filter (bicubic, bilinear, etc.) by Motion and my images will be unnecessarily soft upon output… because they will be scaled up with an kernel that doesn't necessarily preserve the input pixels anywhere in the*1920x1080* image you hand me. Can you describe what you do internally? Frankly, whatever you are doing seems like there is unnecessary processing going on at the very least (because you scale up and I have to scale down by throwing away pixels), and at the very worst, no matter what I do the returned images to the user will be softer than the original image, even if I just copy the input to the output. - Nathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… On 07/26/2011 05:23 PM, Peter Litwinowicz wrote: We're seeing a similar issue here, but it seems to only affect images retrieved from input wells through the FxParameterRetrievalAPI -- the main input is coming out unscaled. Motion and FCP have always been braindead when it comes to well inputs, so we already have a bunch of code that rescales the images, fixes up fields, etc, and so far our plug-ins are handling this without complaint. But it's pretty nasty for the host to scale images up only for us to scale them back down (or vice versa). This email sent to site_archiver(a)lists.apple.com

1 0