search

Return-To-The-Roots / s25edit

Fork of Launchpad: Worldeditor by XaserLe
https://code.launchpad.net/~xaserle/s25rttr/s25edit
4 stars 4 forks source link

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

Open stefson opened 4 years ago

stefson commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

Flamefire commented 4 years ago

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 944cd87601969edd1d1c34472caeda16b70892c2 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.

-->

Hence me closing this.