ladybird/Userland/Services/ImageDecoder/ImageDecoderServer.ipc

#include <LibCore/AnonymousBuffer.h>
#include <LibGfx/ShareableBitmap.h>

endpoint ImageDecoderServer
{
    decode_image(Core::AnonymousBuffer data) => (bool is_animated, u32 loop_count, Vector<Gfx::ShareableBitmap> bitmaps, Vector<u32> durations)
    decode_image_with_known_path(DeprecatedString path, Core::AnonymousBuffer data) => (bool is_animated, u32 loop_count, Vector<Gfx::ShareableBitmap> bitmaps, Vector<u32> durations)
}
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 <LibCore/AnonymousBuffer.h>`
			`#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 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 21:35:22 +02:00			`{`
Userland: Use snake case names in .ipc files This updates all .ipc files to have snake case names for IPC methods. 2021-05-03 15:52:56 +02:00			`decode_image(Core::AnonymousBuffer data) => (bool is_animated, u32 loop_count, Vector<Gfx::ShareableBitmap> bitmaps, Vector<u32> durations)`
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method. 2023-01-15 21:50:32 +02:00			`decode_image_with_known_path(DeprecatedString path, Core::AnonymousBuffer data) => (bool is_animated, u32 loop_count, Vector<Gfx::ShareableBitmap> bitmaps, Vector<u32> durations)`
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			`}`