As long as you're not writing an insane amount of characters to the screen after every keypress, the program is probably getting slowed somewhere else.
You might want to rewrite your event loop to eliminate unnecessary calls to SysHandleEvent and AppHandleEvent. I was able to speed up framerate by a considerable amount by doing this. Also, you can time different parts of the code using TimGetTicks. Try calling WinDrawChars 100 or so times via a loop and see just how long it takes (on a device, not the simulator). This helps to discover which parts of the code are most in need of optimizing. Just make sure optimizations are off when you're doing this, or the compiler may act funny. And yes, the rather frequent db access is probably slowing it down a bit. -- Tim Kostka http://www.nuprograms.com "Dave Mottorn" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm writing an inventory counting application that uses a custom keypad. > The custom keypad has very large tactile keys that allows auditors to enter > data as fast as they can move their fingers. They fastest guys enter data > faster than you would probably believe. Each time a transaction is entered > the program updates the screen with a history of the last 8 - 10 > transactions and running totals. Most of the screen is being rewritten with > every transaction. I'm using WinDrawChars to do the updates. > > The problem is the fastest auditors can get ahead of the screen updates. As > of a few weeks ago they could get so far ahead they would lose data. Since > then I changed the screen updates so a whole line is being written at a time > instead of portions of a line. I reduced the number of writes to the screen > to about a third of what they were and it made a noticeable difference. > Some of the auditors can still get ahead of the screen updates but they > don't seem to lose data now. > > I don't think I can do much to reduce the number of writes to the screen but > there are a few things I can do to make that part of the program more > efficient. I have the impression that writing to the screen consumes > overwhelmingly more time than my other inefficiencies and I wonder if it's > worth it to bother with them. Each transaction is written to a history file > which is opened and closed for each write. I could leave it open and > eliminate the open and close on each transaction. I'm also using a > push-down stack to keep numeric variables that represent the transactions. > I could use a circular stack and save a complete line of text for every > transaction. Then I wouldn't have to push it down and reformat it for every > transaction. My question is compared to the time it takes to write to the > display are these kinds of improvements going to make any difference? > > We're using Handera 330's at present but we're going to PDA's with faster > CPU's (probably Tungstens) in the murky future. Are we likely to see much > improvement in screen updates? My impression is that display technologies > aren't changing that much. > > Is there any way to increase the size of the keyboard buffer? > > The good news is that the auditors probably have a burst rate that's much > faster than their average rate for entering data. While they're entering > data for a single physical location they go very fast but when they have to > change locations they slow down. > > I'd appreciate hearing about any specific observations any of you have had > on these issues. > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
