bfxdev
New Member
Hey @John_ , sorry for the delay, I was on a different project the past 3 weeks. Yes, in fact there is such a lot to do with these typemaps! Help is welcome!
First of all, obviously, is to have a compiling environment. I'm doing everything in Windows, with CMake, VSCode as IDE, Visual Studio Community 2019 only as compiler (my settings of CMake in VS2019 never worked properly), plus the QT and SWIG dependencies delivered as archives.
Second is to understand the concept of "typemap" by SWIG: typemaps in general of different kinds, then for Python and for Lua.
It is a lot of documentation! And it is very challenging to understand because it is about code generation in a mix of C, Python/Lua plus the typemap definition syntax.
My very basic understanding is that:
Finally, with that in mind (it is a lot to learn at the beginning, but once the basic typemap concept is understood, the rest seems logical), tweaking OBS bindings is done in just a few lines of code in the .i files.
For some reason, the typemap feature was never used in OBS and for example the frontend functions, which need non-classical type conversions, were written manually out of the SWIG scope. As a result, these functions do not appear in the obspython.py file (and do not appear if you are trying to use auto-completion).
At the end, the remaining work is to:
I would better look at the bindings for accessing the buffer of a
First of all, obviously, is to have a compiling environment. I'm doing everything in Windows, with CMake, VSCode as IDE, Visual Studio Community 2019 only as compiler (my settings of CMake in VS2019 never worked properly), plus the QT and SWIG dependencies delivered as archives.
Second is to understand the concept of "typemap" by SWIG: typemaps in general of different kinds, then for Python and for Lua.
It is a lot of documentation! And it is very challenging to understand because it is about code generation in a mix of C, Python/Lua plus the typemap definition syntax.
My very basic understanding is that:
- SWIG reads OBS header files and generates code, as defined in the files obspython.i and obslua.i, where there is a list of included files and the definition of the typemaps
- For each C function encountered in some header file, SWIG will generate one C wrapper function that binds the original C function to the scripting language
- The purpose of the C wrapper function is to implement the conversions from/to Python/Lua, i.e. it will first check the Python/Lua parameters consistency, then convert to C structures, then call the original C function, then converts the C-encoded data back to Python/Lua and finally return the data if necessary.
- SWIG generates such C wrapper functions by assembling C code defined in the typemaps at the different stages of the C wrapper function. This is why there are several kinds of typemaps (in, typecheck, out, arginit...), e.g.
typemap(in, .....)
is used to convert function arguments from the target language to C - There is a bunch of pre-defined fields that you can use in a typemap, which are expanded with function-specific values during code generation, e.g.
$1
will be replaced by the name of the variable used by SWIG as argument when calling the original C function,$input
is the Python/Lua object passed by the scripting language. - The way typemaps are applied can be controlled. In general a typemap can be applied to all arguments of all functions, or can be limited to the arguments with a particular name, and a particular C function signature can be re-written to force the use of particular typemaps (this is what I did with the function
gs_stagesurface_map
above) - Typemaps can be applied on a sequence of arguments too
- SWIG generates as well C wrapper functions as getters and setters for members of a struct
- There are tons of additional definitions in SWIG.
Finally, with that in mind (it is a lot to learn at the beginning, but once the basic typemap concept is understood, the rest seems logical), tweaking OBS bindings is done in just a few lines of code in the .i files.
For some reason, the typemap feature was never used in OBS and for example the frontend functions, which need non-classical type conversions, were written manually out of the SWIG scope. As a result, these functions do not appear in the obspython.py file (and do not appear if you are trying to use auto-completion).
At the end, the remaining work is to:
- Identify the functions that can be improved with typemaps (see my previous posts), due to memory leaks or functions that are just not useable currently
- Find a good way to improve with a typemap, that ideally does not break any existing script
gs_stagesurface_map
works somehow, but is not free of memory leaks. Anyway the use is limited because the transfer of data back to RAM can be slow depending on the graphic card.I would better look at the bindings for accessing the buffer of a
texture_data
member of the gs_image_file
structure. In my opinion this is really a missing feature in OBS scripting.