Using the new AEFX_SuiteScoper Template Class

[Christian Lett]

Do folks know about AEFX_SuiteScoper?

I was poking around in AEGP_SuiteHandler.h last night (as you do), and this comment at the top caught my eye:

/** AEGP_SuiteHandler.h

  DEPRECATED:

  This way of doing things is out of date.  See AEFX_SuiteHandlerTemplate.h for the

  new way of doing things.

  -kjw 2/28/2014

There's no mention of this "new way of doing things" in the SDK documentation, in fact it still instructs you to use AEGP_SuiteHandler suites(in_data->pica_basicP);

However this new template class looks to be much better. For one thing it will be faster and more economical, since you're only loading the suite you want; AEGP_SuiteHandler loads all of the available suites in one go and that can cause slow down if you're acquiring suites in an iteration (which you wouldn't do, of course, right? ). It also means you can get fast, C++-style access to the suites that aren't available using AEGP_SuiteHandler, such as PF_WorldSuite2 and the param suites, including PF_AngleParamSuite1, and not have to worry about disposing of them later. In fact I was looking into writing an "Extra_SuiteHandler" class to load these particular suites that made me stumble upon this new class).

So we go from the rather clunky C-style:

     PF_WorldSuite2 *wsP = NULL;

     ERR(AEFX_AcquireSuite(in_data, out_data, kPFWorldSuite, kPFWorldSuiteVersion2, "Couldn't load suite", (void**)&wsP));

     // Do stuff with WorldSuite2

     ERR(wsP->PF_GetPixelFormat(input, &format));

     // Don't forget to dispose!

     ERR2(AEFX_ReleaseSuite(in_data, out_data, kPFWorldSuite, kPFWorldSuiteVersion2, "Couldn't release suite"));

To this shiny new C++ style:

     AEFX_SuiteScoper<WorldSuite2> ws(in_data, kPFWorldSuite, kPFWorldSuiteVersion2);

     // Do stuff with WorldSuite2

     ERR(ws->PF_GetPixelFormat(input, &format));

     // No need to dispose!

Much better! Time to rewrite my plugins!

[Zac Lam]

Checkout and SDK_Noise samples were updated to use AEFX_SuiteScoper, and HistoGrid uses it, but the SDK docs need info on this.  I'll make a note to call it out in the docs.

[Brumbazz]

I'm a little confused with the implementation and implications of this.

In the renderer I load ColorCallback16 and then use it in the iterator as an argument sent in a struct:

PF_ColorCallbacks16Suite1 *CCB = siP->CCB16

Would I be better of just using the following in the iterator?:

AEFX_SuiteScoper<PF_ColorCallbacks16Suite1> CCB = AEFX_SuiteScoper<PF_ColorCallbacks16Suite1>(in_dataP,kPFColorCallbacks16Suite,kPFColorCallbacks16SuiteVersion1,out_dataP);

[Christian Lett]

Probably not in that case.

You're better off using the old implementation for iterators, since if you're calling the suite scoper for every pixel in your image, things will slow down considerably. Much better to do something once wherever possible and point to the result in your refcon.

[Brumbazz]

Thanks, that was pretty much what I thought,

I'll do my updates accordingly 🙂

[Brumbazz]

I'm still a little puzzled with this.

I tried for the hell of it to change most of suite handler calls to suite scoper with no actual performance gain. This might not be a surprise, but I found it really cumbersome to load suites in functions that are pretty deep as I need to pass on in_data and out_data needed for the scoper.

In some places however, it makes for much cleaner code.

Even if there is no substantial performance gain, I would like to know and use the right way of loading the suites.

[Christian Lett]

The performance gain is probably minimal in the grand scheme of things, but consider how many suites are being loaded with every AEGP_SuiteHandler call, and it might make a small difference.

Also, rather annoyingly there are certain suites that AEGP_SuiteHandler won't load (like WorldSuite, and the floating point parameter suites), so before AEFX_SuiteScoper existed you had to load (and unload) these suites the old-fashioned C-style way. Incidentally this is how the scoper works internally but thanks to class destructors the unloading is done for you.

Finally, you don't need to use out_data, as the last two (I think off the top of my head) parameters are optional. It's a shame the suite definitions weren't updated to include the name and version constants, as it feels a little backward to define the param type in the template definition, then tell the constructor what to load, but hey ho, can't have everything!