MacOS X: Sierra scrolling

Дата публикации: 25.09.2016 21:37:01

After MacOS was updated to 10.12 (Sierra), there have beena lot of complains about the very fast scrolling in every our IDE. Because I rewrote scroll bars in the IDEA platform, I became the chosen one. I was chosen to investigate what is going on.

The investigation was quite complicated because the issue was reproducible not on every Mac. For now, I suspect that you need to scroll with a trackpad on Retina display to see the actually fast scrolling. When I got such a computer, I created a simple Swing application. It showed that the problem was in JDK, not in IDEA. Then, I found the corresponding bug and another bug, which fix had become a reason for fast scrolling. The most surprising was that I reproduced the same issue in the Terminal application included in the operating system.

During my investigation I discovered that the preciseWheelRotation property was added into the MouseWheelEvent class since Java 7 (maybe to support gesture scrolling). I never heard about it, despite the fact that I worked in the Swing/AWT team at that time. This property contains correct values on any Mac, including Sierra, but it is not used in JDK. Even Swing components are not aware of its existence! Therefore, I had to find and correct the calculation of the wheelRotation property, which is used to perform scrolling.

Sierra generates much more scroll events than El Capitan. So the native delta from the operating system became close to 0, but Swing still converts it to 1. This makes scrolling too harsh. The proposed fix has been already added to the JetBrains JDK. It successfully solves the fast scrolling problem. However, I understand that my solution is not ideal, because the preciseWheelRotation property is equal to the wheelRotation property. It makes first property completely useless.

Because of this imperfection, I want to modify my fix so that a user can enable the precise scrolling again. But we have the following constraint: the sum of all wheelRotation values during a long period must be close to the sum of all preciseWheelRotation values for the same period. This means that sometimes we have to generate events with wheelRotation = 0.

However, people do not expect that the wheelRotation may be 0. For example, the BasicScrollPaneUI class does not consume mouse wheel events in this case: this was a true reason of the 7141296 bug. But I believe that Oracle can fix all such places in JDK.

Other problems may arise in user's code. For example, IDEA uses the following code for scaling:

    if (e.getWheelRotation() < 0) {         zoomModel.zoomOut();     } else {         zoomModel.zoomIn();     }

This code won't work as expected, because zero wheelRotation may have negative or positive preciseWheelRotation values. I'm sure that we can fix the IDEA platform, but what's about other UI developers?

I will propose both solutions to my colleagues from the Swing/AWT team. Feel free to post your thoughts about these problems here, or you can join the mailing list: awt-dev@openjdk.java.net