week in review --<div><br></div><div>Added lo-fi dispatching to ghost event manager. Early testing on Macintosh reveals a very small amount of input being filtered out (not dispatched). A hybrid hi/lo test tells me the filter is doing its job, there's just not much coming through in lo-fi mode.</div>
<div><br></div><div>This week I focused mostly on Windows development. Finally getting nice clean builds from MinGW (gcc 4.4). </div><div><br></div><div>Hi-fidelity tablet input is not as simple on Windows as on Mac OS. I'm making progress: More of the pen data is being captured by blender than before, but it's still not very good. Mouse input falls short in similar situations (redraw lag --> dropped data points). If time permits, I'll try capturing mouse movement through the RawInput API to see if that helps.</div>
<div><br></div><div>Created a Tablet object (Windows only for now) that takes care of the gritty details so GHOST_System doesn't have to. </div><div><br></div><div>next week --</div><div><br></div><div>Introduce native Pen events (different from mouse Cursor events). The way tablet input is passed from ghost to the window manager is hindering improvement, so I'm trying something new. This affects all platforms.</div>
<div><br></div><div>Continue work on Windows-specific tablet madness. I'm already grabbing all available data points after WT_PACKET notification, processing them before the event-driven code can notice. This leaves many subsequent WT_PACKET events with empty data. Scrap that and simply poll for tablet data during System::processEvents.</div>
<div><br></div><div>Get SpaceNavigator working on Windows. The general approach and most details are already worked out on paper, so let's hope it'll be easy!</div><div><br></div><div>progress --</div><div><br></div>
<div>Took an unexpected two days off this week for personal reasons (in addition to Independence Day). Lucky for all of you, this makes for a refreshingly short update! The complexity of the Windows hi-fi solution has also slowed me down, so next week I'll need to push to make up for these delays.<br>
</div><div><br></div><div>The conceptual overlap between lo-fi input and the recent "in-between mouse move" events is something to keep in mind (and resolve before a merge). My approach takes care of the too-much-input problem during event dispatch. Operators continue to deal with a single event type for cursor moves, they just receive more or fewer of these events by preferring a certain fidelity. There's no concept of "real" events vs. "extra" events. Suggestions welcome!</div>
<div><br></div><div>Mike Erwin<br>musician, naturalist, pixel pusher, hacker extraordinaire<br></div>