[Bf-blender-cvs] SVN commit: /data/svn/bf-blender [30012] branches/soc-2010-merwin/notes/ week 6 notes: human-readable nonsense

Mike Erwin significant.bit at gmail.com
Tue Jul 6 08:24:03 CEST 2010


Revision: 30012
          http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=30012
Author:   merwin
Date:     2010-07-06 08:24:02 +0200 (Tue, 06 Jul 2010)

Log Message:
-----------
human-readable nonsense

Added Paths:
-----------
    branches/soc-2010-merwin/notes/week 6 notes

Added: branches/soc-2010-merwin/notes/week 6 notes
===================================================================
--- branches/soc-2010-merwin/notes/week 6 notes	                        (rev 0)
+++ branches/soc-2010-merwin/notes/week 6 notes	2010-07-06 06:24:02 UTC (rev 30012)
@@ -0,0 +1,229 @@
+29 June --
+
+David at Wacom answered more of my questions about low-level events. I uncovered a bug in Apple's tablet docs: they claim pressure is a Double field, it's actually an integer 0-65535. When even that failed to produce non-zero pressure, I changed the way the tap was installed and Presto! I've got low-level pressure now. Apple's Double pressure does return something, but it's twice what it should be. They're probably dividing by MAX_S16 instead of MAX_U16. But pressure works now. Divide by 65535 or 65536? Subsample scaling, I mean? Using 65535 for now. The difference is so tiny, it doesn't really matter.
+
+He also said that they don't coalesce tablet events on Windows. Hmm... I've got a user's screen shot that says otherwise, so I assumed the problem was the same on Mac and Windows. It's not. It just looks the same. Here's what I think is happening: WinTab's tiny default buffer is filling up, then discarding all other events until emptied. Adding WTQueueSizeSet should fix the problem right away! It accepts up to 128 (more than half a second's worth of input), but the docs recommend testing for success and dialing back the buffer size if it fails. Solved (I hope)! This will not help mouse users, but tablet users can rejoice. Now I just need to successfully build blender on Windows...
+
+From the event intake function (GHOST_SystemWin32::s_wndProc):
+
+	////////////////////////////////////////////////////////////////////////
+	// Tablet events, processed
+	////////////////////////////////////////////////////////////////////////
+	case WT_PACKET:
+		((GHOST_WindowWin32*)window)->processWin32TabletEvent(wParam, lParam);
+		break;
+	case WT_CSRCHANGE:
+	case WT_PROXIMITY:
+		((GHOST_WindowWin32*)window)->processWin32TabletInitEvent();
+		break;
+	
+	...
+	
+	case WM_BLND_NDOF_AXIS:
+		{
+			GHOST_TEventNDOFData ndofdata;
+			system->m_ndofManager->GHOST_NDOFGetDatas(ndofdata);
+			system->m_eventManager->
+				pushEvent(new GHOST_EventNDOF(
+					system->getMilliSeconds(), 
+					GHOST_kEventNDOFMotion, 
+					window, ndofdata));
+		}
+		break;
+	case WM_BLND_NDOF_BTN:
+		{
+			GHOST_TEventNDOFData ndofdata;
+			system->m_ndofManager->GHOST_NDOFGetDatas(ndofdata);
+			system->m_eventManager->
+				pushEvent(new GHOST_EventNDOF(
+					system->getMilliSeconds(), 
+					GHOST_kEventNDOFButton, 
+					window, ndofdata));
+		}
+		break;
+
+Make sure that tablet events aren't also masquerading as mouse events as they do on Mac OS. That NDOF code will be replaced by RawInput events. Down with plugins! GHOST_System will host the shared NDOF axis data. Each platform's subclass will write to this and enqueue the event, which includes a pointer to the axis data. Remember, NDOF events are transient, so this simple shared scheme works well.
+
+For some reason, the Window processes tablet point and prox events. Reading... Nothing particularly Windowy about the code... I'll try moving it to System and see what breaks. Try on Mac first since I'm already familiar and comfortably building. I might add a protected initTablet function to each, to set up data structures and test for functionality once instead of every freakin' time (see GHOST_WindowWin32::processWin32TabletEvent). The function I'm picking on is very well documented though.
+
+Tablet init is in Window constructor. This should probably move to System, as blender can have more than one window now. It starts like this:
+
+	m_wintab = ::LoadLibrary("Wintab32.dll");
+	if (m_wintab) {
+		...
+
+It checks for various capabilities here, and again on tool proximity. For example, max pressure, tilt ranges, that sort of thing. Max pressure should remain constant for any tool on a certain tablet, right? If so, check only once. After it's done exploring the capabilities, it officially opens the tablet for business:
+
+	m_tablet = fpWTOpen( m_hWnd, &lc, TRUE );
+	if (m_tablet) {
+		m_tabletData = new GHOST_TabletData();
+		m_tabletData->Active = GHOST_kTabletModeNone;
+	}
+
+All this checking is very cautious. Why not just #include WinTab.h, check for library load, then ask for its version to determine function availability. If it's an old version, could suggest that the user updates their drivers! This looks promising:
+
+	/* info categories */
+	#define WTI_INTERFACE		1
+		#define IFC_WINTABID			1
+		#define IFC_SPECVERSION		2
+		#define IFC_IMPLVERSION		3
+		...
+
+Wacom says this about WinTab.h:
+
+	"The text and information contained in this file may be freely used,
+	copied, or distributed without compensation or licensing restrictions."
+
+Oh yes, before I forget... The above code calls processWin32TabletEvent on each WT_PACKET event. It should empty WinTab's queue, not just grab one off the front. Use WTPacketsGet instead of WTPacket. This is more responsive and recommended for higher performance. High fidelity!
+
+Window destructor calls WT_Close.
+
+More fun in WinTab.h:
+
+	/* Extension tags. */
+	#define WTX_OBT				0	/* Out of bounds tracking */
+	#define WTX_FKEYS				1	/* Function keys */
+	#define WTX_TILT				2	/* Raw Cartesian tilt; 1.1 */
+	#define WTX_CSRMASK			3	/* select input by cursor type; 1.1 */
+	#define WTX_XBTNMASK			4	/* Extended button mask; 1.1 */
+	#define WTX_EXPKEYS			5	/* ExpressKeys; 1.3 - DEPRECATED: see WTX_EXPKEYS2 */
+	#define WTX_TOUCHSTRIP		6	/* TouchStrips; 1.4 */
+	#define WTX_TOUCHRING		7	/* TouchRings; 1.4 */
+	#define WTX_EXPKEYS2			8	/* ExpressKeys; 1.4 */
+
+Blender uses x,y tilt, converting from azimuth and altitude. Apparently we can just read it off! Very handy. Pretty sure the following (using WTExtSet) is the OLED entry:
+
+	typedef struct tagEXTPROPERTY { /* 1.4 */
+		BYTE		version;				// Structure version, 0 for now
+		BYTE		tabletIndex;		// 0-based index for tablet
+		BYTE		controlIndex;		// 0-based index for control 
+		BYTE		functionIndex;		// 0-based index for control's sub-function
+		WORD		propertyID;			// property ID
+		WORD		reserved;			// DWORD-alignment filler
+		DWORD		dataSize;			// number of bytes in data[] buffer
+		BYTE		data[1];				// raw data
+	} EXTPROPERTY;
+
+Well, not quite. Can override ExpressKeys with that and set their text, but not image. I read how to do that on the developer site, so I'm not worried about it.
+
+1 July --
+
+The Mac SpaceNav demo crashes on machines without a SpaceNav driver installed. While this was anticipated, I should fix it... I especially don't want blender to crash because of this! The example code weak links to test for the driver, but Obj-C++ wouldn't allow that. I know C allows it, and hopefully C++ does as well. If it's C only, I could just split that little function off and call it from the larger NDOF setup code.
+
+No need to test for NDOF presence on Windows. Just register for multi-axis events from RawInput. They show up if there's a SpaceNav device; they don't if there's not. Simple as that! I'll have to look again at how Linux handles it.
+
+Windows build failed again yesterday, from SDK7 (scons), SDK6A (scons), and Visual Studio 2008. Maybe it's the build machine? I'll try on my own tonight or tomorrow.
+
+Oh yeah! I re-read and annotated the "3D Mouse" document yesterday, working out how to apply everything to blender. The RawInput section was especially handy. I'm handling the events a bit different (working through the internal queue on each event signal, keeping only the most recent), but the foundations are there on the page.
+
+Damn, I don't have the Windows lib collection here at the house. That must wait until tomorrow then. Maybe I'll just bring Dude (my WinXP/Ubuntu desktop) to the lab for an overdue system update and build session.
+
+I'm thinking about simple NDOF and Tablet expert objects... Set up, shut down, interpret events, that sort of thing. Maybe that should stay in GHOST_System*.cpp? There's already a GHOST_NDOFManager, which mostly handles the plugin. No need for that going forward, but it might help to have something besides a big block inside System. I dunno, will revisit soon.
+
+I need to catch up on the discussion I started on BlenderArtists. Anything new?
+
+Ok, I get it now. I think. Tablet data lives in the Window instead of the event stream because only GHOST_EventCursor is sent from mouse or tablet input. Operators need some way to get tablet info, so they ask their window. Simple enough, but I'm deprecating that path in favor of true tablet/pen events. Existing pressure-sensitive tools will need to be converted to use the new scheme. Leave the old in place but complain loudly when it's used! Tablet and mouse events can be spoofed on dispatch as described on this project's web site.
+
+Tablet events will indicate capabilities (pressure, tilt, etc.). Copy these from each tool's capability data found during proximity.
+
+GHOST_EventManager handles all events and event consumers in a generic way. This seems to be the place to cull events for LO_FI consumers, but I'd hate to mess up the simplicity of this code. Is there another place? LO_FI should improve overall responsiveness, and HI_FI should provide a better connection between the hand and its work on screen. In other words, it's worth it!
+
+Spoofing can happen in the consumer's main handling function.
+
+I also need to remove the gpencil Manhattan option from the preferences window, since I'm not using it.
+
+Hi-fi seems to have little or no effect on trackpad input. What about a tablet? Wacom mouse delivers nice smoothness, but I need to fix the pen... Pen moves the cursor and hover-grab works, but seemingly no events from surface contact. Oops. Fix.
+
+Ok, discovered the problem: Blender has no "mouse drag" events. A drag is just a move between button down and button up. I'm sending all pen-based events to handleTabletEvent, which currently only sends cursor move events. It should check the event type for mouse up/down and send that instead of move.
+

@@ Diff output truncated at 10240 characters. @@




More information about the Bf-blender-cvs mailing list