#3102 UI very slow - bug or feature^W normal?

[vasya novikov]

Hi. I'm not sure it's a bug, so any help or advices are very welcomed.
The problem is that freecol UI is slow, and sometimes extremely, horribly slow.
Common timers:
- 3 seconds to open colony window (when you had the main map view before)
- 1 seconds to close colony window (and return to main map)
- 2 seconds to re-calculate path when you use "go to" action ("G" shortcut). It's 2 seconds for each tile you try to hover.
- 2 seconds to open "Colony Advisor"
- 1 second co close "Colony Advisor"
and so forth.

Is that normal for the current freecol? If not, anything I can do to help?

[vasya novikov]

Wow! I finally was able to fix it!

The final answer was found here: https://wiki.archlinux.org/index.php/Java#Better_2D_performance

It is to run FreeCol.jar with -Dsun.java2d.opengl=true property. Setting it at runtime via System.setProperty() works, too.

I'll try to submit an MR now. The downside of this approach is that the starting screen, as well as some other screens, get buggy. At least on my system. Needs testing, I guess. But on the up side, calculation, changing map center, opening and closing colony view finally became near-instant!

[vasya novikov]

Merge request: https://sourceforge.net/p/freecol/git/merge-requests/56/

needs testing! For example, the main screen title looks like this on my comp

[vasya novikov]

This is how startup notification looks like (the first thing you see, before video):

[vasya novikov]

I can't comment on the Merge Requests somewhy (sf.net feels really strange after gitlab/gogs/github). So I'll need to comment here.

Another downside of the PR I provided: java options get hardcoded into source, which is not overridable further. That's bad.

I think about closing the MR and creating a new one, which would recommend to do stuff in "help", not force it.. Dunno how to do it best. Both hard-coding and such slowness are horrible.

[Turbo Beholder]

Why indeed stuff it into jar, when you can just as well add " -Dsun.java2d.opengl=true" to the script launching java with that jar (packaging/common/freecol.sh & packaging/common/freecol.cmd)? Though cmd would probably require "-Dsun.java2d.d3d" instead.

Also, searching for "sun.java2d.opengl=true" quickly shows acceleration is prone to such bugs and incompatibilities.
So this may depend on JRE and jOGL versions.

[vasya novikov]

java2d, choosing founding father

[vasya novikov]

java2d, checking "Congress Advisor"
Note that all pictures in this screenshot and the previous one get to normal if you load some other tab and return to this tab back.

In other words, it works correctly on second load, but is always buggy on first load.

[Turbo Beholder]

In other words, acceleration was turned off, probably because it can be turned on/off somewhere in java settings.

Maybe there's also some obscure option that controls buffering, too? =)

I just launched 0.11.6 with extra parameters a few times - adding or removing this option doesn't seem to change anything, perhaps java just handles it correctly like it's suposed to do.

[vasya novikov]

I think this may depend on the java version you use. Mine is OpenJDK 64-Bit Server VM (build 9+181, mixed mode).

[vasya novikov]

What if you set it to false? Like -Dsun.java2d.d3d=false or -Dsun.java2d.opengl=false or -Dsun.java2d.noddraw=true? It's really interesting how it behaves differently on other platforms. BTW, which java version do you have?

[Mike Pope]

We already provide a client option that controls a different Java option that I have seen cause slow graphics, so we can add another if needs be. Hacking the script is not portable across our supported targets, so the code is the place to do this. However the other odd side effects are not encouaging here.

[vasya novikov]

I did some work in trying to fix java2d.opengl graphics. Results so far:

1 . No "code" solution was found. The main testing arena is MainPanel.java. Testing can be done near the add(logoLabel) line. For example, like this: add(new JLabel(new ImageIcon("data/rules/classic/resources/images/ui/freecol2.png")));

Unfortunately, the bug just persist, and no tricks I know of could help.

2 . Accidentally, I found out that altering the image may help. After lots of testing, the problem was reduced to this simple fact: if the upper-left pixel is transparent (in terms of PNG), the bug goes away.

Now, the question is: should we do it? Should we iterate through all the images, add an alpa-pixel to the upper-left just to avoid this java2d bug, for platforms that would otherwise have performance penalties (presumably OpenJDK users)?
We certainly can. But it feels like selling your soul to the devil. TOO wrong.

