Errors like this became more likely due to the 'optimized' memory usage.
Also, this prevents the WindowServer from being killed by a goofy program
sharing an incomplete bitmap, and likely some other scenarios.
Indexed bitmaps used to allocate four times the required amount of memory.
Also, we should acknowledge that the underlying data is not always RGBA32,
and instead cast it only when the true type is known.
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)
This adds support for loading the first image from ICO format images only if they are PNG encoded.
This is useful for loading favicons, which are sometimes PNGs with an ICO extension and sometimes actual ICO files.
In particular we can now load the favicon from new.ycombinator.com
Adds an *almost fully featured BMP loader to process .bmp files.
Features:
- All header formats are supported
- Full RLE4/8/24 support
- Color scaling (e.g. distributing a 5-bit color throughout the 8-bit
color spectrum, so 5-bit white is still 0xffffff)
- Full BITMASK/ALPHABITMASK support
*Not included:
- 1D Huffman compression. Good luck actually finding a bmp in the wild
that uses this
- Use of any field in the V4/V5 header. Color spaces? Endpoints? No
thanks :)
This loader was tested with the images at
https://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html. This
loader correctly displays 81 out of the 90 total images (for reference,
firefox displays 64 correctly). Note that not rendering the images at
the bottom is counted as displaying correctly.
If the area or size_in_bytes calculation for a Gfx::Bitmap would
overflow, we now refuse to create such a bitmap and return nullptr.
Thanks to @itamar8910 for finding this! :^)
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.
This feels a lot more consistent and Unixy:
create_shared_buffer() => shbuf_create()
share_buffer_with() => shbuf_allow_pid()
share_buffer_globally() => shbuf_allow_all()
get_shared_buffer() => shbuf_get()
release_shared_buffer() => shbuf_release()
seal_shared_buffer() => shbuf_seal()
get_shared_buffer_size() => shbuf_get_size()
Also, "shared_buffer_id" is shortened to "shbuf_id" all around.
