[Bf-blender-cvs] SVN commit: /data/svn/bf-blender [30377] branches/soc-2010-merwin/notes: More ramblings from a certain mad scientist.

Thu Jul 15 14:45:11 CEST 2010

Revision: 30377
          http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=30377
Author:   merwin
Date:     2010-07-15 14:45:11 +0200 (Thu, 15 Jul 2010)

Log Message:
-----------
More ramblings from a certain mad scientist.

Added Paths:
-----------
    branches/soc-2010-merwin/notes/week 7 notes.txt
    branches/soc-2010-merwin/notes/week 8 notes.txt

Added: branches/soc-2010-merwin/notes/week 7 notes.txt
===================================================================

--- branches/soc-2010-merwin/notes/week 7 notes.txt	                        (rev 0)
+++ branches/soc-2010-merwin/notes/week 7 notes.txt	2010-07-15 12:45:11 UTC (rev 30377)
@@ -0,0 +1,41 @@
+9 July --
+
+Window receives WT_CTXOPEN after WTOpen, and WT_CTXCLOSE after WTClose. It will either get WT_PACKET events, or not if we want to poll instead using WTPacketsGet. It will also receive context and info change messages.
+
+I'm getting more tablet points on Windows now. Using WTPacketsGet instead of WTPacket (which was discarding all but one point per WT_PACKET notification). Now I'm getting anywhere from 0 to 71 packets inside processWin32TabletEvent. Lots of zero-packet events, I'm guessing from delayed window messages (when I've already processed their input). It's still not as good as the Mac version, not... hi-fi enough. Neither is the mouse, actually.
+
+For Windows, I'd like to take the polling route. Blender does input in batches anyway, so why not get the best performance (and cut down on false positives)?
+
+I think it's sending WM_MOUSEMOVE also, from the lack of cursor event spawning in the tablet handling code. Maybe disabling WT_PACKET window events also disables WM_MOUSEMOVE. I hope so!
+
+later --
+
+Here's the packet info I want (* most important):
+PK_TIME (either t or dt, depending on mode)
+PK_CHANGED (instead of comparison to prev packet)
+PK_CURSOR
+PK_BUTTONS
+PK_X, PK_Y * (these are scaled DWORD coordinates. Scale ourselves to get fractional?)
+PK_NORMAL_PRESSURE *
+PK_ORIENTATION
+
+Info(WTI_INTERFACE, IFC_IMPLVERSION) if it's less than 1.4, suggest a driver update! Info(WTI_DEVICES, DVC_NAME). Also DVC_X, DVC_Y, DVC_NPRESSURE, DVC_ORIENTATION.
+
+Interesting LOGCONTEXT fields:
+Name (up to 40 characters)
+Options (remove CXO_MESSAGES from default (CXO_CSRMESSAGES too?))
+PktData
+
+orAzimuth - Specifies the clockwise rotation of the cursor about the z axis through a full circular range.
+
+orAltitude - Specifies the angle with the x-y plane through a signed, semicircular range. Positive values specify an angle upward toward the positive z axis; negative values specify an angle downward toward the negative z axis.
+
+Use Tilt instead of Orientation.
+
+much later --
+
+Just noticed something interesting: tablet events are sent as WT_PACKET and WM_MOUSEMOVE at first. Soon it starts to send only WM_MOUSEMOVE! I guess if you don't ask for pressure or anything special, it assumes your app isn't tablet aware!
+
+Nope. When I ask that WT_PACKET is not to be sent, I still get WM_MOUSEMOVE from the pen. Damn!
+
+New hope: GetMouseMovePointsEx (retrieve up to 64 mouse/pen events). Also saw another suggestion to use RawInput. This would send WM_INPUT events, not WM_MOUSEMOVE. I can stop handling MOUSEMOVE entirely, using INPUT for mouse and bulk polling for pen. Yay!
\ No newline at end of file