IDK what to do about it. @Mike, @Turbo thoughts? Attached are 2 images of freecol run under java2d.opengl, with and without the alpha-pixel.

[Mike Pope]

The transparency hack strongly indicates a Java bug IMHO. Have you checked the java development bug tracker for similar problems? They may have further wisdom and/or workarounds.

[vasya novikov]

I've tried net-searching it before and tried openjdk bug tracker now. Unfortunately, I wasn't able to find anything useful.

Thing is, it would actually make sense to raise a bug. I just didn't wanna do it cause I'm somewhat lazy. But maybe I should anyway.

[Mike Pope]

But maybe I should anyway

I think that is the most likely way to get this problem fixed.

[vasya novikov]

UPD: "good" news. I'll still have to sell my soul to the devil, but even setting partial transparency on the upper-left pixel does the trick. So it can be made almost visually indistinguishable (at least if no one can find that 0.3-1% transparency with his eyes).

[vasya novikov]

UPD: I fould out the following: if the image is a "transparency-enabled" PNG (it has at least one partially transparent pixel), there is no bug.
This feels less surprising now as a transparency thing may very well be rendered differently than a thing without transparency.

[Beep6581]

Same for me - the game is unplayably slow, being sluggish when you start a new game and quickly growing to take a few seconds before any screen refresh once you get into a game.

But with "-Dsun.java2d.opengl=true", it's perfectly enjoyable again! The intro video and splash images when loading the game are wrong, but the rest of the game is fine!
https://i.imgur.com/YdFoCcL.jpg

It's in your best interst to either either add "-Dsun.java2d.opengl=true" to the launcher (if the game has one), or to let users know through some other means of the existence of this option, otherwise (potential) players will turn away. Only a very small percentage of users take the effort to report a problem. I gave up on this game a year ago due to the unplayable slowness, and came across this option/solution quite by accident. Hooray!

[Beep6581]

By the way, I'm using commit 9ab8fb128
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (IcedTea 3.5.1) (Gentoo icedtea-3.5.1)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)

[Mike Pope]

OK, In git.a9dafd5 I have added a hack to enable the sun.java2d.opengl property. For now it is on by default, but if you want to toggle it look under Preferences/Display/Enable OpenGL. Lets see if that works for the speed issue, and how bad the graphics glitches are.

FTR:
- I have not seen the speed problem
- I do not doubt that it is real
- I am fairly convinced its a Java problem. AFAICT FreeCol is not doing anything weird.
- OpenJDK 1.8.0_151 and previous

[vasya novikov]

( SF doesn't auto-detect git commits, so it's this commit: https://sourceforge.net/p/freecol/git/ci/a9dafd5/ )

[vasya novikov]

I must report that the current patch doesn't work, yet.
1. Re-start is needed for such changes to apply, I think. Also, there should be a warning of the need of a re-start in settings.
2. It doesn't, in fact, work even if set to the right value AND re-started. I believe this is because the setting gets set too late, and something else might already sneak in and initialise some graphics subsystem.
3. The setting just shows "Enable OpenGL", with the same hint as the main label. I can't see any explanations (except in source code). BTW, I'd rename the option to "Experimental: enable OpenGL" (since what we do now is definitely experimental, yet).

[Mike Pope]

Re-start is needed

Correct. This is unavoidable. The pixmaps option has the same problem, but people coped.

I believe this is because the setting gets set too late

If so, something very strange is happening. The properties are set right at the start of the GUI initialization before we call any graphics routines. I could move them up just one step to FreeCol.startClient but any earlier and the saved game options will be lost.

I can't see any explanations

Suggestions welcome. Note though we tend to use "Experimental" for FreeCol extensions that are believed to have rough edges, not for external bug workarounds like this.

[vasya novikov]

Well, I know for a fact that setting this property as first line of main() works. So we just need to find the right place for the code.
I think I've gotta do it, because I'm the one that can observe different behavior. ( Though I still wonder what happens if you set this on Windows: https://sourceforge.net/p/freecol/bugs/3102/#e5b5/5f89 )
I'll do it a bit later.