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

/usr/bin/s25edit has poor performance on linux #22

Open
stefson opened this issue Nov 10, 2019 · 3 comments
Open

/usr/bin/s25edit has poor performance on linux #22

stefson opened this issue Nov 10, 2019 · 3 comments

Comments

@stefson
Copy link
Contributor

stefson commented Nov 10, 2019

on linux, the s25edit binary eats a whole core on my amd64 machine while in the menu, and continues to do so while editing maps. It still gives decent frames per seconds on a fast machine, but it's only 1-2 fps on the rpi2 :/

I tried to strace the s25edit binary, and it seems there's a ton of lseek () going on:
strace-log.zip

@Flamefire
Copy link
Member

I optimized the software renderer that is used here to the maximum I could do. We'd need to use the OpenGL renderer used in RttR main to get more performance but that's gonna take a while :/

So closing for now

@stefson
Copy link
Contributor Author

stefson commented Jan 4, 2020

I doubt this is going to be fixed anytime soon too, but if you confirm the bug once it should not be closed unless fixed properly. Even if that will take a really long time.

@Flow86 Flow86 reopened this Jan 4, 2020
@Flamefire
Copy link
Member

Sorry I was in a hurry:

s25edit binary eats a whole core on my amd64 machine while in the menu, and continues to do so while editing maps.

This was due to a missing frame rate limiter coupled with the limited performance of the software renderer. The former was added in 944cd87 and performance of the renderer was improved by several commits by about 15%. I doubt more is possible without a major rewrite which won't happen as a hardware renderer is more suitable. And getting a hardware render could be done by using the one from RttR main but that won't happen either. a) due to time constraints: it simply isn't important enough and b) the SW renderer has other benefits like using the algo from Xaser which can serve as an alternate implementation and check if it looks different/better than ours, which works completely different.

but it's only 1-2 fps on the rpi2

RPI is not a target platform for me (us?) and especially the editor is more an additional program which made sense to be integrated. Spending time optimizing for that case doesn't seem worth it, there is much more and more valuable things to do. Again: This would basically be a rewrite of the editor.

-->

  • 100% CPU consumption bug fixed
  • performance improved
  • rest: not a bug, won't do

Hence me closing this.

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

3 participants