-
Notifications
You must be signed in to change notification settings - Fork 141
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
Terrible FlxSliceSprite performance on native #404
Comments
HashLink seems to have a huge issue with large I'm making a small side-project game and I wanted to have a pop-up menu use a SliceSprite as a background. Thinking it was just the alpha that was causing this, I switched to a regular I swapped the SliceSprite out for a I have not tested this with this new project - yet - but I have another project with lots of |
@SeiferTim did you notice this section:
you might get better performance on HL with these fields set to true, especially if you're using small source images. This is due to the fact that the default values will tile the image, in my case, using 36000% more vertices |
Well, this did not seem to make a difference. |
The performance is only bad on HL? does making the size smaller improve performance at all? is it possible you're setting the width or height every frame, even if it's setting it to the same values used previously? |
HTML5 and Windows run at 60fps The HiScore screen has a few flxsprites, and a few FlxBitmapTexts nothing too crazy. Simply removing the Frame fixes the framerate. so it's definitely that. The frame is being initialized in the I'm using this class:
I'd be happy to show you code or anything in Discord if you want. |
Sounds like its not anything you're doing wrong, just wanted to check. HL is new and maybe openfl's hl backend is wonky, and requires a deep dive 🤷♂️ |
I've only tested on mac, but adding the following to the FlxCamera demo brings the fps from 60-62 down to 20-23
Edit: upon further investigation, the above code struggles because when width and height are 1280 by 960, this is using 25,480 vertices to draw this. By adding the following lines, the vertex count goes down to 72!
This still doesn't explain why the performance issue was only worse when FlxG.drawDebug is enabled, though. but the above change eliminates the performance issue, entirely. Perhaps drawDebug is a red herring, and the usual slowdown from drawDebug made a more noticeable impact when combined with the slowdown caused by the inefficient slice sprite vertices.
FlxStrip is capable of rendering a repeating image across, for instance:
results in the following:
However this may not be applicable to FlxSliceSprite, because it's not repeating the entire texture, but only a middle portion.
Whenever I make sliceSprites I typically make the middle sections as small as possible, as I expect them to be stretched, by default and i want image sizes to be as small as possible. I do think think it makes sense to make these stretch flags true, by default, given that seemingly insignificant factors like image size and rect size can have exponential impacts on the performance and memory of slice sprites
The text was updated successfully, but these errors were encountered: