chromium/skia/public/mojom/bitmap.mojom

// Copyright 2015 The Chromium Authors
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

// This file contains structures used to represent SkBitmaps in Mojo.
module skia.mojom;

import "mojo/public/mojom/base/big_buffer.mojom";
import "skia/public/mojom/image_info.mojom";

// The most common way to transfer an SkBitmap over IPC. This struct enforces
// that the bitmap is 32bpp to prevent buffer-overflow problems when reading/
// writing the pixel buffer.
struct BitmapN32 {
  BitmapN32ImageInfo image_info;
  mojo_base.mojom.BigBuffer pixel_data;
};

// Marked stable as this is used in the crosapi. This struct should be
// avoided whenever possible. If used, extreme care must be taken when
// manipulating the pixels in the bitmap, either only using SkBitmap methods to
// read and write to them, or taking care to not assume that there are 32 bits-
// per-pixel.
[Stable, RenamedFrom="skia.mojom.Bitmap"]
struct BitmapWithArbitraryBpp {
  ImageInfo image_info;
  uint64 UNUSED_row_bytes;
  mojo_base.mojom.BigBuffer pixel_data;
};

// Similar to above, but the generated bindings avoid copying pixel data on the
// receiving side of an IPC message. That can be a valuable optimization for
// large bitmaps. However, this is DANGEROUS as it leaves open the possibility
// for the sender to continue to modify the pixel data, which could lead to
// TOCTOU issues. Use this type *only* when the sender is fully trusted (and
// a compromise there would already mean system compromise), such as from the
// browser process.
//
// NOTE: It is important that the fields of this struct exactly match the
// fields of the Bitmap struct. This enables stable interfaces to freely
// migrate between these two types in a compatible fashion.
[Stable, RenamedFrom="skia.mojom.UnsafeBitmap"]
struct BitmapMappedFromTrustedProcess {
  ImageInfo image_info;
  uint64 UNUSED_row_bytes;
  mojo_base.mojom.BigBuffer pixel_data;
};

// Encode an N32 SkBitmap for transport without relying on shared memory.
// Normally, it is preferable to use shared memory and this mojom type should
// NOT be used for IPC.
//
// This type is useful, however, for de/serialization to a string (via
// skia::mojom::InlineBitmap::Serialize() and Deserialize()) since it will not
// attempt to use a shared memory handle and will encode the actual pixel
// content always.
struct InlineBitmap {
  BitmapN32ImageInfo image_info;
  array<uint8> pixel_data;
};