How to speed up Graphics Performance about netmf-interpreter HOT 6 OPEN

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

How are you drawing the keys?

from netmf-interpreter.

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.

from netmf-interpreter.

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).

from netmf-interpreter.

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?

from netmf-interpreter.

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?

from netmf-interpreter.

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.

from netmf-interpreter.