Which is faster: obj.fill or obj.fill.effect ?

[santiagoluib3]

I am varying the color of a smoke (display object) by making it darker according to some game conditions.  I have two methods of doing it but I need to know which method runs faster.  Note that i generate a puff every frame so every bit of speed gain is welcome.

Method 1:

obj.fill  =  paint   (where paint is a previously loaded darker version image of the smoke) 

Method 2:

obj.fill.effect = “filter.sepia”;  obj.fill.effect.intensity = .7   

I like Method 2 because I can vary the intensity of the effect (how light or dark) depending on the conditions whereas method one only has one variation of the a darker smoke (unless i have more versions of the image with varying darkness)  but I am concerned if using filters (method 2) might be more taxing on the cpu/gpu.   I don’t notice any performance difference because 1) the smoke image is only 25x25 and  2) my test devices are decently modern with much faster CPUs and large RAMs.  However, if there is a big processing difference I’d probably pick the faster solution so older devices can benefit. 

Thanks!

Santi 

[roaminggamer]

You can benchmark this  yourself to find out.  Please note, I don’t think the core engineers hang out here much nor could they directly answer this question.  Why?  Because performance is relative and dependent on implementation which varies from device to device. 

Some devices will benefit from hardware acceleration in some steps while others will be all software.

Still, you could just grab the benchmark I wrote for this thread: strip out the work loads, and add your own.  Then run some rough tests on all the test devices you have.

https://forums.coronalabs.com/topic/70455-performance-of-width-height-vs-xscale-yscale/

You cold also go a step further and make an android build that dumps the test results to the screen, the distribute it to ‘helpful other testers’ for a better coverage of devices.

[roaminggamer]

Note: You must also remember, not all devices will be capable of handling method 2.

When I find myself facing this kind of question, “Which feature is faster, which should I prefer, what fallback to I use?”  I do the following:

1. I implement both.

2. I modularize my code such that either solution can be selected on demand.

3. I add detection logic and in some cases a micro-benchmark that tests relevant performance/hardware-support features on the apps first run.

4. I then select the solution to use for that device and use it ever after.

Again, there is no one-size fits all answer.  That is one of the things that can made mobile design a real challenge.

[roaminggamer]

Finally, it seems you’re missing a simpler method:

1. Set the texture, followed by:

2. Set the fill color.

   local rect = display.newRect( 200, 200, 300, 300 ) local paint = { type = “image”, filename = “texture1.png” } – … Then later rect.fill = paint rect:setFillColor(0.25,0.25,0.25)

Setting the fill color is very cheap.

[santiagoluib3]

hey @roaminggamer,

thanks.  you are right in that things like these have no one solution, but I appreciate your tips and insights.  I’ll have a look at the link you shared and see how this goes.  

Actually, I could just carry on without these effects but you see, I am more of an artist than a coder and i believe good visual “juice” (effects, feedbacks, etc.) adds up to the game experience so I fiddle a lot in graphics and in code to achieve what I want in this area - provided it doesn’t cost too much in terms of processing power!  So yes, it makes one of the challenges I am going through.    

I am fascinated by your “detection logic” tip, so in my specific case of whether or not obj.fill.filter is a better option… can you possibly shed some light on that one?  I mean, does corona have a means to test that on-the-fly and settle on that method?   Sorry if this sounds  too much and a rather stupid question

santi

[santiagoluib3]

Aha!  gotta try that one too… sounds like a good and cheap method!! 

By that suggestion, It sounds like  setFillColor is a undoubtedly faster than obj.fill.effect isn’t it

[santiagoluib3]

Splendid!!  

rect:setFillColor(0.25,0.25,0.25)     

does the same trick just fine and (I think?) it is cheaper!!!   

Thanks @roaminggamer

[roaminggamer]

You can benchmark this  yourself to find out.  Please note, I don’t think the core engineers hang out here much nor could they directly answer this question.  Why?  Because performance is relative and dependent on implementation which varies from device to device. 

Some devices will benefit from hardware acceleration in some steps while others will be all software.

Still, you could just grab the benchmark I wrote for this thread: strip out the work loads, and add your own.  Then run some rough tests on all the test devices you have.

https://forums.coronalabs.com/topic/70455-performance-of-width-height-vs-xscale-yscale/

You cold also go a step further and make an android build that dumps the test results to the screen, the distribute it to ‘helpful other testers’ for a better coverage of devices.

[roaminggamer]

Note: You must also remember, not all devices will be capable of handling method 2.

When I find myself facing this kind of question, “Which feature is faster, which should I prefer, what fallback to I use?”  I do the following:

1. I implement both.

2. I modularize my code such that either solution can be selected on demand.

3. I add detection logic and in some cases a micro-benchmark that tests relevant performance/hardware-support features on the apps first run.

4. I then select the solution to use for that device and use it ever after.

Again, there is no one-size fits all answer.  That is one of the things that can made mobile design a real challenge.

[roaminggamer]

Finally, it seems you’re missing a simpler method:

1. Set the texture, followed by:

2. Set the fill color.

   local rect = display.newRect( 200, 200, 300, 300 ) local paint = { type = “image”, filename = “texture1.png” } – … Then later rect.fill = paint rect:setFillColor(0.25,0.25,0.25)

Setting the fill color is very cheap.

[santiagoluib3]

hey @roaminggamer,

thanks.  you are right in that things like these have no one solution, but I appreciate your tips and insights.  I’ll have a look at the link you shared and see how this goes.  

Actually, I could just carry on without these effects but you see, I am more of an artist than a coder and i believe good visual “juice” (effects, feedbacks, etc.) adds up to the game experience so I fiddle a lot in graphics and in code to achieve what I want in this area - provided it doesn’t cost too much in terms of processing power!  So yes, it makes one of the challenges I am going through.    

I am fascinated by your “detection logic” tip, so in my specific case of whether or not obj.fill.filter is a better option… can you possibly shed some light on that one?  I mean, does corona have a means to test that on-the-fly and settle on that method?   Sorry if this sounds  too much and a rather stupid question

santi

[santiagoluib3]

Aha!  gotta try that one too… sounds like a good and cheap method!! 

By that suggestion, It sounds like  setFillColor is a undoubtedly faster than obj.fill.effect isn’t it

[santiagoluib3]

Splendid!!  

rect:setFillColor(0.25,0.25,0.25)     

does the same trick just fine and (I think?) it is cheaper!!!   

Thanks @roaminggamer