Wondering how FF renderer works

Hello everyone!

Im just very curious about how FF renderer is desined. I am a c++ programmer myself and just want to ask FF-team about it, if it is not a top secret info.

As I can assume at first all components are transformed (with some kind of factory) in an functional data structure with virtual funtion (c++ case scenario) of structures with function pointers (c case scenario). The main variable function should be (in a very simple approach)
SampleRGBA getSample(x, y);
or something similar to this. Is that a right guess?

Have you tried appoach when all components are transformed into a code chunk (c, c++, lua...) and then it is compiled with JIT compiler (Usually any language has that)? Main problem here - in some cases executable memory can be disabled from bios settings.

Also GLSL or OpenCL code can be generated, you just need to write as much function templates as components you have. And launch GPU computations that should be 10-100 times faster. At first glance I can't see any problem with that because most components represents a very simple math with almost complete absence of code branching (if structures). A bitmap based components can be rendered as separete buffers first.
So why you are not using gpu rendering, what is the main problem with it?

Celeried, here's a Help article that describes FF rendering architecture, along with some implementation details:

http://filterforge.com/more/help/Scri...cture.html

Quote
Have you tried appoach when all components are transformed into a code chunk (c, c++, lua...) and then it is compiled with JIT compiler (Usually any language has that)? Main problem here - in some cases executable memory can be disabled from bios settings.

Nope, we never considered that, mostly due to performance reasons. We wanted all our code to be strictly native. If I remember correctly, we even use Assembly for some performance-critical sections.

We could generate native code directly, and this would be a more viable approach, but since the bulk of our code is already native and well-optimized, performance gains would be minuscule compared with the amount of work involved.

Quote
So why you are not using gpu rendering, what is the main problem with it?

We spent at least a year on experimenting with GPUs, but our architecture doesn't lend itself well to a GPU port. Plus, we have some features that aren't possible on a GPU (e.g. Lua scripting), so we'd have to somehow provide a CPU/GPU bridge somewhere inside the renderer. I posted on this topic numerous times, so if you want more info, just search the forums for "GPU".

To sum up, we won't port FF to GPU, but if we ever decide to do a next-gen renderer, it will be designed for GPUs from the ground up.

SpaceRay Thanx.
I didn'n know about that and it seems awesome.
Its funny but I have similar tool written by myself with Qt multy-platform library some time ago. But it was designed in a bit different hardcore way. That tool operates with saved stack of filters where each control value is a javascript function (QtScript). With that tool all controls were dependent on frame number with math functions sin or cos for example. Filters in stack were able to use output of each other. It was an interesting vocation for me... If you interested I have made a folder with some samples of what could be done with that: https://drive.google.com/folderview?id...sp=sharing

Vladimir Golovin
Thanx for your reply, It seems it is a huge number of gpu raging requests already I was just interested what was the most awkward technical part about gpu rendering in FFs case.