Sudden CPU spike when VertexArray reaches a certain size (1040)

[adcgx]

Issue details

Displaying a certain number of chars in a TextArea / TextField / Label (I'm suspecting pretty much everything than renders BitmapFonts?) on a stage, causes sudden increase in CPU usage. The exact number of chars differs depending on unknown circumstances (which font used perhaps?). In the test below, going from 33 to 34 chars in the TextArea (and again from 42 -> 43) causes huge increase in CPU usage. Only tested on desktop/windows. If you get this bug, but the number of chars needed to reproduce is different, please post how many.

Reproduction steps/code

import com.badlogic.gdx.*;
import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.scenes.scene2d.Stage;
import com.badlogic.gdx.scenes.scene2d.ui.*;

// Notice how CPU usage will spike at 34 chars, and then spike even further at 43

public class DesktopLauncher extends ApplicationAdapter {
    Stage stage;
    TextArea textArea;

    public void create () {
        stage = new Stage();
        Gdx.input.setInputProcessor(stage);
        Skin skin = new Skin(Gdx.files.internal("data/uiskin.json"));
        textArea = new TextArea("TextArea test", skin);
        textArea.setWidth(400);
        textArea.setHeight(400);
        textArea.setPosition(40, 70);
        stage.addActor(textArea);

    }

    public void render () {
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
        stage.act();
        stage.draw();
    }

    public void resize (int width, int height) {
        stage.getViewport().update(width, height, true);
    }

    public static void main (String[] args) throws Exception {
        LwjglApplicationConfiguration config = new LwjglApplicationConfiguration();
        config.foregroundFPS = 0;
        config.vSyncEnabled = true;
        new LwjglApplication(new DesktopLauncher(), config);
    }
}

Version of LibGDX and/or relevant dependencies

Tested: 1.7.1 + 1.9.2

Please select the affected platforms

• Android
• iOS
• HTML/GWT
• Windows
• Linux
• MacOS

[davebaol]

Looks like I don't have any noticeable increase in CPU usage.
Windows 7 here.

[adcgx]

Did you try just adding chars to see if it suddenly jumps? I have no clue what factors are involved in deciding what the "magic number" is, it could be a hardware thing,

[xoppa]

Can reproduce the issue. Although, at least in my tests, it seems like the high cpu usage is not constant. E.g. the cpu usage might drop after a while to normal values. If I understand correctly, @Tom-Ski had some more constant results in reproducing it. I could not reproduce it on LWJGL3. With LwjglApplicationConfiguration#useGL30 set to true it seems like to always have a higher CPU (probably not related to this issue, see #3593 for details).

SpriteBatch uses VertexArray (when not gles3), using VBO instead seems one way to fix this issue. I think that SpriteBatch might use VA instead of VBO based on tests which might be somewhat outdated now that gles1 is no longer supported. Therefor I added a deprecated SpriteBatch.defaultVertexDataType member for easy testing the difference between the two.

Could you check whether, with latest nightly, adding the following line in your create method fixes it?

SpriteBatch.defaultVertexDataType = VertexDataType.VertexBufferObject;

[Darkyenus]

How would that relate to triggering only when certain amount of chars? Wouldn't VA/VBO just result in bigger CPU usage overall? It is possible, just a bit strange IMO.

[Tom-Ski]

This isn't just related to fonts. Its just about the number of vertices in the vertex array. When it hits the magic number (34 font characters, and add on the triangles for the background and other styling in the default uiskin for TextField). Is reproducible by using Sprites alone (52 Sprites).

[adcgx]

@xoppa Sorry for the late reply, I havn't been able to test it until now, but yes, it does indeed seem to fix the issue! I also noticed that turning off vsync (and then instead capping foregroundFPS to 60) also seems to 'fix' it.

[Tom-Ski]

#3916