We started to creating our game in monogame and one of my co-worker had idea to draw our UI only in 20 or 30 fps - it should give us performance boost without any visible issues (later we could apply this to some “static” content like map drawing too).
Iam thinking that RenderTarget could be great candidate - we could draw into it and clear it at lower fps.
But I don’t know if it’s dead end or not.
So far we’ve tried to lower FPS in our basic “draw” method but we encountered flashing (from clear color) - our ui just dissapeared for a few milisecond
Is Rendertarget our solution or is there any better way to achieve it?
Might want to be careful you don’t end up using more resources optimizing, sounds like a rabbit hole I wouldn’t go down honestly
Sounds to me like you’re either accidentally clearing your render target every frame or only drawing it once every other frame. Remember that when you swap to a render target it clears the render target.
What is it that you are trying to achieve? Are you trying to optimize the amount of draws you do?
If your background is static you could always create a render target, draw all your background to it (if it’s composited rather than a single image) and then use it to draw on your main render target.
I would also caution about pre-mature optimization as you may be wasting your time for almost no gains.
Your solution is to not optimize prematurely. Are you experiencing slowdowns because of your UI? Does your UI contain literal tens of thousands of quads? If not, then you are wasting your time. I am90% sure your game will have much, much larger bottlenecks than drawing some healthbars.
I totally agree with others in that be careful how you optimize… having said that, there are some low hanging fruit that can be easy wins at the start so you don’t have to worry about it later.
One of these, especially on the UI front, can be text rendering. I’m not sure if anything’s changed since the XNA days, but it used to be that each glyph was effectively a texture render and so if you have a lot of them, it can add up. It’s all from the same texture so batching is usually pretty good, but when drawing UI there’s usually a lot of other stuff you draw also. Plus if the text isn’t changing, there’s really no point in rendering each glyph independently over and over.
You’ve already mentioned a mitigation for this… a RenderTarget2D object. It’s generally a fairly easy win to just cache the text you want to draw to a texture any time you have new text to draw. Then, on successive draws, you render that cached texture.
So while it’s 100% not a good idea to get too crazy on optimizations, there are generally some easy wins you can take if you want to to jump start. It’s probably worth a day of effort if you know what you want to do… but it’s probably not worth more than a couple days unless there’s some significant driver
I’ve used this approach a number of times, but most recently I did a text scaling prototype that included it. It’s just prototype code, but if you want to see an example of cached text rendering, you can find one there.
Thank you, we already implemented similar technique for text drawing
Also we agreed on that it is not necessary to implement lower fps UI rendering right now because it’s not really bottleneck and it would lead us into “premature optimizing” thing.
Anyway one of my colleague give it like half day and so far with lower fps rendering on UI we’ve got pretty satisfying results on our test machine. So it is not really dead end, but it’s not worth the time right now.
