Newt Mouse Event

On 11/12/2012 07:09 PM, gouessej [via jogamp] wrote:
> Ok thanks, it just returns the same value than getWheelRotation but it does
> not cast it to int.
>
> @Sven adding such a method in NEWT is trivial, isn't it?

You mean just use the float: "float rot = GET_WHEEL_DELTA_WPARAM(wParam)/120.0f;" ?

Hmm .. why not - now I more up to changing the API to return floats
if this doesn't really annoy others too much :)

Would be binary incompatible (needs recompile) but compile clean.
Since we change a few places already which requires recompilation .. I guess thats ok.

~Sven

gouessej wrote

Yes please write a small bug report, be as accurate as possible, mention your mouse, your OS, etc...

I have just read that, I still don't understand how to get the scroll amount.

I've created the bug report, #639.

Thanks.

Yes but why not returning a double rather than a float?

On 11/13/2012 01:19 AM, gouessej [via jogamp] wrote:
> Yes but why not returning a double rather than a float?

Always having 32bit systems in mind :)

double is 64bit, and do we need such a high precision for the wheel ?
I doubt.

~Sven

Ok but why does the new method in Java 1.7 return a double?

On 11/14/2012 01:49 AM, gouessej [via jogamp] wrote:
> Ok but why does the new method in Java 1.7 return a double?

b/c they don't care about mobile, 32bit and efficiency ?

Lots of stuff is using double in JRE .. i.e. haven't seen proper
float sqrt in Math either :)

~Sven

You're right. I thought there was a real reason behind this choice. JInput uses a float for this too.

Now, C is not really my strong point but I think I've figured out why this is happening.  I believe it is part of the native code.

This is a section from the WindowsWindow.c file:

    case WM_MOUSEWHEEL: {
        // need to convert the coordinates to component-relative
        int x = GET_X_LPARAM(lParam);
        int y = GET_Y_LPARAM(lParam);
        POINT eventPt;
        eventPt.x = x;
        eventPt.y = y;
        ScreenToClient(wnd, &eventPt);
        (*env)->CallVoidMethod(env, window, sendMouseEventID,
                               (jint) EVENT_MOUSE_WHEEL_MOVED,
                               GetModifiers( FALSE, 0 ),
                               (jint) eventPt.x, (jint) eventPt.y,
                               (jint) 1, (jint) (GET_WHEEL_DELTA_WPARAM(wParam)/120.0f));
        useDefWindowProc = 1;
        break;
    }

In my case (and I guess with other precision wheel mice) the wParam has a value of 30 for slow rotations.  This gives a value of 0.25 which when cast to an integer is obviously 0.  This is not a major problem, however I believe this remainder should be carried over to any future events.

I tried modifying this section as follows (variable wheelValue being a class variable):

    case WM_MOUSEWHEEL: {
        // need to convert the coordinates to component-relative
        int x = GET_X_LPARAM(lParam);
        int y = GET_Y_LPARAM(lParam);
        POINT eventPt;
        eventPt.x = x;
        eventPt.y = y;
        ScreenToClient(wnd, &eventPt);
        float newWheelValue = GET_WHEEL_DELTA_WPARAM(wParam)/120.0f;
        if((newWheelValue > 0 && wheelValue < 0) || (newWheelValue < 0 && wheelValue > 0)){
            // Reset the saved wheel value if the direction is changed
            wheelValue = 0;
        }
        newWheelValue += wheelValue;
        int intWheelValue = (int) newWheelValue;
        // Save the wheel value to carry over
        wheelValue = newWheelValue - intWheelValue;
        (*env)->CallVoidMethod(env, window, sendMouseEventID,
                               (jint) EVENT_MOUSE_WHEEL_MOVED,
                               GetModifiers( FALSE, 0 ),
                               (jint) eventPt.x, (jint) eventPt.y,
                               (jint) 1, (jint) intWheelValue);
        useDefWindowProc = 1;
        break;
    }

When my test program is run with this version and the mouse is turned slowly, each 4th event returns a 1 for getWheelRotation() as with AWT.  Do you think this could be a fix without introducing a new method to JOGL?

Thanks.

I don't understand. As far as I know, getWheelRotation() returns 0 too with AWT in such cases because it is implemented in the same way that in NEWT. I suggested to add a new method returning a float a bit like the new method in Java 1.7. In my humble opinion, this is the real fix except if getWheelRotation() returns 0 with NEWT but 1 with AWT in some cases. I have no such mouse to test.

It can't be implemented the same way in AWT as NEWT because I get different results with each (Even if JDK6 is used).

Its a bit difficult to explain, but I'll try.  As I understand it, most mouses have wheels that kind of click as they turn and that one click equates to a line of movement.  So one click on this type of mouse would be 120 such that 120/120 gives 1.  On these mice, I'm assuming getWheelRotation() always returns at least 1 or -1 (i.e. a 0 is never observed).

The mouse I have does not have a wheel that clicks.  It's free running and I think the wheel is more precise.  This appears to give 30 on each event such that 30/120 gives 0.25.

If I rotate my mouse wheel such that 8 mouse events are received:

With NEWT getWheelRotation() returns 0, 0, 0, 0, 0, 0, 0, 0.

With AWT getWheelRotation() returns 0, 0, 0, 1, 0, 0, 0, 1.

Therefore, it appears AWT is working as in my example above.  This makes a big difference.  I'm using the wheel for zoom and under AWT events it works perfectly.  But using NEWT events it never zooms as a 1 is never returned, no matter how many full turns of the wheel are made.  That can't be right as it shouldn't be possible to turn the wheel and not trigger something to happen.

With my mod above, the zoom in my application works using NEWT and appears identical to AWT.

I think it would be nice to have a method that returns a float, but I think getWheelRotation() under NEWT is still slightly incorrect for this type of mouse.

On 11/16/2012 11:57 PM, gsxruk [via jogamp] wrote: So AWT accumulates until it overlaps.

We could do either, return the 1 (while adding up the fractions)
or return the fractions as they appear as float. We already discussed this and
I prefer the latter.

On OSX it is actually similar handled like on Windows, it uses a float
and we strip of the fractions.

I guess on X11 there is equivalent, since it operates solely on clicks.

So .. it will be float. Will notify you when done - so you can test.

BTW: Can you give us some product names of said high-res mouse ?
Maybe I can get one ..

~Sven

The mouse is a Microsoft Wireless Laser Mouse 6000.  I think most Microsoft wireless mice are like this.

My only comment is that if the current getWheelRotation() method stays "as is", any application that uses it could appear to work fine with a standard mouse, but if used with this type of mouse, it's possible a user would be unable to use the wheel at all.  I don't think the precise method has been introduced as a fix to this in JDK7 (as it already works), but to provide a finer level of control to those that need it.

Look forward to the fix whichever way you decide to go.

Thanks.

Maybe we should look at how getWheelRotation() is implemented in OpenJDK 1.7 to solve your problem, it probably uses something similar to your fix.