While working on multitouch, one of the problems I've run into is the fact that nobody seems to do gesture recognition without some kind of init event, whether it's a mouseclick or contact with a capacitive touchscreen.
Is it possible to do an "always listening" gesture handler? If so, how to do it without mirroring input in realtime and thereby imposing gloomy processor overheads? Is there some kind of downsampling (ie take every nth input from the cursor)?
How about starting to listening at application start?
As for the processor usage, it depends on your particular implementation and the framework you are using.
If talking in general, independently of any framework, I would imagine several techniques to reduce the processor usage:
Have a solution already embedded into the framework. For example MultiTouchScreen would have an Touched or WokeUp event, which will be raised each time the user touches the panel for the first time (or every time, in which case it would be useful to unsubscribe from the event after it's raised, to avoid impacting performance negatively).
Tactile screens consume less power than multitouch. Maybe you can use your multitouch panel as a tactile screen until touched, and then enable the multitouch.
Monitor the touch panel at regular intervals, the interval being longer when idle. This technique is used for example in cordless laser mice. To waste less power, the mouse monitors the desk surface beneath every, say, 0.5 s. if the mouse wasn't moving for the last one minute, then 1 s. if the mouse was idle for five minutes, then 2 s. after ten minutes.
A few points to note:
You can inspire yourself by what is used by some security cameras. No motion: no need to record the scene at several FPS; but when the previous frame appears to be different from the current one, the camera wakes up and records at higher FPS rate.
Some kiosks and ATMs seem to use that. For example in France, ticket kiosks at railway stations (tactile screens, not multitouch) spend usually a few seconds waking up when not touched for a while, but are much more responsive when a person used it just before you do.
The drawback is that the user will have to wait for the application to "wake up". Depending on circumstances, this may either give a feel of a non-responsive app or be really frustrating. For example, at railway stations, it's rather a bad idea to have kiosks that spend a few seconds before responding when a customer may be late for her train.
You must profile the application in order to have an idea of how this will impact the performance and to choose a good user responsiveness/CPU usage ratio. For example for a security camera, slowing to one frame per second has no real negative impact, and allows to waste much less disk space. For wireless laser mice, there is a huge gain in terms of power consumption, but a non-negligible user responsiveness drawback too. Maybe for your particular app, you'll not gain too much power usage, but it will be very frustrating using your application.
Monitor the touch panel at lower resolution. Like it's possible to grab an image from a webcam at different resolutions, there is probably the same possibility for touch surfaces in the framework you use.
You can even imagine some more original solutions. For example, what about an inexpensive motion detector (the little box in public buildings which trigger an alarm or switch the light on when you enter in a room) which will wake up the touch surface every time a customer is near the touch panel?