* Fix: 'Cache' top and bottom lines of textfile viewer to avoid overdraw.
The text file viewer calculated the number of lines required to set the scrollbar, but did not retain this information, so this was recalculated on every draw operation. This includes overdrawing text outside the bounds of the current scroll position.
With this change the top and bottom lines for each line of text are remembered, and reflowing is avoided where possible. Text outside the current scroll bounds is not drawn.
Additionally the scroll interval is now based on text lines instead of pixel lines, which increases the text capacity depending on the font size.
* Fix: Limit text viewer to showing 64k lines.
Text files with more than 64k wrapped lines would exceed the scrollbar capacity and cause an assert. This is harder to reach now that the scrollbar counts lines instead of pixels.
(cherry picked from commit 0b460bf4a1)
This happens if the bounding dimensions are changed so that each item is the same size, as happens on the railtype/roadtype dropdown lists, as the vertical offset was calculated before this dimension is changed.
(cherry picked from commit ae7f07de74)
YAPF was constantly measuring its performance, but only at
certain debug-levels this information was shown.
Now after years, I sincerely wonder if anyone still knows about this
feature and who still use it. Especially with the new framerate window,
this detailed performance is not as meaningful anymore as it once
was.
(cherry picked from commit 665a3928e2)
Currently we use default OS timeout for TCP connections, which
is around 30s. 99% of the users will never notice this, but there
are a few cases where this is an issue:
- If you have a broken IPv6 connection, using Content Service is
first tried over IPv6. Only after 30s it times out and tries
IPv4. Nobody is waiting for that 30s.
- Upcoming STUN support has several methods of establishing a
connection between client and server. This requires feedback
from connect() to know if any method worked (they have to be
tried one by one). With 30s, this would take a very long time.
What is good to mention, is that there is no good value here. Any
value will have edge-cases where the experience is suboptimal. But
with 3s we support most of the stable connections, and if it fails,
the user can just retry. On the other side of the spectrum, with 30s,
it means the user has no possibility to use the service. So worst case
we annoy a few users with them having the retry vs annoying a few
users which have no means of resolving the situation.
They are likely not working as expected on Windows, so prevent their usage.
Winsock does not set errno and strerror does not return anything useful for Winsock error numbers.
english (us): 39 changes by 2TallTyler
korean: 44 changes by telk5093
german: 43 changes by danidoedel
russian: 7 changes by Ln-Wolf
finnish: 39 changes by hpiirai
norwegian (bokmal): 4 changes by Anolitt
spanish (mexican): 3 changes by absay
japanese: 60 changes by scabtert, 38 changes by Azusa257
english (us): 3 changes by 2TallTyler
korean: 3 changes by telk5093
russian: 4 changes by Ln-Wolf
finnish: 3 changes by hpiirai
slovak: 20 changes by FuryPapaya
