Fix _get_debug_tooltip crash if tooltip string is too large

[jsjtxietian]

This pr solves part of #80959

There are three problems raised from this issue, this pr only deals with the problem that if the stack variable's tooltip string is smaller than 1Mb ( if bigger than 1Mb, the case is addressed by another pr) but still very big, vulkan will crash at creating the buffer for the tooltip's flat style box since it's too long.

I choose to truncate the string at position 200 and append a ' [...] overflowed!' at the end of the string. The number is arbitrary but I dont think it's necessary to expose the value for user to config.

[bitsawer]

Related / Alternative PR:

• Log when debugger drops large variables. #74148

[jsjtxietian]

• Log when debugger drops large variables. Log when debugger drops large variables. #74148

Oh I missed that, but there is on other thing I can do to help this pr.

[miv391]

I would suggest word "truncated" instead of "overflowing". Overflow sounds like an error to me.

[YuriSizov]

I think that warning is excessive, and will end up spamming users that hover over some long values. Nothing they can do about it either, so it's not very useful.

I also think 200 is a very short threshold? What kind of content do we expect there?

[jsjtxietian]

I also think 200 is a very short threshold? What kind of content do we expect there?

Just the content shown when you hover over a gdscript variable. The crash I tried to fix comes from a extremely large json map, the whole content of this map will crash vulkan since the tooltip box is too long, vma can't allocate so much big.

[YuriSizov]

@jsjtxietian Well, yes, I understand that. But I assume that a very large JSON is far beyond 200 characters? I'm just trying to see if this is not an overzealous threshold.

[jsjtxietian]

a very large JSON is far beyond 200 characters

Yes, > 1w characters.

I'm just trying to see if this is not an overzealous threshold.

It maybe too small, but as far as I can see, a tooltip longer than several dozens is already hard too read. 200 is just an arbitary number I chose, it can be changed. Just a safe guard to prevent vulkan's crash.

I feel the ultimate solution for this should be a tooltip like what you can get from visual studio (rather than just a tip) , you can expand it to see the whole content.

[Calinou]

I think this threshold can be extended to 250 or even 300, but I'm fine with the idea in principle. Remember to test this at high editor scales too, as the issue may occur earlier at high editor scales.

[jsjtxietian]

I think this threshold can be extended to 250 or even 300, but I'm fine with the idea in principle. Remember to test this at high editor scales too, as the issue may occur earlier at high editor scales.

Tested locally, 300 with scale at 200% is fine.

[YuriSizov]

Tested locally, 300 with scale at 200% is fine.

Not that it matters much whether it's 200 or 300, but let's go with that, I guess :) Could you also put the number into a local constant so it's easier to modify if needs be and so it's less magical?

[jsjtxietian]

Oh another thing, I just found that we can use '\n' to seperate strings so they won't become too long, should I do something like , let's say after every 50 characters, insert a '\n' into it.

[YuriSizov]

I think for now plugging the crash is what's important. Improving usability or solving this in a better way can be done later.

[YuriSizov]

Thanks!

[YuriSizov]

Cherry-picked for 4.1.4.