Touchscreen CPU load on a716

[Dan East]

After some initial testing I'm seeing a big hit on the a716 when the touchscreen is in use. Around a 50% drop in FPS. Can anyone else verify this? Has anyone found a solution to this performance issue that basically all Pocket PCs exhibit? Supposedly Tomb Raider does not slow down when the stylus is in use. This could be the result of it already running at a low FPS, an inaccurate (or purposefully fudged) FPS counter, or they actually identified and found a way to correct the problem.

Here are existing threads on the issue:
http://www.pocketmatrix.com/forums/view ... hp?t=10065
http://www.pocketmatrix.com/forums/view ... hp?t=13790
http://www.pocketmatrix.com/forums/view ... hp?t=13497

Dan East

[rcp]

I used to see a pretty big hit on my Dell Axim, but not anything like 50%... more like 20%. I did, however, notice a change when I reworked my 'main loop'. I no longer use PeekMessage, rather I use GetMessage. I use SetTimer to make sure I get enough messages to maintain 40fps... the rest of the time the OS can back off and reduce power usage. This greatly increased battery life. In addition, I noticed that it decreased the hit that the stylus imparts... it is now no more than 10%. I don't know if this is because the game is limited to 40fps, or if using GetMessage allows other parts of the OS to have more time to do whatever and service the touchscreen in a more effcient manner.

I would do more serious testing, however, I need to get our pool game released before some of the email threats are made good upon. :)

Cheers,
rcp

[Dan East]

I'm seeing this regardless of FPS. If the FPS is 60 then it will drop to 30. If it is 15 it will drop to 8.

I am using PeekMessage, followed by TranslateMessage and DispatchMessage if there was a queued message. I'll try GetMessage tomorrow and see if that helps.

Dan East

[rcp]

OK, I hope what I said was clear... my reason for using GetMessage over PeekMessage was to reduce power usage. This was based on the following tidbits I found in MSVCe Help...

If you port an application to a Windows CE-based platform that operates on batteries you need to consider the limited power resources on the Windows CE-based device. Avoid cycling the CPU unnecessarily by calling energy-consuming functions such as PeekMessage.

and...

Use PeekMessage carefully, because it does not block the waiting for a message event, which enables an application to continue running regardless of messages in the queue. In a Windows CE–based application, if an application does not block the waiting for a message or some other event, the kernel cannot shift the CPU into low-power mode, which can drain the device batteries quickly.

The last of these I really didn't believe, as I couldn't imagine how the kernel could possibly put the CPU into low-power mode whilst I am trying to get the damn CPU to render 3d graphics. Apparently, I was wrong, because this 'fix' improved power usage by 3x or more.

I've written and worked on embedded OSes in the past, and I know how certain 'code paths' are structured that are considered 'always gonna happen' and what happens when they don't!! My guess is that GetMessage does some 'other things' that really need to be done that PeekMessage should have done. Thus it may well be a design or implementation bug.

Anyway, using GetMessage got our power usage down to very reasonable levels and seemed to address FPS issues as well. I thought it would make the game jerky or slower, but in fact it made it smoother and at least appears to be faster.

Let me know what you find!!

Cheers,

rcp

[j.edwards]

rcp: I just changed my app class to work with GetMessage as you described. However, just wondering - what happens if it takes longer than the interval between each WM_TIMER msg to process the frame? Do the messages queue up?

[Johan]

FYI: I was previously using PeekMessage (..., PM_NOREMOVE) + GetMessage in GapiDraw but experienced issues on some PocketPC 2000 devices when minimizing / restoring the application. Not all messages were caught. After switching to PeekMessage (..., PM_REMOVE) and translate/dispatch the problem was solved.

So please take caution when using GetMessage if you want your app to run reliably on all older Pocket PCs...

[joshbu [MSFT]]

I took a look in the message queing code. Each message que in CE has a an event associated with it that gets signaled when a new message has been entered into the que. GetMessage's primary difference from PeekMessage is that it calls WaitForSingleObject on that event.

All of the low power magic is happening in the WaitForSingleObject routine.

So, you should be able to reap low power goodness with either loop, so long as when you use PeekMessage, you still give some cycles back to the OS in some way: a Wait* or a Sleep.

Now, I'm afraid that I can't answer why the touch driver performance would improve in that case. Perhaps it is multithreaded and giving up a few cycles allows the touch worker threads to do work in a more timely fasion? <shrugs>

[Dan East]

I don't see how that would help battery life either, except that your game is not requiring 100% CPU and you are not Sleeping away the uneeded cycles.

