Accept performance optimization PR into main
harbdog opened this issue ยท 4 comments
This issue is to continue the conversation and track getting performance optimizations from @ovk in PR #27 into the main branch so it can be consumed by all.
These changes are currently being managed separately in the ovk_performance branch while being evaluated.
Since I was still unable to see any net performance benefits I decided to look into the separate pieces of what was in the ovk_performance branch and tried them out independently of each other.
-
Updating Ebitengine from 2.3 to 2.4 seems to have made a big improvement in framerate (and also fixed disabling Vsync on Windows/DirectX). This change has now been merged into main and released as v1.6.3
-
The Ebitengine 2.4 update alone brought it FPS to baseline of ~110+ (default resolution, initial scene view, with Vsync turned off), whereas the branch containing just the "replacePixels" and associated changes sees the FPS cap out in the ~70+ FPS area in the same scene.
- main...perf_remix_replacePixels
- From the raycaster-go-demo project:
git checkout perf_remix_replacePixels go run main.go
ๆ่ฐขไฝ่
Release v1.6.4 now has performance optimizations using image.WritePixels (previously ReplacePixels), it required writing to an image separately and then drawing that image on the screen to see performance gains (~15 fps more).
Big thanks to "Zyko" from the Ebitengine discord channel on suggesting not using WritePixels directly on the screen image!
- The last part to evaluate were changes to the async methods being used. I've put up a "perf_remix_asyncStride" branch on raycaster-go and raycaster-go-demo with only this change added (though prior to the WritePixels update), and saw no real noticable change in fps, maybe +1 at best but that's difficult to justify at this time. I may have to try it again on top of the new improved WritePixels update.
Performance improvements have been made to best of my current ability, may revisit sometime in the future after I get a chance to learn more about parallel/async patterns, since the current methods are what I came up with after first learning to program with Golang.