[Soc-2010-dev] status report (fancy input devices)

[Mike Erwin]

week in review --

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.

This week I focused mostly on Windows development. Finally getting nice
clean builds from MinGW (gcc 4.4).

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.

Created a Tablet object (Windows only for now) that takes care of the gritty
details so GHOST_System doesn't have to.

next week --

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.

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.

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!

progress --

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.

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!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2010-dev/attachments/20100710/e414ab51/attachment.htm