Slide handler slows down

Question

Hi There,

I'm using the slide handler to allow me to slide between pages, and I find that the more pages I have, the more choppy the animation is. The choppiness I'm sure is due to the processing that is required. It's as if items on page 6 are being processed even when I am scrolling between page 1 and page 2. Naturally, this is not very scalable.

a) Is my thinking correct in the regard that non-visible EW items are being processed even if they are far away from being onscreen?

b) Is there a workaround for this?

Kind Regards,

Rob

Answer 1

Hello Rob,

the items occupy memory and (depending on their implementation) may perform operations. For example, an animation implemented in an item will continue running even if you move the item outside of the visible area or you overlay it by other opaque contents. Thus the invisible items may impact the performance.

The invisible items are also taken in account during screen update. In this case, however, the impact is not large. The update algorithm sees that the item lies outside of the visible area and ignores it. However, if you have set Buffered mode for the item and the content of this item changes, the internally used buffer is updated (redrawn) even if the item itself is actually not visible. Are you using the Buffered mode?

To scroll the pages, are you using the Outline Box? Or have you implemented your own code to re-arrange the items? As optimization, you could free the respective item after it has been moved outside the visible area. Later, when the item enters the visible area, create and make visible a new instance of the item.

Use new operator to create instances dynamically and the methods Add() and Remove() to add/remove a item to the view tree. With this technique you can maintain only few items which are actually visible. All other items can be released (also their memory can be released). This works of course, if the items do not store important states. You will need to store the states outside of the items.

Best regards

Paul Banach

Comments

Hi Paul, my apologies for not replying sooner. I have conducted some test. We are using the outline tool with the slide handler as you suggested, and are using double-buffering to avoid flicker. In that mode embedded wizard alternates between 2 video buffer addreses, and we switch our LTDC to the addres that EW is *not* writing to. I find that the effective screen rate is 20 frames per second, until I start to slide. For a normal page with about 6 images displayed, the effective update rate drops to 8 Hz, which is still acceptable, but we have a timer page with 60 small bitmap images, which are rotates to indicate seconds. When sliding around this page, the frame rate drops to about 3 updates per second, which is unacceptable.Is there any wat to suspend drawing whilse the slide is ongoing? De-allocating object that are not on the screen seems like something that EW should be doing for us...

Kind Regards,

Rob

---

Hello Rob,

it is not simple to give the right advice without knowing your target system and your project. Can you provide more details to your target system?

I also wonder about the measured 20 FPS. Does it mean, if there are no screen changes (updates), the application is already limited to 20 FPS?

Also important: do you use in your project Warp Image or Warp Group views? This could be the case if you scale or rotate some images. Such operation, if not suported natively by the HW, is CPU intensive and as such slow.

Best regards

Paul Banach

---

Hi Paul, thanks for the prompt response.

We're using the STM32F469 device, and EW 8.30. We do use the warp image for the second spokes, and perhaps we can look at small bitmaps circles to schieve a similar purpose, whith will not be as CPU intensive.

Perhaps you can suggest a better approach: Our screen refresh rate is 20 frames per second, and we are using the double buffer feature to avoid flicker and display of the EW screen whilst EW is updating it. We execute EW intensively until it tells us that it will we writing to a new videoo buffer address. When that happens, we suspedn EW execution until our video system completes the page so that EW does not write to the buffer whilst it is being displayed, because this can result is unwanted 'animation'.

 

Kind Regards,

Rob

---

Hello Rob,

the Warp Image view is generally not bad. Used with small images it works well even if there is no support from HW for the necessary texture mapping operations. However, the larger the image the bigger the CPU load. So, I would recommend to remove/hide the Warp Images temporarily and test the resulting performance. Maybe you can modify your design and omit the Warp operations?

Regarding the 20 FPS, I'm still not sure, whether I understand this limitation. Does the 20 FPS result from your particular HW or synchronisation with video buffers? In other words, even if there is no screen redraws, your HW can perform max. 20 FPS? As far as I know STM32F469, it should not be a problem to achieve higher FPS.

Assuming there is really a limitation to 20 FPS, this produces 50 ms delay for each screen update. Even if your GUI needs only 20 ms to redraw its contents, the entire screen update would take 50 + 20 = 70 ms. This means 14 FPS.

Best regards

Paul Banach

---

Hi Paul,

It is a hardware limitation of the device. ST has an app note which prescribes the LTDC pixel clock calculated from a number of variables including use of DMA2D, use of LTDC, SD-RAM, Screen size and bytes per pixel. Our screen update rate is 20.27 frames persecond. Because we are using double buffering, one Embedded Wizard calls into out native code EwBspSetFramebufferAddress to prescribe a new video address, we *have* to wait until the LTDC peripheral has finished reading the other buffer, or else we will see imagery we do not wish to see. I think that EW in later versions introduced a thrid buffer, which decouples the embedded wizard app from the video streaming to the screen, but we are using v8.3 still.

I changed the WarpImage to an image, and the screen update rate (during the swipe) changed from 3 frames per second to about 8 frames per second, which is an improvement.

I must say that as a test, I ignored the double buffering to bump up the attention that EW gets, and even though EW is updating the screen at 60 Hz, the swipe apears to have a low update frequency - ie it does not look smooth.

Either:

* I have too many items in my outline object (I don't think I have much)

* The swipe algorithm is unrefined

* Swipe settings required tweaking for smoother animation?

* Our screen size is 1280 x 720. Perhaps the largish size is hard for EW to manage?

Kind Regards,

Rob

---

Hi Paul,

I took in what you said about the screen update. Our display can at best do 50ms between updates, because of the pixel clock, and with some overhead copying graphic data, it will increase.

Our swip duration is 800ms, so I understand that 800/70 = 11 screen updates are required. Ouw screen width is 1280 pixels, so if the swipe is linear, then each screen shift will be about 116 pixels, which obviosuly does not lend itself to a smooth effect.

Thanks for all your feedback, I think this isa hardware limitation we must accept,

Kind Regards,

Rov