Dan East

[joshbu [MSFT]]

addendum:

I ran into on the BSP guys in the hall, and here's his take:

What's likely happening is that the touch sample rate is too high, and the touch driver is flooding gwes with touch events. Now, if you access the message que "slower" (like via a GetMessage, where there's thread scheduling going on,) that gives gwes the opportunity to "merge" the touch event with prior events still sitting in the que.

[Dan East]

Okay, I've tried several incarnations without any change in FPS:

PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);
PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE);
GetMessage(&msg, NULL, 0, 0);
GetMessage(&msg, hWnd, 0, 0);

Again, FPS is halved when the stylus is down, regardless of how high or low the FPS is when the stylus is not down.

RCP, I re-read your post. I see what they are saying. That suggestion is purely for standard gui / event driven applications like DEXplor, or games like Solitaire, etc. Those apps basically don't do anything until the system sends it messages, so while they are waiting they should be Sleeping or letting the message retrieval call block via GetMessage.

Dan East

[rcp]

Dan:
Sorry, I was hoping to make that clear. In our game (Virtual Pool) nothing happens until the player does something. When they aim, the 3D scene updates, stroke the cue, the cue draws, hit a ball, the balls move. Thus a large part of the time the game doesn't really do anything. However, you can't just wait on the user because during animation the user isn't doing anything.. thus the need for WM_TIMER. When I used PeekMessage (obviously) the game ran full blast even when not required. It didn't draw anything or do anything useful, but the CPU load was 100%... just a lot of nothing, which unfortunately draws power. I didn't want to use Sleep, so I left it up to GetMessage to do the work. I also checked the CE source and saw the WaitForSingleObject and knew that would effectively let the CPU sleep and wake up more like an ISR driven system. All that said, I would use the same approach in any game. Low power operation is law on mobile devices and given the CE architecture, it appears GetMessage is the best way of allowing CE to manage its power usage.

Unfortunately, this doesn't seem to help the touchscreen hit on your device. This pretty much sounds like a configuration problem or bug in the touchscreen driver. Possibly just a really crappy touchscreen. The decrease I saw is probably just related to my game being much more thread friendly than when I used PeekMessage.

J. Edwards:
Good question. I've seen my app run over the 40fps limit at times, so I am assuming that WM_TIMER messages were queued when it was running slower than 40fps and the frame rate increase is the queued messages comming out. I probably should verify this.

Johan:
I tried PeekMessage followed by GetMessage if there was something there and I too missed messages. This seemed like a logical thing to do, but it really, really didn't work well. When I switched to just GetMessage, everything seemed to work just fine.

In general:
Use PeekMessage if you are going to handle idle time yourself by a Wait* or Sleep. Use GetMessage if you would like the OS to do it for you. In that case, setup a timer to make sure you get enough control to render at the desired frame rate. Personally, I had lots of problems with Sleep and thus I chose to use GetMessage and let WinCE work it out.

Cheers,

rcp

[Tala]

I tried PeekMessage followed by GetMessage if there was something there and I too missed messages. This seemed like a logical thing to do, but it really, really didn't work well. When I switched to just GetMessage, everything seemed to work just fine.

Is there a way to clear the whole message queue? It seems to me, that if the code is taking longer than the timeframe in between consecutive WM_TIMER events, it is necessary to flush the message cueue.

In any case, GetMessage saves power only if WaitForSingleObject blocks the thread, that is when the "queue-not-empty" event is not yet signaled when GetMessage is called.

[j.edwards]

rcp: have you done any tests to see if the WM_TIMER msgs queue up?

joshbu: you mentioned events being "merged" - does this apply to WM_TIMER messages also?

[joshbu [MSFT]]

No WM_TIMER messages aren't merged. It's a mouse move thing. It's the effect you get when you pull a stylus or mouse across a paint program really fast on a slow machine and instead of getting the exact path you traced, you get line segments. The paint program can't service the mouse move events as fast as they are being generated, hence they are merged. I was really grasping at straws to explain the behavoir rcp had originally reported.

I think rcp is right: the touch panel sample rate is cranked way up (maybe for handwriting recognition?) or the driver is inefficent or both. I don't know how to mitigate that.

[Digby]

Dumb question, have any of you actually loaded Tomb Raider on one of these devices such as the a716 and verified that Tomb Raider doesn't suffer from this performance hit?

I know that TR costs $30 and you can't install it on multiple devices, but $30 isn't much to spend when you're talking about doing a lot of investigative work that may not even be necessary.