many thanks Dan for the clarifications!
On Sun, 03 Apr 2016, Dan Dennedy wrote:
> Also, it has been in git since July, 2015. But, perhaps for a low activity
> mailing list, it might not be a bad idea to reflect commit messages to the
> list?
this is a good idea, especially considering both this mailinglist and
the commits are low traffic. I will look into this together with
colleagues here.
> I agree. In the future I will submit big changes to the mailing
> for review before commit. I ask for their to be a 10 day
> expiration where no response means OK, and I will send a reminder
> e-mail after one week if there was no response.
yes, this is very reasonable.
> To each C++ plugin, yes. The old frei0r.hpp C++ wrapper would
> store the image buffer pointers on the object and access them
> through those members. If there is more than one thread calling
> the same f0r_update function the C++ wrapper classes will change
> the image pointers of the first thread to that of the second
> thread. The only value of this limiting statefulness was to give
> C++ plugins a cuter, simpler update() method signature for their
> implementation. After the change, the image pointers are moved
> from the instance and onto the stack, and each thread's
> f0r_update() is using thread-local pointers and not overwriting
> each others' buffers.
this is exactly what we can consider a fix.
> I am preparing a patch that will remove the extra input buffer
> parameters from each C++ update() method, but it does add the
> overhead of an additional method call plus some virtual function
> lookups within the C++ wrapper.
I haven't read the patch yet and unfortunately today is a very bad day
for me to do that, however reading abou the virtual function lookups
worries me quite much, since those lookups at runtime are very
expensive in terms of CPU cycles especially if used in tight loops.
A way to avoid the overhead is to make the methods pure virtual.
But again I haven't read the patch yet.
ciao
::
Re: [Frei0r] api documentation
