Pre-rotated display mode

[antonio_pasini]

I see you problem regarding the HW sourcing limitations, but isn’t an STM32H7 strong enough for SW >>rotation?

I’ll try in the next days to experiment with this as a stopgap measure while we go on developing, waiting for official V9 code.

Guess will cut frame rate to 1/3 or even less, with a 800x480 display like ours.

This would mean we cant “swipe” the home screen like we do on a different model with same display in landscape orientation, and this won’t play nicely with mkt dept for device “product placement” reasons.

Some OEM asks for portrait orientation but also speedy interfaces and also low cost , as usual.

I hope reducing the swipe to a central portion will be enough, let’s see.

[nylnx]

@antonio_pasini

Guess will cut frame rate to 1/3 or even less, with a 800x480 display like ours.

This is also our experience with similar/the same hardware. Rotation on STM32 is ~brutal~…
Code generator frameworks (like Qt, Embedded Wizard and Co.) do have a performance advantage just by pre-rotating static assets, but once you need to dynamically rotate or something, it falls apart quickly as well…

@antonio_pasini

Now i’m unsure if going back to 8.3 where rotation is maybe handled somehow

@kisvegabor

FYI, in v9 we will also have SW and GPU accelerated rotation too. I’ve just commented about it here

What I understand is that you certainly don’t need to switch back to 8.3. The rotation is just not handled in LVGL natively anymore, but rather in the display driver. Maybe LVGL will provide basic utility functions or even hardware accelerated examples for common hardware, but it’s just more flexible to do it that way. I originally wanted to PR something for this problem but life and work got in the way But I would need to catch up with the latest developments anyway. Not fully informed on what the current state is.

[antonio_pasini]

@nylnx

What I understand is that you certainly don’t need to switch back to 8.3. The rotation is just not handled in LVGL natively anymore, but rather in the display driver.

In V9 i’m working with two full frame RGB888 buffers in sdram, in LV_DISP_RENDER_MODE_DIRECT mode. The display driver don’t do any pixel copying in this case, just buffer point swapping on v-sync.

Guess I need to switch to LV_DISP_RENDER_MODE_PARTIAL mode, and handle the rotation of regions in the display driver; but I’d need some kind of template of a fb_flush to start from for this case, I’ll look better.

But perhaps doing that right now on V9 is not so smart, since I’d replicate code that will be put internally in LVGL V9 soon anyway, if i understand well.

So i was thinking was more efficient to just go back to 8.3 meanwhile.
I’d have other issues in that case (mainly handling the 128 byte stride LTDC requirement on H7, and having to use 32 bit FB instead of 24 like in V9). Sigh

What would really really needed was a lv_conf.h #define to handle axis swapping during FB address calculation, essentially the “pre-rotated” display mode. In our project doing that at compile time is not such a big issue, and would definitely put potrait mode almost at the same level as landscape.

But I understand this wont’ going to happen (unfortunately, because I think its a common enough issue in industrial markets).

[nylnx]

@antonio_pasini

Guess I need to switch to LV_DISP_RENDER_MODE_PARTIAL mode, and handle the rotation of regions in the display driver; but I’d need some kind of template of a fb_flush to start from for this case, I’ll look better.

You could have four frame buffers (should also be possible with 3 I think… not sure) and have a rotation function inside the fb_flush method. Yes, it’s kinda painful, but that’s just the way it is. Even on an NXP with PXP and rotation support you would have to do it like that or similar.

@antonio_pasini

What would really really needed was a lv_conf.h #define to handle axis swapping during FB address calculation, essentially the “pre-rotated” display mode. In our project doing that at compile time is not such a big issue, and would definitely put potrait mode almost at the same level as landscape.

But I understand this wont’ going to happen (unfortunately, because I think its a common enough issue in industrial markets).

That’s my original proposal. But if you think about it how much work this would be without a code generator you already can guess the likelihood of it happening What you can always do, is have a private set of widgets that render themselves pre-rotated. Also you can rotate images beforehand and save them like that etc. Basically everything a code gen would do for you. I don’t know how fast your deadlines are approaching, but depending on the complexity of your application it should be well within the realm of possibility. The most unsolved issue with this approach is text rendering and there are also some discussions on it if you go onto my profile and check the discussions I was part of

I do know your situation and have sympathy for it. But I also think this is one of the cases where this is not a solved problem already. You have to be creative and invest time and/or money solving it. Be it with contributing to LVGL, buying another framework, massaging your requirements or do even more creative problem solving.

[kisvegabor]

I’ll bring up this topic to at SquareLine, and see what we can do on editor level. It seems we still need to solve the rotated text rendering issue in LVGL.