ladybird/Services/ImageDecoder/ImageDecoderServer.ipc

#include <LibCore/AnonymousBuffer.h>

endpoint ImageDecoderServer
{
    init_transport(int peer_pid) => (int peer_pid)
    decode_image(Core::AnonymousBuffer data, Optional<Gfx::IntSize> ideal_size, Optional<ByteString> mime_type) => (i64 image_id)
    cancel_decoding(i64 image_id) =|

    connect_new_clients(size_t count) => (Vector<IPC::File> sockets)
}
Everywhere: Use IPC include syntax Remove superfluous includes from IPCCompiler's generated output and add include directives in IPC definitions where appropriate. 2021-07-03 01:40:44 -03:00			`#include <LibCore/AnonymousBuffer.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 08:19:53 -03:00			`endpoint ImageDecoderServer`
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 16:35:22 -03:00			`{`
LibWebView+ImageDecoder+RequestServer+WebContent: Add init_transport 2025-01-03 13:19:46 -03:00			`init_transport(int peer_pid) => (int peer_pid)`
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 17:23:16 -03:00			`decode_image(Core::AnonymousBuffer data, Optional<Gfx::IntSize> ideal_size, Optional<ByteString> mime_type) => (i64 image_id)`
			`cancel_decoding(i64 image_id) =\|`
Everywhere: Transition ImageDecoder to be single-instance, owned by UI This is the same behavior as RequestServer, with the added benefit that we know how to gracefully reconnect ImageDecoder to all WebContent processes on restart. 2024-06-26 16:44:42 -03:00
			`connect_new_clients(size_t count) => (Vector<IPC::File> sockets)`
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 16:35:22 -03:00			`}`