How to speed up Graphics Performance

[rrideAMT]

My NET MF (V4.4) port is to an STM32F429 platform with a 800x480 LCD screen. As more UIElements are added in the application layout the responsiveness of graphical updates slow.
I am trying to implement a qwerty style keyboard on the display. The more Keys that I display, the less responsive the graphics become. So key press feedback is slow.

Previously I ported NET MF (V4.1) to iMXS platform with a 480x272 LCD screen and the same keyboard implementation is much more responsive to graphic changes.

I was hoping better graphics response from the STM32F429 even though the number of screen pixels is 3X the 480x272.

I have already enabled the ChromeArt DMA of the STM32F429 to write the LCD Framebuffer from RAM to the LCD Controller.

I believe the slow issue is probably due to LayoutManager painting the screen or maybe a difference in how the Bitmap images are being processed between NET MF 4.4 and NET MF4.1.

Any ideas on changes I can make to speed up the screen update process?

[miloush]

The more Keys that I display, the less responsive the graphics become. So key press feedback is slow.

How are you drawing the keys?

[rrideAMT]

Each key is an instance of an Image that is created from one Bitmap file from Resources Manager. I created an array of the Key Images that are added to StackPanel containers that orient the keys into a keyboard.
When the key is touched on (TouchDown event), the key Image is redrawn slightly larger and when the TouchUp event fires the key Image is redrawn to the original size. The slightly larger key Image is stored in memory so it is not an actual redraw, but just changing the Image.Bitmap source.

[rrideAMT]

I did a test using Text objects where I added 1 - 80 Text instances in an array to a StackPanel that was contained in a Window. Then I added one key Image where the Visibility property is changed from Hidden to Visible in TouchDown and Visible to Hidden in TouchUp events.

I see the same performance slow down. I think it is just an issue with how many graphic elements makeup a screen. The more Text instances I added the slower the response. Doesn't seem to matter what type of graphical element it is (Image or Text), the performance impact is the same based on the number of instances.

Previous Managed apps that I developed on NET MF 4.1 I would populate the screen with multiple button Image instances and other graphical elements and never noticed a significant slow down. When I load these same apps to my NET MF 4.4 device, there is a noticeable performance difference between the app run on NET MF 4.1 (iMXS) and NET MF 4.4 (STM32F429).

[miloush]

I think it is just an issue with how many graphic elements makeup a screen.

Well that's what I find concerning a bit. Only the area that needs to be redrawn should be redrawn, i.e. it shouldn't depend on the number of elements unless you cause re-layout of everything on each touch event.

I also remember our on-screen keyboard on iMXS running MF 4.3 had horrible performance with GCC but was running great when compiled using RVDS, though I have been told that shouldn't be a problem anymore.

We were rendering the keys in the OnRender method of one UI element that represented the whole keyboard. Maybe you could try some bitmap solution too?

[rrideAMT]

I am compiling NET MF V4.4 with MDK 5.06. I used RVDS with NET MF V4.1.

I am just overriding the OnTouchDown and OnTouchUp event handlers and then finding the key that was touched on and updating the Bitmap property. I tried making calls to Invalidate() method of the key itself and the parent container and window to see if that made a difference. I thought for some reason it was causing a repaint of the entire screen, but no difference.

The screen refresh is fast as I have tested this by using Background images that are the full 800x480. I loaded up 5 full background images and toggled through them with TouchDown. The background will update with an instantaneous appearance.

I have a work around idea for the keyboard. I can make the entire keyboard 1 element and then use 1 element to show the touch location. I am concerned though for my final app that if I want to display a good number of dynamic text and graphical information that I may run into this performance degradation issue. I am hoping that the performance difference between the application screens won't be noticeable to the user.

I believe that it is the same in NET MF 4.1. The keyboard graphical response is slower than other screens with less UIelements.

I believe now with the screen having 3X the pixels and the processor running a little less than 2X the speed, it has become a little more prevalent.

This may just be a limit of the hardware platform design that I have to work around.

I did see that the Framework's LayoutManager class uses a timeout feature that stops the process if it has been active too long to prevent it from consuming all the processor time. Will increasing this timeout benefit my design?

[miloush]

That is what I proposed and what I believe is a good approach. Every element you add needs to participate in the layout process. Even if you end up not redrawing the whole screen, you still need to re-measure and re-arrange everything.

I don't see how "dynamic text and graphical information" would cause less overhead in individual elements, they still need do the same computations, if not more.