Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibGfx/ShareableBitmap.h

52 lines
908 B
C
Raw Normal View History

Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
*/
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
#pragma once
#include <AK/RefPtr.h>
Everywhere: Avoid large rebuilds when editing (Immutable)Bitmap headers This reduces the number of recompiled files as follow: - Bitmap.h: 1309 -> 101 - ImmutableBitmap.h: 1218 -> 75
2025-11-23 13:07:35 +01:00
#include <LibGfx/Forward.h>
LibIPC+Everywhere: Change IPC decoders to construct values in-place Currently, the generated IPC decoders will default-construct the type to be decoded, then pass that value by reference to the concrete decoder. This, of course, requires that the type is default-constructible. This was an issue for decoding Variants, which had to require the first type in the Variant list is Empty, to ensure it is default constructible. Further, this made it possible for values to become uninitialized in user-defined decoders. This patch makes the decoder interface such that the concrete decoders themselves contruct the decoded type upon return from the decoder. To do so, the default decoders in IPC::Decoder had to be moved to the IPC namespace scope, as these decoders are now specializations instead of overloaded methods (C++ requires specializations to be in a namespace scope).
2022-12-22 20:40:33 -05:00
#include <LibIPC/Forward.h>
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
namespace Gfx {
class ShareableBitmap {
public:
Everywhere: Avoid large rebuilds when editing (Immutable)Bitmap headers This reduces the number of recompiled files as follow: - Bitmap.h: 1309 -> 101 - ImmutableBitmap.h: 1218 -> 75
2025-11-23 13:07:35 +01:00
ShareableBitmap();
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
LibGfx: Short-circuit ShareableBitmap construction in IPC decoder When decoding a ShareableBitmap that came over IPC, it's safe to assume that it's backed by an anonymous file (since we just decoded it.)
2021-01-16 11:23:22 +01:00
enum Tag { ConstructWithKnownGoodBitmap };
ShareableBitmap(NonnullRefPtr<Gfx::Bitmap>, Tag);
Everywhere: Avoid large rebuilds when editing (Immutable)Bitmap headers This reduces the number of recompiled files as follow: - Bitmap.h: 1309 -> 101 - ImmutableBitmap.h: 1218 -> 75
2025-11-23 13:07:35 +01:00
~ShareableBitmap();
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
Everywhere: Avoid large rebuilds when editing (Immutable)Bitmap headers This reduces the number of recompiled files as follow: - Bitmap.h: 1309 -> 101 - ImmutableBitmap.h: 1218 -> 75
2025-11-23 13:07:35 +01:00
ShareableBitmap(ShareableBitmap const&);
ShareableBitmap(ShareableBitmap&&);
ShareableBitmap& operator=(ShareableBitmap const&);
ShareableBitmap& operator=(ShareableBitmap&&);
bool is_valid() const;
Bitmap const* bitmap() const;
Bitmap* bitmap();
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
private:
LibGfx: Use ErrorOr<T> for Bitmap infrastructure used by ShareableBitmap This also allows us to get rid of the ShareableBitmap(Bitmap) constructor which was easy to misuse. Everyone now uses Bitmap's to_shareable_bitmap() helper instead.
2021-11-06 13:15:43 +01:00
friend class Bitmap;
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
RefPtr<Bitmap> m_bitmap;
};
}
namespace IPC {
LibGfx: Templatize Point, Size, and Rect
2020-07-25 21:31:47 -07:00
Userland: Properly define IPC::encode and IPC::decode specializations In order to avoid the base encode/decode methods from being used (and failing a static assertion), we must be sure to declare/define the custom type implementations as template specializations. After this, LibIPC is no longer sensitive to include order.
2022-11-15 11:24:59 -05:00
template<>
LibIPC+Everywhere: Change IPC::encode's return type to ErrorOr In doing so, this removes all uses of the Encoder's stream operator, except for where it is currently still used in the generated IPC code. So the stream operator currently discards any errors, which is the existing behavior. A subsequent commit will propagate the errors.
2023-01-01 23:37:35 -05:00
ErrorOr<void> encode(Encoder&, Gfx::ShareableBitmap const&);
Userland: Properly define IPC::encode and IPC::decode specializations In order to avoid the base encode/decode methods from being used (and failing a static assertion), we must be sure to declare/define the custom type implementations as template specializations. After this, LibIPC is no longer sensitive to include order.
2022-11-15 11:24:59 -05:00
template<>
LibIPC+Everywhere: Change IPC decoders to construct values in-place Currently, the generated IPC decoders will default-construct the type to be decoded, then pass that value by reference to the concrete decoder. This, of course, requires that the type is default-constructible. This was an issue for decoding Variants, which had to require the first type in the Variant list is Empty, to ensure it is default constructible. Further, this made it possible for values to become uninitialized in user-defined decoders. This patch makes the decoder interface such that the concrete decoders themselves contruct the decoded type upon return from the decoder. To do so, the default decoders in IPC::Decoder had to be moved to the IPC namespace scope, as these decoders are now specializations instead of overloaded methods (C++ requires specializations to be in a namespace scope).
2022-12-22 20:40:33 -05:00
ErrorOr<Gfx::ShareableBitmap> decode(Decoder&);
LibGfx: Templatize Point, Size, and Rect
2020-07-25 21:31:47 -07:00
LibGfx+LibIPC: Add Gfx::ShareableBitmap, a bitmap for easy IPC usage With this patch, it's now possible to pass a Gfx::ShareableBitmap in an IPC message. As long as the message itself is synchronous, the bitmap will be adopted by the receiving end, and disowned by the sender nicely without any accounting effort like we've had to do in the past. Use this in NotificationServer to allow sending arbitrary bitmaps as icons instead of paths-to-icons.
2020-03-29 19:04:05 +02:00
}
Reference in a new issue Copy permalink