I came across this very often when making menus because I tend to close paintball after testing, make changes to the menu file and then reopen it to look at the result again. For me, that gives two advantages over keeping the game running and using menu_reload: First, there is no GPU / CPU load when paintball is not running, so these parts don't heat up and produce noise. Second, my task bar is less cluttered. As the game takes less than a second to start and load a menu when using a bind or modified link, I don't see any disadvantages of doing it that way - except that you get these artifacts.
When implementing or changing widgets for any ingame menu, you have to recompile and restart to test changes, so if you don't want to load a map, you pretty much will always come across this.
On the other hand: Yes, you are right, a "normal" user would never see this and for debugging purposes I could temporarily add a background to the menu files - but I'm lazy
.
In my opinion, accepting that minimal performance cost to eliminate the possibility of having these artifacts is worth it, but that is your decision. I just wanted to hear your opinion about this.
Anyway, I took a look at it and will append a really small patch file that would change the menu code to render cl_conback if there is nothing behind the first (bottommost) menu screen rendered. It's up to you whether you think it is unnecessary or too much of a performance hit.
By the way: What a shame people can't compile and use their own clients - I would do that right here.
//Edit: changed it a little bit to avoid unnecessary calls to DrawFindPic, although I couldn't measure any performance improvements.
