mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-23 01:32:14 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibGfx/ImmutableBitmap.cpp

106 lines
2.9 KiB
C++
Raw Normal View History

LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
/*
LibWeb: Return ImmutableBitmap from PaintingSurface::create_snapshot() This is a preparation for upcoming changes where ImmutableBitmap will own SkImage allowing Skia to cache GPU textures across repaints.
2024-11-08 20:36:31 -05:00
* Copyright (c) 2023-2024, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibGfx/ImmutableBitmap.h>
LibGfx+LibWeb: Create PaintingSurface snapshot without GPU->RAM readback ...by constructing ImmutableBitmap directly from SkImage. This is a huge optimization for the case when content of canvas is painted onto another canvas, as it allows pixels to remain in GPU memory throughout the process. Fixes performance regression on https://playbiolab.com/ introduced by switching to GPU-backend for canvas.
2024-11-09 00:47:16 -05:00
#include <LibGfx/PaintingSurface.h>
LibGfx: Sync to_skia_color_type
2024-11-10 14:42:27 -05:00
#include <LibGfx/SkiaUtils.h>
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
#include <core/SkBitmap.h>
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 18:55:43 -05:00
#include <core/SkColorSpace.h>
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
#include <core/SkImage.h>
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
namespace Gfx {
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
struct ImmutableBitmapImpl {
sk_sp<SkImage> sk_image;
SkBitmap sk_bitmap;
LibGfx+LibWeb: Create PaintingSurface snapshot without GPU->RAM readback ...by constructing ImmutableBitmap directly from SkImage. This is a huge optimization for the case when content of canvas is painted onto another canvas, as it allows pixels to remain in GPU memory throughout the process. Fixes performance regression on https://playbiolab.com/ introduced by switching to GPU-backend for canvas.
2024-11-09 00:47:16 -05:00
Variant<NonnullRefPtr<Gfx::Bitmap>, NonnullRefPtr<Gfx::PaintingSurface>, Empty> source;
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 18:55:43 -05:00
ColorSpace color_space;
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
};
int ImmutableBitmap::width() const
{
return m_impl->sk_image->width();
}
int ImmutableBitmap::height() const
{
return m_impl->sk_image->height();
}
IntRect ImmutableBitmap::rect() const
{
return { {}, size() };
}
IntSize ImmutableBitmap::size() const
{
return { width(), height() };
}
Gfx::AlphaType ImmutableBitmap::alpha_type() const
{
return m_impl->sk_image->alphaType() == kPremul_SkAlphaType ? Gfx::AlphaType::Premultiplied : Gfx::AlphaType::Unpremultiplied;
}
SkImage const* ImmutableBitmap::sk_image() const
{
return m_impl->sk_image.get();
}
RefPtr<Gfx::Bitmap const> ImmutableBitmap::bitmap() const
{
LibGfx+LibWeb: Create PaintingSurface snapshot without GPU->RAM readback ...by constructing ImmutableBitmap directly from SkImage. This is a huge optimization for the case when content of canvas is painted onto another canvas, as it allows pixels to remain in GPU memory throughout the process. Fixes performance regression on https://playbiolab.com/ introduced by switching to GPU-backend for canvas.
2024-11-09 00:47:16 -05:00
// FIXME: Implement for PaintingSurface
return m_impl->source.get<NonnullRefPtr<Gfx::Bitmap>>();
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
}
Color ImmutableBitmap::get_pixel(int x, int y) const
{
LibGfx+LibWeb: Create PaintingSurface snapshot without GPU->RAM readback ...by constructing ImmutableBitmap directly from SkImage. This is a huge optimization for the case when content of canvas is painted onto another canvas, as it allows pixels to remain in GPU memory throughout the process. Fixes performance regression on https://playbiolab.com/ introduced by switching to GPU-backend for canvas.
2024-11-09 00:47:16 -05:00
// FIXME: Implement for PaintingSurface
return m_impl->source.get<NonnullRefPtr<Gfx::Bitmap>>()->get_pixel(x, y);
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
}
static SkAlphaType to_skia_alpha_type(Gfx::AlphaType alpha_type)
{
switch (alpha_type) {
case AlphaType::Premultiplied:
return kPremul_SkAlphaType;
case AlphaType::Unpremultiplied:
return kUnpremul_SkAlphaType;
default:
VERIFY_NOT_REACHED();
}
}
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 18:55:43 -05:00
NonnullRefPtr<ImmutableBitmap> ImmutableBitmap::create(NonnullRefPtr<Bitmap> bitmap, ColorSpace color_space)
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
{
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
ImmutableBitmapImpl impl;
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 18:55:43 -05:00
auto info = SkImageInfo::Make(bitmap->width(), bitmap->height(), to_skia_color_type(bitmap->format()), to_skia_alpha_type(bitmap->alpha_type()), color_space.color_space<sk_sp<SkColorSpace>>());
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
impl.sk_bitmap.installPixels(info, const_cast<void*>(static_cast<void const*>(bitmap->scanline(0))), bitmap->pitch());
impl.sk_bitmap.setImmutable();
impl.sk_image = impl.sk_bitmap.asImage();
LibGfx+LibWeb: Create PaintingSurface snapshot without GPU->RAM readback ...by constructing ImmutableBitmap directly from SkImage. This is a huge optimization for the case when content of canvas is painted onto another canvas, as it allows pixels to remain in GPU memory throughout the process. Fixes performance regression on https://playbiolab.com/ introduced by switching to GPU-backend for canvas.
2024-11-09 00:47:16 -05:00
impl.source = bitmap;
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 18:55:43 -05:00
impl.color_space = move(color_space);
LibGfx+LibWeb: Create PaintingSurface snapshot without GPU->RAM readback ...by constructing ImmutableBitmap directly from SkImage. This is a huge optimization for the case when content of canvas is painted onto another canvas, as it allows pixels to remain in GPU memory throughout the process. Fixes performance regression on https://playbiolab.com/ introduced by switching to GPU-backend for canvas.
2024-11-09 00:47:16 -05:00
return adopt_ref(*new ImmutableBitmap(make<ImmutableBitmapImpl>(impl)));
}
NonnullRefPtr<ImmutableBitmap> ImmutableBitmap::create_snapshot_from_painting_surface(NonnullRefPtr<PaintingSurface> painting_surface)
{
ImmutableBitmapImpl impl;
impl.sk_image = painting_surface->sk_image_snapshot<sk_sp<SkImage>>();
impl.source = painting_surface;
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
return adopt_ref(*new ImmutableBitmap(make<ImmutableBitmapImpl>(impl)));
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
}
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
ImmutableBitmap::ImmutableBitmap(NonnullOwnPtr<ImmutableBitmapImpl> impl)
: m_impl(move(impl))
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
{
}
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-08 23:48:17 -05:00
ImmutableBitmap::~ImmutableBitmap() = default;
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 08:45:45 -05:00
}
Reference in a new issue Copy permalink