Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very poor screen/button performance #5508

Closed
Charmareian opened this issue May 13, 2024 · 8 comments
Closed

Very poor screen/button performance #5508

Charmareian opened this issue May 13, 2024 · 8 comments

Comments

@Charmareian
Copy link

Charmareian commented May 13, 2024

I honestly don't think this is something that could be fixed, but I noticed Renpy screens/buttons can tank performance. Not sure if there's a way to mitigate this.

2024-05-13.01-59-00.mp4

It seems like disabling the transform that makes the icons go up and down increases fps by 20. That's kind of insane.

2024-05-13.02-13-25.mp4
@HorBro38
Copy link

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

loafylemon commented May 27, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants