modules/*: instantiate and use setups

Now modules allocate and return an opaque setup pointer in
res_setup when they implement a setup method.

Defaults are utilized when ${module}_create_context() receives a
NULL setup.  The default setup used in this case should match the
defaults/preferred values emitted by the module's setup method.
But performing setup should always be optional, so a NULL setup
provided to create_context() is to be expected.

No cleanup of these setup instances is currently performed, so
it's a small memory leak for now.  Since these are opaque and may
contain nested references to other allocations, simply using
free() somewhere in the frontend is insufficient.  There will
probably need to be something like a til_module_t.setup_free()
method added in the future which modules may assign libc's free()
to when appropriate, or their own more elaborate version.

Lifecycle for the settings is very simple; the setup method
returns an instance, the caller is expected to free it when no
longer needed (once free is implemented).  The create_context
consumer of a given setup must make its own copy of the settings
if necessary, and may not keep a reference - it must assume the
setup will be freed immediately after create_context() returns.
This enables the ability to reuse a setup instance across
multiple create_context() calls if desired, one can imagine
something like running the same module with the same settings
multiple times across multiple displays for instance.  If the
module has significant entropy the output will differ despite
being configured identically...

With this commit one may change settings for any of the modules
*while* the modules are actively rendering a given context, and
the settings should *not* be visible.  They should only affect
the context they're supplied to.

0 files changed, 0 insertions, 0 deletions