Open jaymehta-g opened 8 months ago
Ive been having this issue on my setup too (first Fedora 38 and now Fedora 39 both exhibiting the issue). It seemed to run smoothly when i made the window smaller (ive been using that as a temporary fix) which makes it seem like its a rendering thing. I ran cpu profiling with visualvm and that indeed does seem to be where the slow down is coming from:
I first maximized mcaselector and opened a world, then started the profiling and began moving around in mcaselector a bit until i had gone on for a bit the results looked like this:
Noticing the high usage on drawing the chunk grid i then turned it off and did it again yielding these results:
I wonder if switching to a drawing method other than canvas (like the ones suggested here) would help. To me it seems a bit like the javafx canvas implementation on linux is just slow (though more testing and research is probably needed to confirm or deny that) so there might not be much else than switching to something more performant that can be done.
Addition: Researched a bit more and found mentions of some people experiencing slow downs because JavaFX was failing to use hardware acceleration however after checking that it wasnt that. JavaFX was using hardware acceleration just fine.
"-Dprism.forceGPU=true" did the trick for me
Describe the bug Program works as expected but is painfully slow. Scrolling around the world, zooming, selecting/unselecting, all take several seconds for the screen to update.
To Reproduce Steps to reproduce the behavior:
Environment (please complete the following information):
Additional context Add any other context about the problem here, e.g.:
expand for specs