Hey i have this weird thing.
Whenever i pick something up, ammo, weapon, if i have text drawn on my hud like the scale of the sniperzoom, it gets a bit bigger and then goes back to normal in a sec, this is very annoying since i want to draw text on the hud with my own sniper too.. my friend says that he had this too and he fixed it somehow but doesnt know anymore how. Is it something in the advanced options??

The way your friend may have fixed was by forcing a font in the canvas before drawing any text, as what happens in the regular sniper is that no font is defined before the text drawing, and if a bigger or smaller font was already defined earlier in another canvas (since the Canvas is all pretty much the same), that value is retained and passed down and therefore affecting any text drawing with no font change.

Also, before doing anything on Canvas, is a good practise to make perhaps this instead:

Yeah, the default font is non-existent, I didn't realize that 7 years ago.

Having that said, what you're suggesting doesn't solve the problem the OP asked about at all, it only worsens it given that then you pick up whichever font is set at the time of that first call and force it forever, meaning that such a solution is non-deterministic.
In other words, if the canvas ends up having at huge font at first for whichever reason, you're doomed to always see everything else from there in that context using that font and not the desired one.

Yep. I know that. But you can set your Font very early.
Because you do not know which font is really used.
Because if you used fix font then it big on small screens and small on big.
I investigate this issue before make this solution.

It doesn't necessarily have to be a fixed hardcoded font, this could as easily be a function call, using the Canvas as an argument, which would return the right font to use, and it would work 100% of the time, unlike what you're proposing.
You shouldn't assign state to something that can be stateless, or in other words, you shouldn't save things in vars when you can achieve the same by calling a deterministic function (except in cases where the function is heavy, and there you use a var for caching purposes only: memoization).

dot wrote:About 7 years - I need place this code somewhere. I can create new topic if you want.

I didn't mean anything big with it, it was mostly to make sure that you actually saw the date of this topic.

It's up to the moderators/admins how they prefer to go with this, but for what's worth, in my own personal opinion you should just check the date of the post and ask yourself if what you want to post is valuable enough to resurrect topics with almost a decade, or if it should be better to make a post with an aggregation of the ideas and solutions that you have in a more generic way, maybe by referencing these topics.

If it's just to give a very specific small alternate solution for a very old topic for a very specific small problem, maybe it's not worth it.

In this case I don't really see a big problem in posting in this one, but just make sure you don't resurrect too many old topics, otherwise the visibility of new posts may get lost between ancient topics, and other posters may not check the previous post dates and think these are recent things, which are not.
This forum should probably just have an automatic archival of old topics though.

For example: when you change the resolution in mid-game, your font will be bigger or smaller than intended.
And it's not as infrequent as it may sound, I can just Alt+Enter to window mode with a different resolution.

Like I said above: you shouldn't assign a state to something which doesn't have to be stateful, since it brings all sorts of edge cases and whatnot like the one above, unnecessarily so.
Any performance gains that you're trying to get there are negligible, and make the code be worse and more complicated overall than it should be.

Then need save width of Canvas and if it changed get Font from scratch. Else use cache.
This is from UT code.https://github.com/Slipyx/UT99/blob/a26 ... ontInfo.uc
I do not think they do this without reason.
And I do not think create new Font on every frame is good idea,
Maybe better be make own FontInfo and use non-static methods from it.
It is already use cache.

Notice that no actual "new" fonts are created, it's just a class reference, and always the same class reference in the end, although looking into the function itself (which I didn't at the time) it has DynamicLoadObject calls, which are indeed slow, and should indeed be taken into consideration.

What you pointed out was exactly what I was mentioning before: that's memoization, caching the results of function calls into vars, so that the heavy parts of a function do not need to run again in the subsequent calls.

But notice that still doesn't invalidate what I mentioned overall.
While it would indeed be a bad idea to call this function directly every frame, all that actually needs to be done is to just instantiate the FontInfo itself, either directly or through a similar way as TournamentScoreBoard:

and you get the same thing, but memoized for free already in the FontInfo actor instance itself.

By the way, in this example it is assumed that you spawn the FontInfo only once, and keep the FI as a var.
In a way, this is similar to your proposed solution, except that here rather than saving the font itself, you save the actor which actually provides the fonts, and this way you have no issues whatsoever for 100% of the use-cases, and you also get all the caching/performance benefits you want.

Solution with two variables is more easy, clear and light.
Because new Actor need more memory and use more resources. And for it called tick method and so on.
But if you need not one Font this can be not good solution rather reinvented wheel and make same code in your class.
But for one Font it can be overhead.

You're worried about spawning a single actor, which is spawned only once and lasts the entire game lifetime, when the standard game itself spawns hundreds of actors constantly, some of which actually run code every single tick.
That's like worrying about a big lake flooding a village only because you dropped a single drop of water on it, it doesn't make any sense.

I understand that you want your code to be efficient, everyone wants the same, but you're putting optimization ahead of design, and that approach has been proven over and over again to cause much bigger problems either immediately or later on in the code, in the form of code that no one will want to use because it will break all sorts of stuff or have all sorts of weird hardcoded behaviors.

The moment you're just replicating code around just to avoid to spawn an actor, that's a dead end as far as maintainable code goes, and shifts your own focus from what you should actually paying attention to in the first place, which is how all the pieces actually fit together overall.