Framebuffer rotation - Some advice needed. (VGLite, PXP, LCDIFV2)

[AndyCapon]

Hi Guys,

Here is some background:

I'm looking at porting some LVGL code to an mimxrt1170-evk.

The supplied mipi display is a portrait display.

LVGL renders only in landscape using a combination of direct memory access and PXP.

The resolution is 1280x720 16 bits.

Worst case scenario for a frame is every pixel changing due to scrolling.

So I'm hoping to use this portrait display rather than getting another landscape display to replace it.

I need at the worst case to rotate the full 1280x720 LVGL buffer to a 720x1280 frame buffer for the display.

Using PXP I can do this in 15.7ms, not great but we can live with that. The main problem here though is the LVGL is also using PXP and we block that, so a full 15.7ms is used.

So I thought I would look at VGLite thinking that it and PXP can run in parallel and I will just sync things up, the issue here is that VGLite bitmap rotation is horrendously slow at 52ms.

I was hoping LCDIFV2 could actually do the rotation for me but I can't seem to find any info on that.

So I guess my questions are:

1. IS VGLite really this slow or am I maybe doing something wrong?

2. Can this rotation be done by LCDIFV2?

Thanks for any advice

Andy

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1. IS VGLite really this slow or am I maybe doing something wrong?
-- I was wondering if you can share the code to rotate the figure via the VGlite.
2. Can this rotation be done by LCDIFV2?
-- No, I'm afraid not.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[AndyCapon]

Hi Jeremy,

Thanks for the interest, here is the code:

    vg_lite_matrix_t mat;
    vg_lite_identity(&mat);
    vg_lite_rotate(90, &mat);
    vg_lite_translate(0, -720, &mat);
    vg_lite_blit(rt, &imageBuffer, &mat, VG_LITE_BLEND_NONE, 0, VG_LITE_FILTER_POINT);

I have included the exported project as well, this will load into MCUXpresso as evkmimxrt1170_clock_freetos_cm7 as that is the example I modified.

Thanks

Andy

[carstengroen]

Andy,

not sure it helps you, but I just noticed that the next version of lvgl has some rotation features:

If it is usable or not I don't know.

PS: I download the newest lvgl and patched the version from NXP in the SDK for RT1064 as the version in the SDK is many versions "behind" the official lvgl (same goes for a lot of the other middleware components).

[AndyCapon]

Hi Carsten,

Thanks for the interest and reply.

I have looked at the newer lvgl stuff, the actual main rendering code is still stuck in rendering left to right then it does the rotation in software. It also only works with single buffer mode.

So the cost of rotation is unfortunately still there, seems to be at about the same speed cost as using VGLite which makes me wonder why VGLite is so slow at rotation, about 5 times slower than a transform blit without rotation.

Cheers

Andy

[carstengroen]

No worries Andy,

I knew it was probably a long shot, but you never know

I'm following this with interest too, I have 2 1170 EVKs here with display, and the first 3 (different) PCB's of my own design for the 1176 (just waiting for the chips).

Hope there will be some input on this from NXP

[AndyCapon]

Hi Carsten,

To be honest I'm now thinking with this board even with a landscape 1280x720 display, scrolling the whole display is not going to be great. I guess the amount of sdram used and the slow speed of the sdram are playing a part.

As a test I removed the code rotating onto the framebuffer to just see how lvl was running when scrolling, first using the lvl metrics which has the M7 pegged out at 100% and then double checking with some code using the DWT cyclecount to measure time spent in total and in lvgl every 5 seconds or so:

8 FPS 100% CPU
11 FPS 100% CPU
12 FPS 100% CPU
13 FPS 100% CPU
14 FPS 100% CPU
13 FPS 100% CPU
12 FPS 100% CPU
13 FPS 100% CPU
13 FPS 100% CPU
13 FPS 100% CPU
14 FPS 100% CPU
13 FPS 100% CPU
12 FPS 100% CPU
11 FPS 100% CPU
Total = 5076 ms, lvgl = 4938 ms