Unreasonably poor perfomance in main menu

[AlexanderR]

I have recently installed fresh Arch Linux and latest 2D drivers on my notebook along with LLVM-backed Mesa 3D renderer. 3D perfomance is poor but 2D is nice - Teeworlds works with 20-30 fps, for example.

The question is - why does pure 2D animation in main menu go with 3-5 fps?

[historic_bruno]

Does it slow when you use the menus or is it that slow from the start? Maybe the large (2048x1024) background texture is causing some problems.

[fabio]

Can you attach the output of glxinfo -l

[AlexanderR]

Replying to historic_bruno:

Does it slow when you use the menus or is it that slow from the start? Maybe the large (2048x1024) background texture is causing some problems.

from the start

[AlexanderR]

output of glxinfo -l

[AlexanderR]

Replying to fabio:

Can you attach the output of glxinfo -l

Ok.

[fabio]

According to glxinfo you are running with software renderer:

OpenGL renderer string: Gallium 0.4 on llvmpipe

No surprise it is so slow...

Please post the output of

lspci -v|grep -i vga

[Philip Taylor]

Yeah, llvmpipe is currently too slow to play the game at all (I typically get about 2fps on my computer at 1024x768), so it doesn't seem worth optimising the main menu for it. If llvmpipe becomes usable in the future (e.g. the implementation is improved, or CPUs get faster, or we add a very-low-quality graphics mode to the game) then it might be good to revisit this, but currently I don't think we should work on it.

(If the menu is slow on any real hardware-accelerated graphics cards then we should fix it, but that would be a different bug.)

I expect the menu is particularly slow because it's drawing several fullscreen textures with scaling (to fit the window) and bilinear filtering (to pan slowly and smoothly). GPUs are very fast at that, and software renderers are very slow at that. Other games using OpenGL for 2D graphics are probably drawing unscaled unfiltered textures, which allows llvmpipe to go much faster than in the general case, but our current menu design requires the slow path instead.