ameline
03-03-2003, 01:22 PM
The following is missing/broken;
1: A (simple) way to query a pen/cursor for it's range of pressures.
- Sketchbook hardcodes 0-255 because there is no way we could find to do this. This currently works for all the tabletPCs out there, but it's going to break sooner or later.
2: A (simple) way to query the tablet device sample rate.
- We assume 130/second -- this is good enough for our purposes -- we need to (very efficiently) calculate velocity and accelleration with reasonable accuracy, and we need the sample rate to do this.
3: A (simple and *fast*) way to query if a cursor button is down or not
- without tracking the up/down events -- because these are broken -- see below...
And finally, a fix for the problem where when the pen goes out of range quickly, you don't get a cursor-button-up message, or an out-of-range message -- you get nothing -- zip -- nada.
When the pen comes back into range (some arbitrary time later), you get 3 all at once; an up, then an out-of-range, then an in-range. Quite bogus.
And no -- the hack of having a timer looking for a pause in the event stream *does not work* for our algorithms -- we need to know *right away* when the pen goes up.
The old WINTAB API has none of these shortcomings.
There also seems to be a significant additional latency (of amout 5 ms) in the tablet event stream compared to WINTAB. With Sketchbook, if you start moving fairly fast, the stroke can lag behind the pen position by as much 10 or 15 pixels on a TabletPC. On a regular PC with a 15 inch Wacom cintique, and the same processor/memory as the tabletPC, this lag does not happen.
1: A (simple) way to query a pen/cursor for it's range of pressures.
- Sketchbook hardcodes 0-255 because there is no way we could find to do this. This currently works for all the tabletPCs out there, but it's going to break sooner or later.
2: A (simple) way to query the tablet device sample rate.
- We assume 130/second -- this is good enough for our purposes -- we need to (very efficiently) calculate velocity and accelleration with reasonable accuracy, and we need the sample rate to do this.
3: A (simple and *fast*) way to query if a cursor button is down or not
- without tracking the up/down events -- because these are broken -- see below...
And finally, a fix for the problem where when the pen goes out of range quickly, you don't get a cursor-button-up message, or an out-of-range message -- you get nothing -- zip -- nada.
When the pen comes back into range (some arbitrary time later), you get 3 all at once; an up, then an out-of-range, then an in-range. Quite bogus.
And no -- the hack of having a timer looking for a pause in the event stream *does not work* for our algorithms -- we need to know *right away* when the pen goes up.
The old WINTAB API has none of these shortcomings.
There also seems to be a significant additional latency (of amout 5 ms) in the tablet event stream compared to WINTAB. With Sketchbook, if you start moving fairly fast, the stroke can lag behind the pen position by as much 10 or 15 pixels on a TabletPC. On a regular PC with a 15 inch Wacom cintique, and the same processor/memory as the tabletPC, this lag does not happen.