CI depends on #4832. Let ignore the CI failure for now.

however I can't tell how complicated will it be to use lv_draw_buf_t on all places, instead of using some simpler functions directly.

I'm planning to update some modules with latest draw buf interface these days. Let's see if more helpers can save us.

I have included bin_decoder as an use case of draw_buf. Please help to review it d57ec2e

Thank you :)

During the process of debugging freetype, I found that the image cache provided by freetype cannot guarantee that the output bitmap meets the width alignment and address alignment requirements. We may need to manage the cache ourselves and use draw buf to uniformly manage the bitmap output by freetype.
The advantage of using the draw buf structure for management is that the image information is created together with the image, and no information will be lost in the context transfer, making it easier to track problems such as misalignment.

@FASTSHIFT
The idea is that the get_bitmap should return an address and stride aligned bitmap. I think it's even better to use our cache for FreeType, because we have more control over it.

@FASTSHIFT The idea is that the get_bitmap should return an address and stride aligned bitmap. I think it's even better to use our cache for FreeType, because we have more control over it.

If get_bitmap returns the draw_buf structure, what do you think is its shortcoming? Is it taking up more memory and introducing construction overhead?

Yes, what we loose is the extra memory and the construction overhead for sure.
What we win is unified stride and address align handling and unified cache usage.

Hi Gabor,
I have updated the draw_buf related APIs, please help to review it.
Thank you.

I'm thinking about the stride parameter in lv_draw_buf_create. I understand that images can have any stride and those stride settings might not be supported by a draw unit, but do we really need to allow manually crafting draw_bufs with any stride value?

What is the advantage of providing full control over stride, instead of setting the stride automatically from the width and color format.

I understand that images can have any stride and those stride settings might not be supported by a draw unit, but do we really need to allow manually crafting draw_bufs with any stride value?

We do need to create draw_bufs with different stride value, see the usage in bin_decoder

https://github.com/lvgl/lvgl/pull/4934/files#diff-fb2fd60d4b02948954b996a1c52438a1c6a51c9a2b61ffd7063f6d9594ad0d7dR949-R950

There's no reason to assume binary file has same stride as GPU needed, it could be already 128 byte aligned which also meets GPU(64Byte assume).

For PNG decoders, e.g. 100x100 image, the draw buffer alloced for directly decoded data is 400Byte. If GPU requires 64byte aligned stride, then a 448Byte stride draw buffer is alloced and lv_draw_buf_copy can process possibly by DMA2D.

For font with bitmap, we may also want to use draw buf. For example PXP(from NXP) doesn't need aligned stride.

So the conclusion is keep stride as open can easy lots of processing without hacking into draw buffer details.

So

• it can happen that draw_bufs (a.k.a images) are not stride aligned.
• the buffers allocated in draw_bufs are always address aligned
• the images stored in flash might not be address aligned

So GPUs need to check for both address and stride before taking a task.

However:

• Let's say we have a draw task for "Hello world". VG-Lite takes it, but when it gets the bitmap of the first letter, it will see that it's not stride aligned because some font engine returns a not stride aligned bitmap. It's already too late, as the draw task is already being executed, but VG-Lite couldn't make a good decide in the evaluate_cb
• Let's say VG-Lite takes a seemingly innocent image draw task, which is actually PNG file. During drawing it will be decoded to a not stride aligned buffer. What to do now? Convert it to stride aligned? Or would it have been a better idea to leave it to PXP? (Maybe this already resolved because in the info_cb the draw_unit can set the stride in the header)

So

• it can happen that draw_bufs (a.k.a images) are not stride aligned.
• the buffers allocated in draw_bufs are always address aligned
• the images stored in flash might not be address aligned

Yes.

So GPUs need to check for both address and stride before taking a task.

No. The decoded image will always fulfill a draw task' requirement like stride alignment. It relies on post_process_cb for now.

No. The decoded image will always fulfill a draw task' requirement like stride alignment. It relies on post_process_cb for now.

I think this the catch. The stride alignment of SW render, VG-Lite, PXP, other? That's I believe having a global stride is cleaner.

The stride alignment of SW render, VG-Lite, PXP, other? That's I believe having a global stride is cleaner.

SW render, VG-Lite, PXP, other have different alignment requirement, so it's not correct having a global stride is cleaner?

Aside from that, the stride parameter is a basic para for draw buf just like w, h. That's why I mentioned the PNG decoder case.

For PNG decoders, e.g. 100x100 image, the draw buffer alloced for directly decoded data is 400Byte. If GPU requires 64byte aligned stride, then a 448Byte stride draw buffer is alloced and lv_draw_buf_copy can process possibly by DMA2D.

• During drawing it will be decoded to a not stride aligned buffer.

I hope the code here can explain it better.

https://github.com/lvgl/lvgl/pull/4968/files#diff-e78cbe701293b586a1376e5917219514c197244669c224744ee13af8f7055e8fR144-R157

For PNG decoders, e.g. 100x100 image, the draw buffer alloced for directly decoded data is 400Byte. If GPU requires 64byte aligned stride, then a 448Byte stride draw buffer is alloced and lv_draw_buf_copy can process possibly by DMA2D.

I understand that the buffers can be copied with on-the-fly stride alignment, but

1. it require an other buffer -> extra memory. If it was a wallpaper then it could mean MBs of RAM
2. it requires time, especially important as usually the buffers are in external RAM

It would be nice to have solution by design, and keep the buffer copy as a fallback for very special situation.

In my head I still have the "no room for failure" policy. If we choose a common stride which works for all it can't be messed up.

There are 2 places where it really matter and not trivial:

1. image decoders: it might be hard to make e.g. libpng return a stride aligned image. However decoder_info_cb can tell in advance what the stride will be so the draw_units can decide if it's ok for them or not. Maybe a draw_unit will accept a not stride aligned image too because it knows that will use a buffer_copy internally. But it shouldn't be the default assumption because of the above mention memory and time reasons.
2. font bitmaps: we can either
   1. return the bitmap as it is and let the draw_unit make the stride alignment
   2. returned stride aligned bitmap

Regarding fonts, now we have ii. implemented, but if we have a simple buf_copy to align stride, i. would be better as we have smaller bitmaps here and some draw units (e.g. SW and PXP) can use the bitmaps without any alignment.

For all other things, like snapshot buffer, canvas buffer, layer buffers, etc, we can use a stride which works for all to not put any limitation on the compatible draw_units.

I merge it now as blocks a lot of other PR and we can improve it later.