This patch replaces the use of shbufs for GUI::Window backing stores
with the new anonymous files mechanism.
Backing bitmaps are now built on memory allocated with anon_create().
They are passed across the IPC socket as IPC::File. This means that
WindowServer now pledges "recvfd" and graphical clients need to pledge
"sendfd" to work.
To support the cached bitmap swapping optimization on the WindowServer
side, each backing store is assigned an incrementing serial number on
the client side. (This allows us to re-use an already mapped file.)
This patch adds a new AnonymousFile class which is a File backed by
an AnonymousVMObject that can only be mmap'ed and nothing else, really.
I'm hoping that this can become a replacement for shbufs. :^)
Instead of storing the back/front buffers of a GUI::Window as just
Gfx::Bitmap, wrap them in a WindowBackingStore class.
This will allow us to add more information alongside the bitmaps while
keeping the back/front swapping logic simple.
Problem:
- `HttpProtocol::start_download` and `HttpsProtocol::start_download`
implementations are the same except for a few types.
Solution:
- Follow the "Don't Repeat Yourself" mantra and de-duplicate the code
using templates.
Problem:
- Access to the underlying type is not provided. This limits
metaprogramming and usage in function templates.
Solution:
- Provide public access to the underlying type.
- Add test to ensure the underlying type is accessible.
Problem:
- The implementation of `find_first_of` is coupled to the
implementation of `StringView`.
Solution:
- Decouple the implementation of `find_first_of` from the class by
using a generic `find` algorithm.
Problem:
- Raw loops are often written to validate that any values in a
container meet a predicate, but raw loops are not as expressive as
functions implementing well-named algorithms and are error-prone.
Solution:
- Implement a very generic form of `any_of`.
This broke when switching IPC messages to support move-only types.
This pattern is not ideal, but the real fix for this will be using fd
passing instead of shbufs.
Fixes#4955.
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.
If you don't need a file descriptor after sending it to someone over
IPC, construct it with IPC::File(fd, IPC::File::CloseAfterSending)
and LibIPC will take care of it for you. :^)
When receiving a file descriptor over IPC, the receiver must now call
take_fd() on the IPC::File to take over the descriptor. Otherwise,
IPC::File will close the file on destruction.
SOCK_NONBLOCK is a linux-ism that serenity and linux support. For lagom
builds, we use ioctl/fcntl to get a non-blocking socket the old
fashioned way. Some file re-org unhid the fcntl.h dependency of TcpServer,
so add the header explicitly.
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. :^)
This adds a scale factor to Painter, which will be used for HighDPI
support. It's also a step towards general affine transforms on Painters.
All of Painter's public API takes logical coordinates, while some
internals deal with physical coordinates now. If scale == 1, logical
and physical coordinates are the same. For scale == 2, a 200x100 bitmap
would be covered by a logical {0, 0, 100, 50} rect, while its physical
size would be {0, 0, 200, 100}.
Most of Painter's functions just assert that scale() == 1 is for now,
but most functions called by WindowServer are updated to handle
arbitrary (integer) scale.
Also add a new Demo "LibGfxScaleDemo" that covers the converted
functions and that can be used to iteratively add scaling support
to more functions.
To make Painter's interface deal with logical coordinates only,
make translation() and clip_rect() non-public.
The underlying fill_rect() works correctly, but the special case for
thickness = 1 was not blending the new color with the target pixel's
color, causing RGBA colors to be painted as their RGB counterpart.
I have a local branch that gets us past implementation stage 1
in this doc, and it seems like a useful enough checkpoint to
upstream it and then iterate in tree.