Added: branches/soc-2010-merwin/notes/week 8 notes.txt
===================================================================
--- branches/soc-2010-merwin/notes/week 8 notes.txt	                        (rev 0)
+++ branches/soc-2010-merwin/notes/week 8 notes.txt	2010-07-15 12:45:11 UTC (rev 30377)
@@ -0,0 +1,55 @@
+10 July --
+
+Today I learned how to specify which Windows version is targeted by code. Changed GHOST_SystemWin32 to require XP or newer. This gives us some more #defines, like WM_INPUT and extra mouse buttons. Plenty of other stuff I'm sure, but the need for input is what led me to this info. I was able to remove a whole block of #defines in the blender code.
+
+After WIN32_LEAN_AND_MEAN, you can manually include rare (but necessary) headers. This class needs OLE for drag-and-drop, so now I include <ole2.h> just for that.
+
+RawInput is working now for the regular mouse! No WM_MOUSEMOVEs sent, only WM_INPUT, as desired. Now I need to interpret those events and generate ghost cursor events from them.
+
+The current s_wndProc function assumes that only one event is generated. Probably not true for buffered RawInput. I'm doing unbuffered right now for the mouse, but plan to switch.
+
+I'd like to get the timestamp once in s_wndProc, not in every event handler function. Raw mouse events don't have a timestamp, but I think tablet events do.
+
+MSDN says that GetRawInputData handles a single input event, so I must assume that the others remain queued. When Wintab handles a single event, it discards all older events from its queue. Trying the buffered input now... Still trying...
+
+14 July --
+
+Uh-oh... Wacom mouse also supplies WM_INPUT events... in different coordinates! There's probably a way to exclude this. Pen too? Yep. Very large coordinates.
+
+from About Mouse Input (Windows) on MSDN:
+"The mouse is an important, but optional, user-input device for applications."
+"When mouse messages are posted faster than a thread can process them, the system discards all but the most recent mouse message."
+
+SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, pulScrollLines, 0)
+
+SPI_GETMOUSE "Retrieves the two mouse threshold values and the mouse acceleration. The pvParam parameter must point to an array of three integers that receives these values. See mouse_event for further information."
+
+SPI_GETMOUSESPEED "Retrieves the current mouse speed. The mouse speed determines how far the pointer will move based on the distance the mouse moves. The pvParam parameter must point to an integer that receives a value which ranges between 1 (slowest) and 20 (fastest). A value of 10 is the default."
+
+GetMouseMovePointsEx retrieves up to 64 previous data points. Pass in a single point and it gives more. After the passed-in point? Before?
+
+What about making my own mouse events from RawInput using SendInput()? It should apply ballistics.
+
+The example code for GetMouseMovePointsEx is wrong. As in, missing arguments and wrong types. Microsoft apparently never compiled it to check... I think I remember something similar when adapting their RawInput example. Ok, it's compiling now. Maybe they do that to weed out noobs. As in "if you can't figure this out, you shouldn't be programming!" So is it hostility or incompetence? Moving on.
+
+GetMouseMovePointsEx is returning 64 points no matter what. Weird. I'm passing in the most recent point provided by WM_MOUSEMOVE. Use previous event instead? It seems to send the past 64 events up to the one you send in, whether or not they've been sent. Search backward from the end to find our previous mouse position. Everything after that is new!
+
+Could combine RawInput with SendInput to provide uncoalesced mouse input...
+
+This is it! I'm watching the point buffer length as I mouse around, and hi-res sculpting shows severe dropped points. I'll try without RawInput (for mouse), then again later with it.
+
+MOUSEINPUT m = {
+	dx, dy,
+	nevermind! };
+
+MOUSEEVENTF_MOVE_NOCOALESCE is for Vista+, so I can't test it at home. It looks like GetMouseMovePointsEx can retrieve the coalesced events, so it's no big deal. This must not be widely used -- the MSDN reference is 1st in a Google search, and my notes from week 4 are 5th! Back to the code!
+
+The large tablet coords from RawInput aren't buggy or anything. They're hi-res coordinates (0..65535) and must be converted to screen coordinates first. Since WT_POINT messages are not WM_MOUSEMOVE messages, they're probably not coalesced. In other words, don't use RawInput for them!
+
+The GetMouseMovePointsEx is in reverse time order. The latest point is the first one. So search forward for the previous point, then backward from there to add them to blender's queue. Testing looks good -- almost done!
+
+WM_NCCREATE is giving me trouble. Nevermind, sending to default winproc handles it fine.
+
+As of 6:15am, hi-fi mouse input works on Windows. Yay! It did hang once or twice, might be when the point buffer doesn't include prev point. Look into that tomorrow. No need, I found it already. And... fixed! Good night.
+
+



