Issues with class Views::WarpGroup to achieve run-time screen rotation in embedded wizard

Question

For our project, we are using one firmware image for two displays where one display is set for framebuffer in portrait mode (240x320) and other in landscape mode (320x240). We need a way to rotate the screens during run time depending on the mode of display that the UI is running on. Rotation achieved with the screenOrientation (set in Embedded Wizard studio) and EW_SURFACE_ROTATION won’t help us as these are set during compile time. 

Going through Embedded Wizard's knowledge base, looks like class Views::WarpGroup can be used for run time rotation. We tried WarpGroup to see if we can rotate the complete screen but looks like there are complications with that. Rotating a single image/button works fine but to rotate a screen, it seems that it needs enough canvas area to rotate through. Could you please guide us how we can rotate complete screen with WarpView? We are trying to rotate a 320x240 screen by 270 degree to fit in framebuffer of 240x320 resolution.

Answer 1

Hello,

as you already mentioned, the attribute ScreenOrientation is used to generate the entire GUI application for a dedicated display orientation - thus it cannot be changed during runtime.

Views::WarpGroup is a powerful class to make dynamic rotations (and other things like scaling and transformation) of graphical objects - but warping the entire screen (every frame) is not recommended. On most targets, the resulting graphical performance will not be sufficient.

The simplest solution for the described scenario is the combination of two binaries within one flash image and a small boot program that jumps either to the "portrait binary" or to the "landscape binary" - depending on your hardware settings. Of course, you need sufficient Flash memory to do that. From the runtime perspective this is the fastest solution and I know from several customer projects doing that.

If this is not suitable in your case, let me know. Then we have to discuss about drawing the GUI into a separate offscreen buffer and doing a rotation on the fly into the visible framebuffer. But this requires an additional framebuffer and a software rotation which costs a certain runtime.

Let me know your toughts...

Best regards,

Manfred.

Comments

Hello Manfred,

Thanks for the information! Unfortunately, we don't have enough flash memory to store two binaries -Portrait and Landscape. So, we'll have to go with doing a rotation on the fly. To achieve this, we are thinking of using DMA to rotate buffer in memory and for timing DMA transfers with the VSYNC interrupt (target device is RX65 processor). Is there a precedent for this approach? Thanks.

---

Hello,

the alternative solution is the usage of a separate offscreen buffer and doing a rotation on the fly into the visible framebuffer. For that purpose, the GUI has to be designed in the size 320x320 pixel and the offscreen buffer has the size 320x320 pixel. Depending on your current display mode - either 320x240 (landscape) or 240x320 (portrait) area out of the offscreen buffer is used and rotated into the framebuffer. Only the dirty area is copied by CPU.

We have done this already in a customer project with a different MCU. If you are Embedded Wizard customer (Professional Edition) and using the source codes of the Graphics Engine, then we can provide you with the necessary adaptation.

If this is interesting for you, please contact us via support@embedded-wizard.de and let us know your platform details, color format and version you are using. We can provide you an untested template.

Do you have enough memory for the additional offscreen buffer (320x320 pixel)?

Best regards,

Manfred.

---

Hello Manfred,

I have sent an email at support@embedded-wizard.de with the requested details. We'll appreciate if you can share the suggested solution with us.

We have sufficient SDRAM to allocate memory for an additional offscreen 320x320 buffer. In order to understand the steps we need to do from our side to incorporate the suggestion solution, I have couple of questions:

1.You mentioned in the above post that "the GUI has to be designed in the size 320x320 pixel". Currently, we have the ScreenSize attribute of profile set to <320,240> and each of the screen is designed to same size/bounds <320,240>. Do we need to have these both attributes set to <320,320> to fulfill the condition for runtime rotation?

2. We are using frame buffers in double buffering mode. To have rotation on fly, do we need to use single buffering mode with an additional off screen buffer (a total of 2 buffers) or could we continue with double buffers along with one more additional off screen buffer (a total of 3 buffers)?

We'll appreciate your response.

Thanks,

Simran

---

Hi Simran,

do you have a landscape GUI and a portrait GUI that should be shown on the different displays - or do you have one landscape GUI and just the displays are either portrait or landscape orientated?

I thought you are addressing the first scenario - then it would be necessary to have a 320x320 offscreen buffer and to draw either landscape or portrait GUI.

In the second case it will be easier and you can keep your GUI landscape.

Let me know...

Best regards,

Manfred.

---

Manfred,

Its the second scenario, we have one GUI in landscape mode that is used by a display oriented in landscape mode (needs no rotation) and used by a display oriented in portrait mode (needs a 270 degree rotation to show contents correctly on screen).

Thanks for the confirmation. Looks like we don't need to make any changes in EW Studio and can continue to use screen size as 320x240.

Regards,

Simran