Bug 413

Summary: mouseWheelMoved event is never generated
Product: [JogAmp] Newt Reporter: Kraft <kraft.aralya>
Component: coreAssignee: Sven Gothel <sgothel>
Status: VERIFIED FIXED    
Severity: normal CC: bienator, gouessej, sgothel, trog
Priority: P2    
Version: 1   
Hardware: All   
OS: all   
Type: --- SCM Refs:
30c959a4534bc0c6b4718ae65fd4f91d68d6eca6
Workaround: ---
Attachments: Source code to demonstrate the bug

Description Kraft 2010-09-11 16:02:28 CEST
Created attachment 153 [details]
Source code to demonstrate the bug

In a simple com.jogamp.newt.opengl.GLWindow,with a MouseListener listening to mouse events, when the user rolls the mouse, instead of calling mouseWheelMoved(), the methods mousePressed() and mouseReleased() are called.

Not critical but still annoying since the method mouseWheelMoved() exists.
We expect the method to be called when the event happens...
Comment 1 Michael Bien 2010-09-11 16:13:07 CEST
*** Bug 382 has been marked as a duplicate of this bug. ***
Comment 2 Kraft 2010-09-11 16:14:22 CEST
Forgot to mention :

i was using jogl-2.0-pre-20100831-linux-i586
on Ubuntu 10.04 with sun jdk
Comment 3 Trog 2010-09-15 12:29:08 CEST
I have the same problem. :-(
Comment 4 Trog 2010-09-16 08:14:19 CEST
I'm using: jogl-2.0-pre-20100611-linux-i586.zip.

> java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

OS: Gentoo GNU linux.
Comment 5 Sven Gothel 2011-10-24 20:42:32 CEST
On Monday, October 24, 2011 08:31:26 PM gouessej [via jogamp] wrote:
> 
> Hi
> 
> This bug prevents me from porting the pre-beta version of TUER to JOGL 2.0:
> 
> A mouse pressed event with MouseEvent.BUTTON4 is generated instead of a
> mouse wheel event. Sven, do you know how to fix this bug?

No, but it rings a bell now.

While still @ Sun, we had a 'discussion' whether to use a dedicated 'wheel'
event or just representing them as another 'button'.

Well, I favored the latter since it's a more generic approach, 
plus we really cannot tell what-else game-pads may have.
Technically it's a button, hence a pass-through button representation 
is IMHO best. For sure I can be convinced otherwise with good (tech.) arguments.

Maybe we can make a checklist here how the wheel is
represented on the native platforms:

Android: None
X11: Usually button4 and button5
Windows: ?
OSX: ?

If they all use a button representation, I guess it's best to remove the 'wheel' ID.

Let me copy paste this email to the bugzilla entry, 
so we can continue it's discussion there (where it belongs IMHO).
Comment 6 Sven Gothel 2011-10-24 21:04:03 CEST
Windows: 
  - WM_MOUSEWHEEL:
    - x/y position 
    - rotation: (jint) ( GET_WHEEL_DELTA_WPARAM(wParam) / 120.0f ) 

+++

http://msdn.microsoft.com/en-us/library/windows/desktop/ms645617%28v=vs.85%29.aspx

The high-order word indicates the distance the wheel is rotated, expressed in multiples or divisions of WHEEL_DELTA, which is 120. A positive value indicates that the wheel was rotated forward, away from the user; a negative value indicates that the wheel was rotated backward, toward the user.

+++

http://msdn.microsoft.com/en-us/library/ms646273%28v=vs.85%29.aspx

If dwFlags contains MOUSEEVENTF_WHEEL, then mouseData specifies the amount of wheel movement. A positive value indicates that the wheel was rotated forward, away from the user; a negative value indicates that the wheel was rotated backward, toward the user. One wheel click is defined as WHEEL_DELTA, which is 120.

Windows Vista: If dwFlags contains MOUSEEVENTF_HWHEEL, then dwData specifies the amount of wheel movement. A positive value indicates that the wheel was rotated to the right; a negative value indicates that the wheel was rotated to the left. One wheel click is defined as WHEEL_DELTA, which is 120.

+++

So I guess we can assume that the WHEEL_DELTA_PARAM is a positive or negative multiple of 120 ?

+++++++++++

X11: mouse button4/5 - we can pass each 'click' as a mouseWheel event.

++++

MacOSX: NSScrollWheel .. w/ some 'complicated' GetDeltaY() code ..

+++

Ok .. bottom line I guess is to generate mousewheel events for X11 and we would be done.
Comment 7 Julien Gouesse 2011-10-24 21:16:55 CEST
X11:

(first wheel)
BUTTON4 -> SCROLL UP
BUTTON5 -> SCROLL DOWN
(second wheel)
BUTTON6 -> SCROLL LEFT
BUTTON7 -> SCROLL RIGHT
Comment 8 Sven Gothel 2011-12-02 07:55:21 CET
As Julien suggested, mapped the 4 X11 button to 2 mouse wheels (See X11Window.java).

> 0: UP
< 0: DOWN

Usually w/ events by 1 .. 

Updated the MouseEvent API doc as well.

See commit: 30c959a4534bc0c6b4718ae65fd4f91d68d6eca6
Comment 9 Julien Gouesse 2011-12-02 12:31:05 CET
It's a very good piece of news. Thank you so much.
Comment 10 Julien Gouesse 2011-12-05 23:03:16 CET
I reopen this bug as mouseReleased(MouseEvent me) is still called when the mouse scroll is moved. The bug fix should consist in avoiding to generate any MouseEvent on release when the wheel position isn't zero.
Comment 11 Julien Gouesse 2011-12-06 23:49:52 CET
I get these logs when using the mouse scroll with the build 577:
doMouseEvent: enqueue false, wait false, EVENT_MOUSE_PRESSED, mod 0, pos 631/446, button 5, lastMousePosition: 631 / 446
consumeMouseEvent: event:         MouseEvent[EVENT_MOUSE_PRESSED, [I@1917a08/[I@1e2b67c, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511376 d 1ms]]]
doMouseEvent: enqueue false, wait false, EVENT_MOUSE_RELEASED, mod 0, pos 631/446, button 5, lastMousePosition: 631 / 446
consumeMouseEvent: event:         MouseEvent[EVENT_MOUSE_RELEASED, [I@13ac14d/[I@68d505, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511377 d 0ms]]]
doMouseEvent: synthesized MOUSE_CLICKED event: MouseEvent[EVENT_MOUSE_CLICKED, [I@7973e4/[I@1a79071, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511377 d 0ms]]]
consumeMouseEvent: event:         MouseEvent[EVENT_MOUSE_CLICKED, [I@7973e4/[I@1a79071, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511377 d 0ms]]]

You can see that there is no mouse wheel event.
Comment 12 Sven Gothel 2011-12-07 00:38:20 CET
I haven't build on master while pushing out the rc branch to save time,
ie not kicking off a master branch build.

RC4: https://jogamp.org/chuck/view/RC/job/jogl-RC/44/
  sha1 30c959a4534bc0c6b4718ae65fd4f91d68d6eca6
  http://jogamp.org/git/?p=jogl.git;a=commit;h=30c959a4534bc0c6b4718ae65fd4f91d68d6eca6

577: https://jogamp.org/chuck/view/fwd/job/jogl/577/
  sha1 4856f7800bac165c3770495b77de4a2eabcca46e

  This one does not contain the mouse wheel tweak ..
Comment 13 Julien Gouesse 2011-12-07 00:46:30 CET
I have noticed that a few minutes ago, sorry. I use the release candidate 4 and now it works fine. Thank you very much.