dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Services/ImageDecoder/ImageDecoderServer.ipc

15 lines
536 B
Text
Raw Permalink Normal View History

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>
LibIPC+LibWeb+LibWebView+Services: Add IPC::TransportHandle Add IPC::TransportHandle as an abstraction for passing IPC transports through .ipc messages. This replaces IPC::File at all sites where a transport (not a generic file) is being transferred between processes. TransportHandle provides from_transport(), clone_from_transport(), and create_transport() methods that encapsulate the fd-to-socket-to-transport conversion in one place. This is preparatory work for Mach port support on macOS -- when that lands, only TransportHandle's internals need to change while all .ipc definitions and call sites remain untouched.
2026-03-11 16:10:08 -03:00
#include <LibIPC/TransportHandle.h>
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
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)
LibImageDecoderClient: Remove sync id fetch from async decode request
2026-02-21 17:48:14 -03:00
decode_image(Core::AnonymousBuffer data, Optional<Gfx::IntSize> ideal_size, Optional<ByteString> mime_type, i64 request_id) =|
cancel_decoding(i64 request_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
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
request_animation_frames(i64 session_id, u32 start_frame_index, u32 count) =|
stop_animation_decode(i64 session_id) =|
LibIPC+LibWeb+LibWebView+Services: Add IPC::TransportHandle Add IPC::TransportHandle as an abstraction for passing IPC transports through .ipc messages. This replaces IPC::File at all sites where a transport (not a generic file) is being transferred between processes. TransportHandle provides from_transport(), clone_from_transport(), and create_transport() methods that encapsulate the fd-to-socket-to-transport conversion in one place. This is preparatory work for Mach port support on macOS -- when that lands, only TransportHandle's internals need to change while all .ipc definitions and call sites remain untouched.
2026-03-11 16:10:08 -03:00
connect_new_clients(size_t count) => (Vector<IPC::TransportHandle> handles)
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
}
Reference in a new issue Copy permalink