diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2019-09-13 10:41:11 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-09-13 10:41:11 -0700 |
| commit | 0b6321b3f08c48e37e6b8256d420f05d9727fb5a (patch) | |
| tree | 9bb880dd91fd01839df504741923b8d0d019b0b9 /examples/model-viewer | |
| parent | 33f95e0e3d41262a6ebe023b2b2624d735539c6d (diff) | |
Revisions to "new" Slang API based on use in Falcor (#1052)
* Revisions to "new" Slang API based on use in Falcor
As I've been integrating the new/revised Slang API (using the "COM-lite" interfaces) I've run into some cases where the API was either missing features or didn't really work as originally implemented. This change fixes the gaps/problems that came up.
There are two main things here:
1. Some of the routines that returned an `IComponentType*` as a function result weren't actually doing anythign to retain the object they returned (e.g., putting it into a cache). Leaving aside the question of whether we need to add that caching layer, it made sense to instead have the return be through an output argument. Discussion after the initial iteration of the COM-lite API came around to the point that properly reference-counting objects that get returned would be useful if we ever decide we don't like having ever-expanding memory usage for caches of specialized/composed component types.
2. There was no way with the existing API to get at an `IComponentType` that represents an entry point produced during compilation, so that a user could include it in their own composition. This change alters `spCompileRequest_getProgram` to return the global program *without* the entry points, and adds a separate `spCompileRequest_getEntryPoint`. This design lets an application compose whatever combination/layout they want, rather than being stuck with a pre-designed composition baked into the compiler.
* fixup: review feedback
Diffstat (limited to 'examples/model-viewer')
0 files changed, 0 insertions, 0 deletions
