beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-21 23:20:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibGfx/ShareableBitmap.h

44 lines
758 B
C
Raw Permalink Normal View History

Meta: Add missing copyright headers
2020-04-06 09:09:01 +00:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 11:19:50 +00:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
Meta: Add missing copyright headers
2020-04-06 09:09:01 +00: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 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add missing copyright headers
2020-04-06 09:09:01 +00: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 17:04:05 +00:00
#pragma once
#include <AK/RefPtr.h>
#include <LibGfx/Bitmap.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-23 01:40:33 +00: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 17:04:05 +00:00
namespace Gfx {
class ShareableBitmap {
public:
Libraries: Use default constructors/destructors in LibGfx https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 19:26:37 +00:00
ShareableBitmap() = default;
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 17:04:05 +00: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 10:23:22 +00:00
enum Tag { ConstructWithKnownGoodBitmap };
ShareableBitmap(NonnullRefPtr<Gfx::Bitmap>, Tag);
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 17:04:05 +00:00
bool is_valid() const { return m_bitmap; }
Everywhere: Run clang-format
2022-04-01 17:58:27 +00:00
Bitmap const* bitmap() const { return m_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 17:04:05 +00:00
Bitmap* bitmap() { return m_bitmap; }
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 12:15:43 +00: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 17:04:05 +00:00
RefPtr<Bitmap> m_bitmap;
};
}
namespace IPC {
LibGfx: Templatize Point, Size, and Rect
2020-07-26 04:31:47 +00: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 16:24:59 +00: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-02 04:37:35 +00: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 16:24:59 +00: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-23 01:40:33 +00:00
ErrorOr<Gfx::ShareableBitmap> decode(Decoder&);
LibGfx: Templatize Point, Size, and Rect
2020-07-26 04:31:47 +00: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 17:04:05 +00:00
}
Reference in a new issue Copy permalink