ladybird/Userland/Services/ImageDecoder/ImageDecoderClient.ipc

#include <LibGfx/ShareableBitmap.h>

endpoint ImageDecoderClient
{
    did_decode_image(i64 image_id, bool is_animated, u32 loop_count, Vector<Optional<NonnullRefPtr<Gfx::Bitmap>>> bitmaps, Vector<u32> durations, Gfx::FloatPoint scale) =|
    did_fail_to_decode_image(i64 image_id, String error_message) =|
}
Everywhere: Use IPC include syntax Remove superfluous includes from IPCCompiler's generated output and add include directives in IPC definitions where appropriate. 2021-07-02 21:40:44 -07:00			`#include <LibGfx/ShareableBitmap.h>`

IPCCompiler: Remove hardcoded endpoint magic, attempt deux This patch removes the IPC endpoint numbers that needed to be specified in the IPC files. Since the string hash is a (hopefully) collision free number that depends on the name of the endpoint, we now use that instead. :^) Additionally, endpoint magic is now treated as a u32, because endpoint numbers were never negative anyway. For cases where the endpoint number does have to be hardcoded (a current case is LookupServer because the endpoint number must be known in LibC), the syntax has been made more explicit to avoid confusing those unfamiliar. To hardcode the endpoint magic, the following syntax is now used: endpoint EndpointName [magic=1234] 2021-04-25 13:19:53 +02:00			`endpoint ImageDecoderClient`
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res) 2020-06-22 21:35:22 +02:00			`{`
ImageDecoder: Pass decoded images as Gfx::Bitmap over IPC Before this change, we were passing them as Gfx::ShareableBitmap. The problem is that shareable bitmaps keep their underlying file descriptor open, so that they can be shared again with someone else. When a Gfx::Bitmap is decoded from an IPC message, the file descriptor is closed and recovered immediately. This fixes an issue where we'd accumulate one file descriptor for every image decoded. This eventually led to descriptor starvation after enough images were loaded and still referenced at the same time. 2024-07-17 19:14:44 +02:00			`did_decode_image(i64 image_id, bool is_animated, u32 loop_count, Vector<Optional<NonnullRefPtr<Gfx::Bitmap>>> bitmaps, Vector<u32> durations, Gfx::FloatPoint scale) =\|`
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder. 2024-04-19 14:23:16 -06:00			`did_fail_to_decode_image(i64 image_id, String error_message) =\|`
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res) 2020-06-22 21:35:22 +02:00			`}`