YOUR ACCOUNT

Home > Forums > Bugs and Problems (Windows) > 

Map Switch Performance Hit

Active Topics Search
Login or Register to post new topics or replies
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
When I hook up a map switch, I encounter a strange drop in performance - searched for info on this, but all I can find is that switches should be very fast.

I wanted to let the user specify wether input image (1), input image alpha (2) or selection (3) should be used in a given filter. When I set it up this way and e.g. #1 (the image) is selected, the overall performance drops significantly compared to using the image directly connected to where the switch normally goes.

Anyone else noticed this? I can't imagine that just introducing the switch can be that heavy.. maybe there is something wrong in my setup or it has some sort of not so clear consequence performancewise...

I attached a simple example filter: Lock the preview to the result, and try bypassing the switch setup by connecting the image directly to the tone curve and visa versa.

When a direct connection is made the filter renders roughly double as fast.. doesn't make sense

Switch Performance Hit.ffxml
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: December 11, 2007 10:53 am   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Can anyone confirm this "behaviour"? - I'd like to know if its a general issue or something related to my system..
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: December 12, 2007 3:01 am   Details E-Mail
Kraellin
Kraellin

Posts: 12749
Filters: 99
with the image component hooked up direct, 1.6 seconds. with all hooked up, running through the switch, 10 seconds. with just the image component running through the switch and none of the others, 1.6 seconds. so, either your selection component or alpha component or a combination of all, are what's adding the additional time.

ok, hooked up the alpha with the image through the switch, 1.6 seconds. hooked up the selection component with the others, through the switch, 10 seconds. looks like it's the selection component that's doing it.

edit: ok, just ran the selection component through the switch with no others, 4.6 seconds. so, some combination of those three, through the switch, is what's doing it.
If wishes were horses... there'd be a whole lot of horse crap to clean up!

Craig
Posted: December 12, 2007 12:44 pm   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
ok, thanks... it just gets even weirder.. how can other non used sources in the switch affect the rendering? I mean, if the selector is at #1 then #2 and #3 shouldn't influence anything... weird stuff.. maybe Vlad or some of the FF guys can shed some light here.. could be an issue that ought to be corrected
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: December 12, 2007 1:05 pm   Details E-Mail
Kraellin
Kraellin

Posts: 12749
Filters: 99
dunno. maybe the 12 node switch doesnt work the same way as the older five node switch. but might be that the selection component is pre-rendering regardless.
If wishes were horses... there'd be a whole lot of horse crap to clean up!

Craig
Posted: December 12, 2007 1:29 pm   Details E-Mail
ssamm
Posts: 364
Filters: 21
I did a test where I made a filter with no switch, and then a filter that had a switch where other selections on the switch were much slower (with with slow refraction and blur components). I made the default first preset the same for the non-switch and switch filters. As I clicked on each filter, they seemed to render at about the same speed.


So... It may be that since you used a "selection" component, this perhaps causes the filter (even if the selection component isn't in the selected subtree of the switch) to run some subroutine to see/find what the selection is. If there is no selection, then the filter will also display a message that says "This filter requires a selection". Maybe this is what is (some how relevant) to what you are seeing?



I just re-did my test above where the Selection component was added as one of the options in the switch version of the filter, and this did seem to cause the default preview from that switch filter to run a bit slower than default preview of the non-switch preview. My next test would be to make sure both the switch and non-switch filters use the selection component, and then try to notice if there was still a difference...


In other words, my guess is that the filter goes through pre-rendering calculations (which don't take too much time), then goes through the actual rendering calculations (which if certain Switch options are selected, it can take a ton of time, or it can be really quick, depending on which subtree is selected).
... (but that's just my guess so far (if you were able to understand what I was trying to describe)...)



Posted: December 12, 2007 7:12 pm   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
SSamm,

I understand what you're saying - did similar experiments.. what really makes me wonder is not the fact that it slows down rendering, but rather why it does from a software design perspective.. having a turned off vacum cleaner plugged in should not affect the power consumption meter smile;)
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: December 13, 2007 3:43 am   Details E-Mail
Bella
Moderator
Filter Forge, Inc.
Posts: 274
Sphinx,

Kraellin is right -- it's indeed the Selection component that slows it all down. Even if it is in a non-selected subtree of the switch. The thing is that the fact whether or not the Selection component is present in a filter determines how the filter output is combined with the original image.

I'd recommend that you read this article: http://www.filterforge.com/more/help/...utput.html
Posted: December 13, 2007 11:05 am   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Quote
Bella wrote:
I'd recommend that you read this article: http://www.filterforge.com/more/help/...utput.html


That cleared a few other questions, but I couldn't find any explanation on why its slower with selection component present, in fact it seems the other way around:

Quote
If a filter uses the Selection component, Filter Forge assumes that the filter needs to modify pixels outside the selection. In this case, Filter Forge does not mask the filter output with the selection – the filter output simply overwrites the original image ignoring the selection.


Overwriting should be faster than combining, so it still seems strange to me, and I have a feeling that it isn't directly related (since the performace hit is present in internal previews too). I probably don't understand the full context smile;)

Btw. what does the bold text in this sentence mean?:

Quote
If a filter uses the Image component but no Selection component, Filter Forge considers the filter to be an image-based effect such as a distortion, and combines its output with the original image by linear interpolation using the selection as an interpolation coefficient, so that the filter output is restricted by the current selection.
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: December 13, 2007 11:16 am   Details E-Mail

Join Our Community!

Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!

33,711 Registered Users
+18 new in 30 days!

153,531 Posts
+39 new in 30 days!

15,347 Topics
+72 new in year!

Create an Account

Online Users Last minute:

20 unregistered users.

Recent Forum Posts:

Join our Forum Join our Forum
Over 30 000 members!
Join us on Facebook Join us on Facebook
Over 42 000 likes!
Follow us on Twitter Follow us on Twitter
Get updates quickly!
Follow us on Instagram Follow us on Instagram
Tag us #filterforge