|
Sphinx.
|
I'm working on a filter with a rather heavy initialization section. In theory the initialization script part should execute one time (I'm testing with only CPU core), however I counted more than 60 executions :-S
Here is a dedicated test script that shows the problem (also attached, note it is unsafe due to the os.time() call):
Here is the output (Filter Forge x86.log):
Variable "do_initialize" should remain false, but for some reason it doesn't. "Prepare" is only executed once, so what the h*** is going on here? Is this related to the rendering "tiles"? Ini Test.ffxml Njyldgarkn sample cache! |
|||||
| Posted: August 21, 2011 7:41 am | ||||||
|
Sphinx.
|
This is very annoying :-S I can't prepare the script in function Prepare because get_sample calls are not allowed (I need to analyze multiple image inputs to get average color of the inputs).
So I'm left with the option to analyze the images in the main get_sample function (with a similar initialization setup as described above). But the extreme overhead caused by the multiple executions (as described above) makes it practically unusable..
We really need a middle way here: some sort of initialization function that allows get_sample calls and can produce data that is shared in all threads/tiles.. FF programmers.. any comments? Njyldgarkn sample cache! |
|||||
| Posted: August 21, 2011 8:11 am | ||||||
|
Igor Lorents
Posts: 39 |
Sphinx, thank you for reporting the issue.
The problem seems to be in our architecture. Changes you've made in the Global table which contains definition for all global variables after the first initialization (which is made by calling the prepare() routine) do not propagate properly. That's why your initialization code in get_sample() function executes each time when the new rendering block is started. The problem should still persist even if you use single-threaded rendering, and your test sample illustrates it very well. So, this issue seems to be a pretty large piece of work, and unfortunately I won't have time for it until the release of version 3.0. Sorry for the inconvenience. |
|||||
| Posted: August 22, 2011 5:27 am | ||||||
|
Sphinx.
|
I see - after Prepare has been called you assume the global table is not changed and simply copy the table...
Could you possibly add some sort of "super global" table that works across tiles, or allow get_sample calls in prepare? Njyldgarkn sample cache! |
|||||
| Posted: August 22, 2011 7:16 am | ||||||
|
Igor Lorents
Posts: 39 |
Unfortunately no, because the behavior of the suggested "super global" table is absolutely equal to the intended behavior of the global table. We'll just have to implement it properly |
|||||
| Posted: August 22, 2011 7:42 am | ||||||
|
Sphinx.
|
Sigh... well, that "bug" along with the darn unpersist error blocks several of my projects. Patience..
Thanks for the explanation anyways. Njyldgarkn sample cache! |
|||||
| Posted: August 22, 2011 9:06 am | ||||||
|
Sphinx.
|
Alright, FF3 released - time to bring this up again The problem still persists: Global variables are not truly global, but only "global" inside a given rendering block. This will ruin smart logic such as initialization regions. A typical scenario: collect a set of samples and use their properties to determine global filtering (e.g. auto levels). This initial sample collection is only necessary to do once. Njyldgarkn sample cache! |
|||||
| Posted: November 17, 2011 5:43 am | ||||||
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
15,510 Registered Users
+7 new last day!
113,390 Posts
+58 new last day!
10,191 Topics
+10 new last day!
6 unregistered users.