Light2D has performance issues on Android

[Noisefever]

Operating system or device - Godot version:
Android, Samsung S7 - Godot 2.1.3

Issue description:

Light2D is very slow and laggy. On the desktop it runs smooth but on Android it slows down unusable. Without shadow and without shader. But as it should be in this state only a texture with add blendmode, it should be have no such impact on the framerate.

Steps to reproduce:
Marble.zip

I have attached a simple example project. Just tab (or click) the marbles to switch their lights on and off. On Android you will experience a major slowdown. The marbles can be moved with arrow keys (PC) and the accelerometer (Android).

Link to minimal example project:

[RandomShaper]

I'm also hit by this. But I'm not sure a real fix is possible.

I'd say this affects any platform on which overdraw, state changes, etc. are expensive. Each CanvasItem is rendered 1 + N times, being N the number of lights that intersect it. And before that, every light has to be checked for intersection against every item. This checks is restricted to what is visible in the viewport, and I don't know it it's a bottleneck, but it has to happen.

I tried to optimize the renderer with several approaches:

• VBOs and some bookkeeping to reduce state changes: didn't pay, the performance on mobile even worsened a bit;
• using the depth buffer to try to reduce drawn pixels and also reduce state changes, it's work-in-progress, but probably won't work either;
• I implemented the AT_LIGHT_PASS shader builtin to at least get code from the vertex and fragment shaders removed at runtime, for those computations not needed in lighting, but with no big difference.

Instead, the way to go would be to embrace some good practices:

• keep the light count to the minimum;
• make them as small as possible;
• try to avoid intersection between lights;
• etc.

If someone has a more promising approach, I'd be glad to hear it!

[reduz]

If it helps, another thing I found to speed up lights on Android is to make a small light texture, then use the scale parameter. This reduces memory bandwidth

…

On Fri, Jul 28, 2017 at 8:24 AM, Pedro J. Estébanez < ***@***.***> wrote: I'm also hit by this. But I'm not sure a real fix is possible. I'd say this affects any platform on which overdraw, state changes, etc. are expensive. Each CanvasItem is rendered 1 + N times, being N the number of lights that intersect it. And before that, every light has to be checked for intersection against every item. This checks is restricted to what is visible in the viewport, and I don't know it it's a bottleneck, but it has to happen. I tried to optimize the renderer with several approaches: - VBOs and some bookkeeping to reduce state changes: didn't pay, the performance on mobile even worsened a bit; - using the depth buffer to try to reduce drawn pixels and also reduce state changes, it's work-in-progress, but probably won't work either; - I implemented the AT_LIGHT_PASS shader builtin to at least get code from the vertex and fragment shaders removed at runtime, for those computations not needed in lighting, but with no big difference. Instead, the way to go would be to embrace some good practices: - keep the light count to the minimum; - make them as small as possible; - try to avoid intersection between lights; - etc. If someone has a more promising approach, I'd be glad to hear it! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9944 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z20FKImUPJVfae0VvOQQ1ZSOICM5pks5sScTngaJpZM4OmV26> .

[reduz]

There are also not many ways to optimize this. Using a single pass for all lights is also slow because of non dependent texture reads, which also kill the performance on Android. Mobile performance in general is crappy..

…

On Fri, Jul 28, 2017 at 8:28 AM, Juan Linietsky ***@***.***> wrote: If it helps, another thing I found to speed up lights on Android is to make a small light texture, then use the scale parameter. This reduces memory bandwidth On Fri, Jul 28, 2017 at 8:24 AM, Pedro J. Estébanez < ***@***.***> wrote: > I'm also hit by this. But I'm not sure a real fix is possible. > > I'd say this affects any platform on which overdraw, state changes, etc. > are expensive. Each CanvasItem is rendered 1 + N times, being N the > number of lights that intersect it. And before that, every light has to be > checked for intersection against every item. This checks is restricted to > what is visible in the viewport, and I don't know it it's a bottleneck, but > it has to happen. > > I tried to optimize the renderer with several approaches: > > - VBOs and some bookkeeping to reduce state changes: didn't pay, the > performance on mobile even worsened a bit; > - using the depth buffer to try to reduce drawn pixels and also > reduce state changes, it's work-in-progress, but probably won't work either; > - I implemented the AT_LIGHT_PASS shader builtin to at least get code > from the vertex and fragment shaders removed at runtime, for those > computations not needed in lighting, but with no big difference. > > Instead, the way to go would be to embrace some good practices: > > - keep the light count to the minimum; > - make them as small as possible; > - try to avoid intersection between lights; > - etc. > > If someone has a more promising approach, I'd be glad to hear it! > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#9944 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AF-Z20FKImUPJVfae0VvOQQ1ZSOICM5pks5sScTngaJpZM4OmV26> > . >

[Noisefever]

Just to remind: if I make "fake lights" using sprites with the blend mode "add" using the same texture, there is no slowdown! And that's the thing I don't get: this should be basically the same, or am I wrong?

[reduz]

It's not the same. As Pedro mentioned, lights need rendering the canvas items again in a different blend mode plus the light texture. This allows effects such as darkening the whole scene with a CanvasModulate and then making sections properly visible using a light. With just additive, you lose color precision

…

On Fri, Jul 28, 2017 at 8:35 AM, Noisefever ***@***.***> wrote: Just to remind: if I make "fake lights" using sprites with the blend mode "add" using the same texture, there is no slowdown! And that's the thing I don't get: this should be basically the same, or am I wrong? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9944 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z20-iqqLA-gQw55iXFBmkptEBIZY2ks5sSceBgaJpZM4OmV26> .

[Noisefever]

Okay, I see. Tried to remember how I do this in my animation software. There I have a black layer, mix the lights in using "add", group the layers together and "subtract" the whole group. I thought Godot does that the same way. Seems I have to rebuild that by hand (and hope it makes a difference).

[ghost]

i did what @Noisefever is doing, basically fake lights. if you have more than

5 of these kind of textures on a screen, with a light2d it will start to drop fps on a gtx 950

however, reduz is right the fake lights don't look the same.. maybe i should try a different texture (even smaller) and test that

i really want to incorporate torch lighting and stuff, but hell, if you get 3 or more torches in a room and if your character has a light2d.. fps is already getting smashed lol

[Calinou]

GLES2 Light2D rendering performance has been improved since 3.2.2 thanks to the introduction of 2D batching and light scissoring. GLES3 Light2D rendering performance also has been improved in 3.2.4beta1 onwards thanks to #42119, closing.

Also, 4.0 will feature significantly improved 2D lighting performance in its Vulkan renderer. thanks to a single-pass approach.