Very poor screen/button performance about renpy

[HorBro38]

One thing you will want to make sure you are doing: Make sure you've cropped all your images for your buttons as close to the image as possible. Ren'py has to calculate the transparency for buttons when using focus_mask True to verify what is and isn't clickable in real time, so if the button is full screen (with the majority of it transparent) it can really tank performance (especially when you have dozens of them on a screen).

[Charmareian]

That's good to know, but I already do this. According to Pink Productions, the creator of the overworld system I'm using(Pink Engine) is a big contributing factor. Apparently Renpy needs to re-render the entire scene when buttons are interacted with, so this means it needs to re-render the the entire map when I interact with a button. So unless Renpy gets a more efficient renderer, I'm kinda screwed.

[renpytom]

What version of Ren'Py are you on? There was some work done on this recently, so if you're out of date, you might be able to get some easy fixes.

[Charmareian]

Renpy 8.2.1. On a similar note, does renpy.pause() need to re-render the entire scene as well? I've noticed some major performance drops with Pink Engine's NPC movement during events. To my knowledge these essentially spam renpy.pause(0.1) until a condition is met(finishing their movement). My battle system has a similar problem. I have a while loop with a renpy pause that keeps a screen open until a selection is made. This can tank performance in a similar matter. To be fair, these are both doing things not intended for Renpy at all.

[Charmareian]

Renpy 8.2.1. On a similar note, does renpy.pause() need to re-render the entire scene as well? I've noticed some major performance drops with Pink Engine's NPC movement during events. To my knowledge these essentially spam renpy.pause(0.1) until a condition is met(finishing their movement). My battle system has a similar problem. I have a while loop with a renpy pause that keeps a screen open until a selection is made. This can tank performance in a similar matter. To be fair, these are both doing things not intended for Renpy at all.

Seems like just having a longer pause of 1 second instead of 0.1 fixes any major drops with pausing, which makes complete sense.

[Charmareian]

I noticed bars are very expensive as well. Each of my buttons has 3 bars overlayed on top(One for HP, SP and XP). I thought it might be because they use an animated value, but that seems to make no difference. Each bar costs about 3fps. If I have a full party, I lose about 50-60fps on that menu.

[loafylemon]

I have noticed that displayables containing a tooltip property cause massive lag spikes on hover events. This is because they restart the interaction of every single displayable utilizing the tooltip property. We're talking about a drop from stable 144 FPS to ~60-70 FPS.

There's no telling if the issue is the same on your end, but here's the solution that worked for me:

init early hide:
    def set_focused(widget, arg, screen):
        global _tooltip
        renpy.display.focus.argument = arg
        renpy.display.focus.screen_of_focused = screen

        if screen is not None:
            renpy.display.focus.screen_of_focused_names = { screen.screen_name[0], screen.tag }
        else:
            renpy.display.focus.screen_of_focused_names = set()

        renpy.game.context().scene_lists.focused = widget
        renpy.display.tts.displayable(widget)

        # Figure out the tooltip.
        _tooltip = widget._get_tooltip() if widget else None

    # Monkey-patch focus in the Engine
    renpy.display.focus.set_focused = set_focused

default _tooltip = None

screen tooltip():
    window:
        id "tooltip"
        text "[_tooltip!i]" align (0.5, 0.5)

Keep in mind that this code may have side effects. The set_focused method is part of the Ren'Py engine, and modifying it could potentially break other parts of the engine. That said, I've been using this piece of code in my project for about a year and have noticed no negative side effects, and the performance bump is significant.

[renpytom]

I don't think there's an obvious way to solve this.

@loafylemon 's code disables updating the tooltip when it changes, at which point you might as well just not use it. Fundamentally, either you use tooltips are you don't,and if you use them, there's an associated performance hit from restarting the interactions when the tooltip changes.