It's less code, and blit() already handles scaled painters.
Fixes the window server asserting in highdpi mode with a centered
background image. Part of #5017.
This apparently was a workaround for escape sequences in GML at some
point (see #4937), but it now literally inserts "\n" and no newline, as
the backslash itself is escaped.
These are 2x the smallest 4 resolutions. When picking one of these
in 1x and then half the size in 2x, the window server adjust the
ui scale factor, but the actual framebuffer size doesn't change.
2560x1440 also happens to be 5k resolution and monitors with that
resolution do exist -- so that seems like a good upper limit :)
For now, only support 1x and 2x scale.
I tried doing something "smarter" first where the UI would try
to keep the physical resolution constant when toggling between
1x and 2x, but many of the smaller 1x resolutions map to 2x
logical resolutions that Compositor rejects (e.g. 1024x768 becomes
512x384, which is less than the minimum 640x480 that Compositor
wants) and it felt complicated and overly magical.
So this instead just gives you a 1x/2x toggle and a dropdown
with logical (!) resolutions. That is, 800x600 @ 2x gives you
a physical resolution of 1600x1200.
If we don't like this after trying it for a while, we can change
the UI then.
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
This is in preparation of adding (much) more process information to
coredumps. As we can only have one null-terminated char[] of arbitrary
length in each struct it's now a single JSON blob, which is a great fit:
easily extensible in the future and allows for key/value pairs and even
nested objects, which will be used e.g. for the process environment, for
example.
Now, `chres 640 480 2` can set the UI to HighDPI 640x480 at runtime. A
real GUI for changing the display factor will come later.
(`chres 640 480 2` followed by `chres 1280 960` is very fast since
we don't have to re-allocate the framebuffer since both modes use
the exact same number of physical pixels.)
For small rects there was a disagreement between two parts of the
layout algorithm. There is a function that decides if there is
enough space in a rectangle for a label. But this function was
called on two slightly different rectangles.
This API was a mostly gratuitous deviation from POSIX that gave up some
portability in exchange for avoiding the occasional strlen().
I don't think that was actually achieving anything valuable, so let's
just chill out and have the same open() API as everyone else. :^)
