Delayed Flush

We all know one of the biggest drains doing graphics on NETMF is calling Flush. Even if you’re only flushing a specific region of the screen, you’re taking a hit. And the more complicated your GUI becomes, the more hits you take.

I’ve got a customer working on a commercial product using Tinkr and their client wasn’t satisfied with the speed of the Virtual Keyboard. There’s a lot of features on that keyboard most people will never use but power users will love. Looking over and over trying to find ways to cut down time, it always came back to flush.

Here’s an interesting stress test for you.

I took a Textbox with all the features turned on and made it 792x59 pixels and performed as many high cost updates (inserting a character in the middle of a string, which kept growing larger after every loop) as I could inside of 1 second. The results (based off emulator):

Flushing only the region used (792x59) every time:
91 updates per second

Flushing the [em]entire screen[/em] 10 times every second using a second thread

The same [em]30[/em] times a second

Two things are obvious. 1 my numbers won’t be this insanely high on a real device and 2 it will still be fantastically faster than it is now.

So delay those flushes people. :wink:

1 Like

Good to know. Thanks for the tip!

Might not apply to a lot of people, but I know certain forum members that make games :wink:

This is even more complicated. Flushing a more horizontal region is faster then a vertical region. There is a loop internally that has to run once for every single line but only if the line is less than the display width.

100x50 will flush twice as fast as 50x100!

I wish there was a 2D DMA on these chips.

1 Like

Real-world results:

Original method: 9.4 FPS averaged over 10 seconds
New Method: 343 FPS averaged over 10 seconds

Run on a Cobra II with CP7

@ Skewworks - That is really good piece of info and the results are impressive.

@ Skewworks - So the optimization was to move it into a separate thread?

Yes and no. The main core requests renders and the tread batches it out to prevent multiple nearly simultaneous request. For example if you press a button that changes text you’d have 3 render requests in less than a 10th of a second. Thread tells it to wait and then performs everything in 1 flush instead of three. The more you try to do in a second the more cycles you save.

Makes sense.

One last real world test, the VirtualKeyboard…the culprit behind these tests. Glide has smacked my VK around for awhile, but not anymore. :smiley:

800x480 VK ran 2.8 keys per second on the old method (remember it allows you to move around carets, supports scrolling and multiple lines etc).

The new version running on 800x480: 111.2 keys per second. If you can out type that, you win.

1 Like

Outstanding!!! :clap:


@ Skewworks - That is an incredible performance gain! Well done… and again thanks for sharing.

@ andre.marschalek - There is already a robot with that name :wink:

Heh that’d be pretty cool. For testing I set up a thread that sent touch messages to the core as fast as it could for 10 seconds and recorded how many character updates went through in that time.

Exciting news!

I’ve just tested a new multi-line enabled text area control. In which I was able to type at full speed on a USB keyboard with Cobra II & CP7…not a single character was lost.

:dance: :dance: :dance:

1 Like

Because you type slow or because the device is fast? :slight_smile:

Just kidding. Good job.

zing !