I am wondering if this is the same issue I'm experiencing:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2014-August/006700.html
If so, it's because Java 7 and later are defaulting to OpenGL drawing on
Macs, which is slow, and there appears to be no way to change this
behavior. Java 6 uses some other form of drawing. This can be revealed
by adding -Dsun.java2d.trace=count to the java command line and noting
the differences in the output between Java 6 and Java 7/8.
On 8/18/14 9:05 AM, Florian Bruckner (3kraft) wrote:
Hi Sergey,
I have built a minimalistic test case that exposes the problem. It
creates a JFrame with an editor pane in it to show some HTML content (a
javadoc page). The test is to just scroll from the bottom to the top and
back to the bottom by mouse wheel as quickly as possible, I did 5
iterations in each test run.
Wall clock timing was approx. 15 seconds with Java 6 and approx 45
seconds with java 8. As the problem worsens with increased screen
resolutions I decided to use the full resolution of my new UHD display
(which is 3840x2160), the machine is a
MacBook Pro
15-inch, Early 2011
Processor 2 GHz Intel Core i7
Memory 16 GB 1333 MHz DDR3
Graphics AMD Radeon HD 6490M 256 MB
Software OS X 10.9.4 (13E28)
These are the java versions:
$ java -version
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
$ /System/Library/Frameworks/JavaVM.framework/Home/bin/java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
With java 6, the application felt agile and responding, whereas with
java 8 it was barely usable.
Attachments were rejected from the list, therefore I have uploaded them
to our web storage (this link expires Aug 31st):
https://owncloud.3kraft.com/public.php?service=files&t=ae0f609d6bd42b27a5ea38261507a38c
Please let me know if those results are usable for you.
regards,
Florian
