I have serious performance issues on iPad2 if I create 40 static display objects and change their hue with filters.
[lua]local bush = display.newImageRect(“maze-bush.png”,128,128)
bush.fill.effect = “filter.hue”
bush.fill.effect.angle = math.random(0,30)[/lua]
Is the performance hit normal or something that should be investigated further?
Hi @polygonblog,
This may be taxing the processor a bit. Do you do this in a transition or something? Or just set the hue of all 40 at once? What devices are you testing on, and what kind of performance hit are you seeing?
Brent
Hi Brent! No, I don’t do it in transition. I do it exactly like the code above. It takes a second to do it, but after it’s done, everything becomes very slow as long as the 40 filtered object are visible. The performance hit is huge. Only thing I’m doing is dragging small display object and the performance is really bad. If I disable the filters or place a fullscreen display object on top of filtered objects it runs very smoothly.
Are you moving the objects around (or the group they’re in)? Note that when filtered objects are moved/repositioned/etc., the filter has to be re-applied to them, so if you have 40 of these being moved around or “refreshed”, the performance hit seems expected. One potential solution, if it suits your app design, is to do the initial rendering of them, take a snapshot of that group, and then hide (or overlay) the objects with that snapshot, which will mimic what it looked like while behaving as one single, non-filtered object.
Brent
No I’m not moving them. I’m not doing anything to them. It feels as if the effect is re-applied every frame even though nothing is happening.
Hi @polygonblog,
The engineers report to me that the “hue” filter can be expensive when applied to this many objects, because of the way OpenGL has to refresh them (even if you’re not moving those objects but rather some other object(s) on top). The best solution would be to render that group to a snapshot post-hue-application, so it’s treated as one object… this should remedy the performance impact.
Best regards,
Brent
Thanks Brent for clearing this up and suggesting a workaround.
Hi @polygonblog,
This may be taxing the processor a bit. Do you do this in a transition or something? Or just set the hue of all 40 at once? What devices are you testing on, and what kind of performance hit are you seeing?
Brent
Hi Brent! No, I don’t do it in transition. I do it exactly like the code above. It takes a second to do it, but after it’s done, everything becomes very slow as long as the 40 filtered object are visible. The performance hit is huge. Only thing I’m doing is dragging small display object and the performance is really bad. If I disable the filters or place a fullscreen display object on top of filtered objects it runs very smoothly.
Are you moving the objects around (or the group they’re in)? Note that when filtered objects are moved/repositioned/etc., the filter has to be re-applied to them, so if you have 40 of these being moved around or “refreshed”, the performance hit seems expected. One potential solution, if it suits your app design, is to do the initial rendering of them, take a snapshot of that group, and then hide (or overlay) the objects with that snapshot, which will mimic what it looked like while behaving as one single, non-filtered object.
Brent
No I’m not moving them. I’m not doing anything to them. It feels as if the effect is re-applied every frame even though nothing is happening.
Hi @polygonblog,
The engineers report to me that the “hue” filter can be expensive when applied to this many objects, because of the way OpenGL has to refresh them (even if you’re not moving those objects but rather some other object(s) on top). The best solution would be to render that group to a snapshot post-hue-application, so it’s treated as one object… this should remedy the performance impact.
Best regards,
Brent
Thanks Brent for clearing this up and suggesting a workaround.