search

Loreinator / Shuffle-Move

Program to help choose moves in the Pokemon Shuffle puzzle game
GNU General Public License v3.0
95 stars 18 forks source link

Java 8u60 Performance Bug #57

Open Loreinator opened 9 years ago

Loreinator commented 9 years ago

See here

Not much to be done as far as I can tell, I spent the night trying to figure out what to do about it and troubleshooting through various JREs and Shuffle Move versions while profiling to isolate the exact cause. If anyone has any ideas, please share or make a pull request with your solution.

Loreinator commented 9 years ago

Now that I'm rested, I was able to look into more about the cause:

Nimbus LAF just uses a lot more resources to display than the default LAF. That's why we notice it obviously with NLAF.

Profiling results:

Each result will be in the format of 4 numbers, defining the ratio of usage for each of:

  1. sun.java2d.d3d.D3DSurfaceData$1.run()
  2. javax.swing.RepaintManager$ProcessingRunnable.run()
  3. EditRosterService.createRosterComponent(Species)
  4. EditRosterService$3.getPreferredSize()

Test is simple: Go into the roster editor, start CPU profiling, then scroll as much as the mouse possibly can.

On 8u51 using Nimbus: 53.8 / 15.0 / 20.1 / 0.0

On 8u60 using Nimbus: 84.1 / 11.7 / 2.6 / 0.0

On 8u51 using Default: 1.8 / 97.2 / 0.0 / 0.2

On 8u60 using Default: 86.1 / 13.7 / 0.0 / 0.0

Note the extreme change from 8u51 to 8u60 for the default. There is obviously something going wrong with usage of D3DSurfaceData$1 to change by such a huge amount - 340 times more CPU is used in u60 than u51.

The difference is less prominent in Nimbus, where the CPU change is only 1.75 times more - this is likely because Nimbus uses far more D3DSurfaceData$1.run() calls to start with. This also indicates that it is not a problem with these methods taking longer than before - it is probably just that something is calling them FAR more often than it should, irregardless of the LAF settings.

So, as you can see, the lag is likely caused by an extremely high usage of sun.java2d.d3d.D3DSurfaceData$1.run() and is not isolated to Nimbus Look And Feel. For whatever reason, in either LAF the performance is much worse. The only benefit to using Default is a slightly less laggy experience, where the responsiveness is better than Nimbus but definitely not u51 smoothness.

I'm not sure if I want to switch it to the default since the rest of the program will look more jagged and less kind, which is not the point of an interface for something like Pokemon. For now I will leave it as-is until we know more.

Loreinator commented 8 years ago

Just as an update: it appears that the Java developers have found a fix for a related problem (the scroll bar disappearing). It should be in for 8u76.