View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000854 | VTK | (No Category) | public | 2004-05-17 17:02 | 2004-05-21 09:57 | ||||
Reporter | Chris Scharver | ||||||||
Assigned To | Mathieu Malaterre | ||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0000854: vtkCocoaGLView reports incorrect mouse position | ||||||||
Description | vtkCocoaGLView reports an incorrect mouse position on MacOS X. To demonstrate, create a Cocoa VTK window and press the mouse button along the left side of the window. The view should rotate to the left. Now, move the window to the right side of the screen. Click the mouse in approximately the same position. The view spins widely to the RIGHT. The is incorrect, as the mouse position should be registered relative to the window, not relative to the screen. When the class obtains the NSPoint representing the mouse position, it calls -[NSEvent locationInWindow]. Through testing, I verified that this function was returning the screen position for the event, ignoring the request to return the location relative to the window. I eventually tracked this behavior down to the NSPeriodic timer events that are fired. I filed an item with Apple (radar #3168753) in December 2003. The response was, "The fix was just adding clarification to the documentation because the problem is in the test case's use of -locationInWindow. The unexpected coordinates are getting returned when called for NSPeriodic events. the problem here is that you are calling -[NSEvent locationInWindow] for an event for which that method returns undefined values. You could instead call -[NSWindow mouseLocationOutsideOfEventStream] to get the location of the mouse in window relative coordinates." Another approach may be required to properly handle the timer mechanism. There are workarounds for manually converting the event location into the vtkCocoaGLView's NSRect on the screen, but it would be ideal to determine the proper event mechanism that would avoid such workarounds. | ||||||||
Tags | No tags attached. | ||||||||
Project | |||||||||
Type | |||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0001088) Mathieu Malaterre (developer) 2004-05-20 16:23 |
This should be fixed in CVS: http://vtk.org/cgi-bin/cvsweb.cgi/VTK/Rendering/vtkCocoaGLView.mm.diff?r1=1.8&r2=1.9 [^] Thanks to Yves Starreveld for patch |
(0001089) Chris Scharver (reporter) 2004-05-20 18:18 |
Still not quite fixed. There are problems holding the mouse button down. The initial mouse up and down events locations are properly read. The problem is that the mouse locations within vtkCocoaGLView's event methods' internal do..while loops are not converted from the screen to the view. I copied the new code with convertScreenToBase into that internal loop, and that seemed to properly resolve interactor behavior. This fix looks primarily like a bunch of copying and pasting, so maybe I can prepare a diff this evening. |
(0001091) Mathieu Malaterre (developer) 2004-05-21 09:57 |
This should be fixed in CVS: http://vtk.org/cgi-bin/cvsweb.cgi/VTK/Rendering/vtkCocoaGLView.mm.diff?r1=1.9&r2=1.10 [^] |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2011-06-16 13:11 | Zack Galbreath | Category | => (No Category) |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |