Yeah, we disable thumbnail caching on low-end devices on purpose.

Image decoding currently uses blink::WebImage::FromData (see https://cs.chromium.org/chromium/src/services/data_decoder/image_decoder_impl.cc?l=38&gs=cpp%253Adata_decoder%253A%253Aclass-ImageDecoderImpl%253A%253ADecodeImage(const%2Bstd%253A%253A__1%253A%253Avector%253Cunsigned%2Bchar%252C%2Bstd%253A%253A__1%253A%253Aallocator%253Cunsigned%2Bchar%253E%2B%253E%2B%2526%252C%2Bdata_decoder%253A%253Amojom%253A%253AImageCodec%252C%2Bbool%252C%2Blong%252C%2Bconst%2Bgfx%253A%253ASize%2B%2526%252C%2Bbase%253A%253AOnceCallback%253Cvoid%2B(const%2BSkBitmap%2B%2526)%253E)%2540chromium%252F..%252F..%252Fservices%252Fdata_decoder%252Fimage_decoder_impl.cc%257Cdef&gsn=DecodeImage&ct=xref_usages) -- can you point me towards how the quality reduction would work there?

I assume we would want to use something like SkConvertPixels to convert the image to 16-bit colors?

Yes, something like that.

Right now previews look nice and crisp on 512MiB devices compared to actual page which is rendered to 16-bit textures. If we render previews in 16-bit mode too, we can save half of the memory they are currently using.

This looks like the place where we prefer 565 textures on 512MiB devices: https://cs.chromium.org/chromium/src/content/browser/renderer_host/compositor_impl_android.cc?l=195

+ericrk@ to confirm.

That looks right. We should definitely be using 16-bit textures for everything.

Assuming you're just dealing with software Skia types here, you should be able to allocate a new bitmap/pixmap in 16 bit kRGB_565_SkColorType format then provide that as the destination for SkBitmap::readPixels (https://cs.chromium.org/chromium/src/third_party/skia/include/core/SkBitmap.h?rcl=0be01ccecba9c330baf4ba3840e57f34f6cdf320&l=959)

How does the snippet preview get eventually rendered to screen? Is it sent in software form to the browser? Passed to CC in the renderer?

It's converted to a Java Bitmap and then put into an ImageView.