FPS drop in the ship selection window

[CMDR Edu]

I hope that there will be an improvement in the window of selection of ships because this bothers us, especially in multiplayer where the whole game is laggy when we are exploring the list of ships

 

My English is bad, so I made a video to better demonstrate the problem.

Thank-you

 

[Kamo]

Ah that ::)

It's the thumbnail creating and/or loading

Try putting old ships in folders, the autosave sometimes goes (properly) paranoid :).

[ottodeluxe]

I have the same problem, however it is even more severe on my machine. Even with only 2-3 ships, my FPS drop to less than 1. Moving or deleting ships is not an option when I want to use workshop designs, and I cannot "avoid" the problem by only building my own ships, since the same UI is used for fighter crafting. When I click anything or press any button with the create fighter UI open, I have usually have an input delay of roughly 11 to 13 seconds until the game responds, while frames still come in every 2-3 seconds. And no matter how long the UI is open, the problem does not fix itself when all thumbnails are loaded. Even after letting the game sit for 20 mins I still have the same slowdown.

 

Is there no workaround at all?

 

edit: While scrolling (and I guess while loading the thumbnails) the game actually runs smoothly again. So on my end, it seems to be the rendering of the thumbnails that causes slowdowns. The game itself runs perfectly smoothly, including any other UI, massive battles, or any other kind of gameplay.

[ComfyDema]

I've nailed the problem down to being caused by the thumbnails, as it appears the thumbnails are fully rendered unmoving displays of the build itself rather than an image file, so far have not found a way around this, and i seem to lose frames hard as soon as there are more than 10 design thumbnails loaded at once

[ottodeluxe]

When I played around a bit with the debug info overlay, like the op, I also found that rendering took all the time. When I was monitoring my hardware load on a second monitor, I found my graphics card idle and Avorion maxed on one thread. So my best guess is that everything is rendered on CPU, even the stills, inside the UI thread.

My second best guess (before you had posted) was that the images were loaded, downscaled and then drawn *per frame*, maybe even with a very inefficient downscaling filter.

Your theory does sound more likely, though.

[ComfyDema]

When I played around a bit with the debug info overlay, like the op, I also found that rendering took all the time. When I was monitoring my hardware load on a second monitor, I found my graphics card idle and Avorion maxed on one thread. So my best guess is that everything is rendered on CPU, even the stills, inside the UI thread.

My second best guess (before you had posted) was that the images were loaded, downscaled and then drawn *per frame*, maybe even with a very inefficient downscaling filter.

Your theory does sound more likely, though.

 

i didn't find similar results when monitoring my hardware, i found that the CPU usage of Avorion only achieved 19% CPU usage at most, and and 42% GPU usage (bad GPU is bad), as well as only 1.2gb of ram. my theory is that it's due to the icons in the design menu being generated by an .xml instead of being actual images, which is causing the game to chug, which obviously it would when trying to render 30 images from 30 .xml's that're representing hundreds to millions of blocks