Hardware JPEG decoder

[cepetr]

This PR implements a hardware JPEG decoder for T3W1.

• Implemented a new gfx/jpegdec module that wraps the STM32 hardware JPEG decoder.
• Implemented a new trezorhal/jpegdec.rs module that provides the JpegDecoder API for Rust.
• Modified shape::JpegImage to support the hardware jpeg decoder.
• Additionally, two new features have been introduced - hw_jpeg_decoder and ui_jpeg - which replace jpeg and ui_jpeg_decoder.
• Implemented missing blurring for RGBA8888 canvas

JpegImage shape limitations on T3W1:

1. Scaling is not supported. If enabled, the resulting image is simply cropped. A simple (but slow) scaling method can be easily implemented in the future if needed.

The simulator is still using the original JPEG decoder implemented in Rust.
All other models (except T3W1) should not be affected by this PR.

[github-actions]

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3B1 Safe 3	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3T1 Safe 5	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

[prusnak]

Can you post the results of the benchmark? I.e. how much faster is it than SW decoding on the same chip?

Also are there any limitations of the HW decoder when compared to SW encoding?

[cepetr]

Can you post the results of the benchmark? I.e. how much faster is it than SW decoding on the same chip?

Also are there any limitations of the HW decoder when compared to SW encoding?

For 380×520 color images, software decoding takes approximately 600 ms, while hardware decoding takes about 10 ms (both include YCbCr to RGB conversion and display presentation).

According to the STM datasheet, the hardware decoder should comply with the JPEG standard and parse all standard JPEG headers. Unfortunately, it cannot decode progressive JPEGs (though the same applies to the software decoder we currently use).

One current limitation of the hardware decoder, compared to the software decoder we use, is that it cannot scale JPEG images. As a result, we cannot display a small preview of the uploaded image. However, this is not a problem if we slightly change the UI.

[matejcik]

One current limitation of the hardware decoder, compared to the software decoder we use, is that it cannot scale JPEG images. As a result, we cannot display a small preview of the uploaded image. However, this is not a problem if we slightly change the UI.

we should be able to scale the image while streaming it -- unless the jpeg decoder is barfing pixels directly into the framebuffer?

[cepetr]

One current limitation of the hardware decoder, compared to the software decoder we use, is that it cannot scale JPEG images. As a result, we cannot display a small preview of the uploaded image. However, this is not a problem if we slightly change the UI.

we should be able to scale the image while streaming it -- unless the jpeg decoder is barfing pixels directly into the framebuffer?

Yes, it would definitely be possible - and it wouldn’t be too slow if we simply skipped pixels and used (1/2, 1/4, …) scaling as before. However, it would still be much slower than just copying with DMA2D. You also have to consider that the image quality wouldn’t be perfect for some images due to aliasing.