[Cin] Stupid question about pixel conversions in CinGG (xfer functions)

[Andrew Randrianasulu]

Hi, all!

I was looking again at 
https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/guicast/bcxfer.C;h=8eb6533baa68b7cc8b3fe1d763f03d65a3d28b4e;hb=HEAD

and I think it works (via generated  functions from guicast/xfer) by doing  pixel-at-a-time, with slices done at different CPUs.

Is there possibility to optionally add few stagin buffesr, so something like http://gegl.org/babl/index.html#Usage will have chance to work?

"The processing operation that babl performs is copying including conversions if needed 
between linear buffers containing the same count of pixels, with different pixel formats."

So, address calculations usually send down to Cin's own (slow?) functions will be reused to calculate size of buffer 
(per slice, as done by slicer function), and then babl or ffmpeg or something will transfer pixels to this new buffer, and then ..
I dunno, signal 'done' to upper calling function and switch pointers to this new buffer? So, tricking Cin
into thinking conversion (per sliced area) was done by its of functions, yet using different set of them 
(not those row-based macro expanded functions I see in build tree)?  As long as pixels organized the same (row x column), 
and internally represented by same datatypes (like, first 4 bytes is R in float, second is G, third is B, and last 4 bytes is alpha ...
for total of 16 bytes per pixel) this should work? Or I missed something?