Low framerate and high CPU usage about amidst HOT 23 CLOSED

I did some profiling but am not yet familiar enough with the code to figure out why ImageDrawer.draw() is creating such a load.

I was thinking perhaps the graphics routines aren't being accelerated for some reason, i.e. it's all being done by the CPU. As far as I can tell, Amidst4 is enabling graphics acceleration, but point 2 of this post indicates that the way BufferedImages are used can affect whether they are accellerated. Note that this whole theory could be wrong, but it's as far as I got on the problem tonight.

from amidst.

Amidst is indeed limited to 50 fps. It is odd, that we have a performance issue, especially because I do not know about any specific change that I made, that could cause this issue. I did some testing with the accelerated buffered images. On my machine, most of the images are being accelerated. Here is the code I used to test this:

private volatile int accelerated = 0;
private volatile int counter = 0;
private final GraphicsConfiguration gc = GraphicsEnvironment
        .getLocalGraphicsEnvironment().getDefaultScreenDevice()
        .getDefaultConfiguration();

private void log(BufferedImage image) {
    if (image.getCapabilities(gc).isAccelerated()) {
        accelerated++;
    }
    counter++;
    if (counter % 10000 == 0) {
        System.out.println("accelerated: "
                + (100.0d * accelerated / counter) + "%");
    }
}

Place this in the class ImageDrawer. Then replace the line:

    g2d.drawImage(fragment.getImage(declaration.getLayerId()), 0, 0, null);

with

    BufferedImage image = fragment.getImage(declaration.getLayerId());
    log(image);
    g2d.drawImage(image, 0, 0, null);

I get about 99% accelerated images. Maybe, you can use this to find out whether the acceleration is the problem.

Also, when I set the FPS limit to 100, I get varying result: everything from 60 to 100 FPS, pretty much independent of whether fragments are currently loaded or not. You can set the FPS limit in the method ThreadMaster.startRepainter(). To get to 100 FPS, you should replace the 20 by 10.

Regarding the CPU usage: When fragments are loaded, the CPU load is high. When all fragments are loaded and Amidst is in full screen, the CPU load is low again. However, as you said: All of this is also dependent on the hardware you run it on.

I hope some of these information can help you to figure it out.

from amidst.

I'm getting 0.0% accellerated here.

I've downloaded the beta6 executable and run that to eliminate my build environment from the set of possible causes. The beta6 exe has the same poor performance as the one I built that reports 0.0%.

I've compiled AmidstExporter against JavaSE-1.8 to eliminate Java 7 or 8 improvements possibly raising the acceleration support hardware requirements, but it still ran at 50fps full screen.

Because of your acceleration logging, my suspicion is still that the problem will have something to do with my VM evironment providing Java with less-than-normal acceleration capabilities. I'm still confused by why one program is accelerated but not the other, but no longer as concerned about this bug since mine isn't a normal user environment. I'll look into adding some sort of acceleration indicator to the FPS widget (Edit added - see #44).

Update: If I run it on natively on the host machine it's 99.66% accelerated, so I assume there's some extra feature it uses that the VM acceleration can't provide.

(For future reference, these observations were made in Windows 10, running under VMware Player 7.1.2 build-2780323)

from amidst.

I'm running Amidst4.0b6.exe on a Windows 10 system, with Java 1.8.0_71 64 bit and a GeForce GT 730 GPU.
I set task manager to "always on top" and Amidst to full screen.
Panning and zooming the map doesn't cause frame rate to go below ~48 fps and it quickly gets back to 50.
CPU usage is quite low for the Java process that contains Amidst. Spiking up to 20% momentarily when zooming and then dropping back down to ~3%.

from amidst.

@BigAlanM Thanks for testing it out.

@Treer I am still a little big concerned about this issue, even though it did only occur on a VM until now. I also compared the usage of the buffered images to how they where used in Amidst v3.7. I was not able to spot any difference. v4.0 does not use any other methods. I guess we have to consider this a non-issue until we get more reports about it, which is hopefully not gonna happen.

For now I will leave this open.

from amidst.

I updated the VM to the latest version, which adds support for DirectX 12, and I doubled the VM gfx memory to 512 MB, still no acceleration.
There's another gfx issue on a different computer that I'm still investigating - all the Amidst4 windows are blank - this is running natively, not in a VM. Once I know more I might open it as a seperate issue, but I suspect it's a gfx driver issue with the latest Java and not anything Amidst4 is doing.

from amidst.

While investigating #81, I might have found a fix for this issue. Please have a look at #82 and test whether the issue still exists for you. I now do get 100% acceleration on my windows machine.

from amidst.

It's Friday here and I'm at work. My work PC reproduces the white screen bug, but I can't build Amidst here, so if you can send me a build in the next 5 hours I could test whether it affects the white-screen issue.

(Otherwise white-screen testing will have to wait until Monday)

from amidst.

I just created a new release: Amidst v4.0-beta9

It contains the fix. First, I wanted to upload the jar-file directly to this issues, but github does not like jar-files being uploaded here.

While you are at it: I noticed still a few problems with the rendering that I was unable to solve.

When I resize the main window, the complete contents of the window is scaled, until it gets redrawn. What I mean by that is, that the currently displayed graphics are skewed to fit completely into the new window size. This also means the width to height ratio is wrong. I am not sure whether my description is clear. Sadly, I cannot create a screenshot of this, since it gets redrawn with the next frame.

I will shortly post a description of another issue which is probably related.

from amidst.

Your description seems clear but I don't see it happening here - when I resize the main window (by dragging one of the bottom corners), the map image does not resize, it stays attached to the top left corner of the window and newly generated fragments start fading into the new space created by resized the window.

Do you have a monitor plugged directly into

v4.0-beta9 had no effect on the white-screen issue, but the white screen issue only happens on one of my two monitors (I swapped the working monitor to be the windows primary monitor and it made no difference swapped which monitor worked), if I drag the window over to the other monitor then it's still initially white but all subsequent updates get draw so the app works normally again once you force a redraw. So in my case the bug is not in Amidst, it's either Java or video drivers, however the general java-app white-screen issue sounds like it can be caused by more than one thing, so:

• I'll try some of the other folk-remedies such as uninstalling and reinstalling java.
• My case of white-screen might not be the same as Talyda's

The acceleration percentage is all over the place - too complicated to describe, but we know the acceleration is broken on this PC, so I won't pay attention to the percentage until it's working properly.

from amidst.

The second issue is, that the window does not redraw itself if the opengl acceleration is activated. You can see this in the screenshot below. The steps to get there are the following:

• load any profile
• do not generate a map
• resize the window
• hover over any menu entry

This will turn the complete window black, except for the menu entry. When you switch to another window the complete menu bar will redraw, but not the remaining window. To reproduce this, you might have to try it multiple times and close Amidst in between. To me, it does happen about 50% of the time.

I can observe the same behavior when a map is loaded. This is even more reliable. The map itself will still redraw itself, however not the menu bar. It becomes completely black as soon as I maximize the window. This also does not happen always, but more than 50%. Steps to reproduce:

• load any profile
• generate a map
• maximize the window

I am unable to post a screenshot of this, since the menubar is repainted as soon as I switch the windows to create the screenshot.

It would be great if you could try whether these problems also exist on your machine.

from amidst.

What appears to be happening on this computer is that acceleration is enabled on the primary monitor, but not the secondary. The bug is in the acceleration, so the primary monitor = white-screen bug, and the second monitor = not accelerated.

This means I'm unable to test your redraw scenario until I get home, as I have working acceleration on my home PC (just not in the virtual machine I usually use).

from amidst.

@Treer

Too bad, this did not fix the acceleration issue on your machine. I really thought this is the solution.

Here are the specs of my machine:

• Windows 8.1 Pro and Ubuntu 15.10
• Java 1.8.0_73
• Lenovo L450 (Notebook)
• 64-bit
• Intel Core i5-5200 CPU @ 2.20 GHz
• Intel HD Graphics 5500
• no external monitor, just the one integrated into the notebook

I am still trying to understand the thing with the monitors. One is working, the other is not. Then you switch the primary monitor by changing a windows system setting. You do not change how the monitors are connected to the PC. Afterwards, the other monitor is working. Did I get this correctly?

Then you say the window is initially white but works after a forced redraw. Is this always the case, so it is usable on both monitors but just initially white on one of them? Or is this part of the description about switching the primary monitor?

Following your description, I also think you are correct that this is a different white screen issue that the one in #81.

Maybe, you can try one more thing with the beta9. There are more environment variables to enable/disable specific java2d features. Can you try the following command? It should disable all other acceleration features, but not opengl.

java -jar -Dsun.java2d.d3d=false -Dsun.java2d.ddoffscreen=false -Dsun.java2d.noddraw=true amidst-v4-0-beta9.jar

from amidst.

It could well have solved acceleration issue #43, but I won't know until I get home, because the work computer that I'm on now has the white-screen issue, which beta9 didn't solve.

I tried that command, and it didn't change the white-screen issue.

The white-screen behavior I have is as follows:

• Amidst always opens on the primary monitor
• Amidst's windows are never updated when they are on the primary monitor (hence they start white)
• If I move the window to the secondary monitor, then repaints start working. However, Amidst doesn't repaint unless something changes so the window still appears white after you move it to the second monitor, until you start doing things which cause it to update its window. After that the app looks and behaves normally.
• When Amidst displays a map on the secondary monitor, it shows as 0% accelerated.
• If Amidst is displaying a map on the secondary monitor and I move it back to the primary window, the window ceases to update - I can still see the map (i.e. the window isn't white) but it's frozen displaying the last thing the window was displaying before I moved it.
• Now it gets interesting... If I move the window back to the secondary monitor, obviously it starts visibly updating again, but acceleration is 100%! However as I scroll the map and new fragments are loaded, the acceleration starts dropping. This is why I concluded acceleration is happening on the primary monitor but not the secondary - any bitmap drawn when the window is on the primary monitor goes into video ram, and remains accelerated when the window is moved back to the secondary monitor, but any bitmap introduced while the window is on the secondary monitor is unaccelerated.
• I am not swapping monitor cables, I was changing the windows settings.

Since the secondary monitor isn't accelerated and doesn't have the white-screen issue, I conclude that in this case the white-screen issue is caused by a bug in the acceleration. I'm guessing it's either the crappy card or drivers, but it might be in Java.

As best I can tell, Minecraft is 3D accelerated in both monitors. I don't have a copy of AmidstExporter here that gives acceleration information, but AmidstExporter works on both monitors. I was going to try an AmidstExporter built with Java 1.8 instead of 1.6, but I left it at home by accident.

from amidst.

heh, I was just thinking we should add a way to turn off acceleration, perhaps commandline.

Anyway, I found how to get the acceleration working, kind of... I was looking at these settings and noticed that in windows d3d is on by default, and opengl is off by default. If I comment out the line in Amidst4 that turns on opengl then Amidst4 runs fully accelerated on my VM.

The problem with this is that AmidstExporter always runs fully accelerated in that VM without needing that line commented out - I confirmed with the debugger that the line is being executed in AmidstExporter.

It seemed interesting enough to mention, but I don't know what to make of it.

from amidst.

This is indeed a good observation. How did you check whether d3d and opengl are turned on or off? Did you use the System.getProperty () method? I just merged a pull-request which is logging the java2d properties. Below, you can see the output on my Ubuntu machine. Maybe, you can post yours?

[info] Amidst v4.0-beta9
[info] Current system time: 2016-02-20 04:56:34.257
[info] System.getProperty("os.name") == 'Linux'
[info] System.getProperty("os.version") == '4.2.0-27-generic'
[info] System.getProperty("os.arch") == 'amd64'
[info] System.getProperty("java.version") == '1.8.0_72'
[info] System.getProperty("java.vendor") == 'Oracle Corporation'
[info] System.getProperty("sun.arch.data.model") == '64'
[info] System.getProperty("sun.java2d.opengl") == 'null'
[info] System.getProperty("sun.java2d.accthreshold") == 'null'
[info] System.getProperty("sun.java2d.d3d") == 'null'
[info] System.getProperty("sun.java2d.ddoffscreen") == 'null'
[info] System.getProperty("sun.java2d.noddraw") == 'null'
[info] Biome profile activated: default
[info] Graphics Acceleration: enabled
[info] System.getProperty("sun.java2d.opengl") == 'True'
[info] System.getProperty("sun.java2d.accthreshold") == '0'
OpenGL pipeline enabled for default config on screen 0
[info] using '.minecraft' directory at: '/home/stefan/.minecraft', libraries: '/home/stefan/.minecraft/libraries'
[info] using biome profiles at: 'biome'
New Default Acceleration Threshold: 0
[info] Scanning for profiles.
[info] Successfully loaded profile list.
[info] Beginning latest version list load.
[info] Attempting to download remote version list...
[info] Successfully loaded version list. URL: https://s3.amazonaws.com/Minecraft.Download/versions/versions.json

The reason why it is working for AmidstExporter is, that at the point in time when the properties are set, it is already to late for the JVM to use them: In this line, you init the look and feel to the windows look and feel. The properties are set afterwards. You have to set the properties before the look and feel, or they will have no effect. This is what I learned when I debugged the white screen issue :-P

from amidst.

And here is the output from Windows. Seems to be pretty much the same.

[info] Amidst v4.0-beta9
[info] Current system time: 2016-02-20 05:07:17.374
[info] System.getProperty("os.name") == 'Windows 8.1'
[info] System.getProperty("os.version") == '6.3'
[info] System.getProperty("os.arch") == 'amd64'
[info] System.getProperty("java.version") == '1.8.0_73'
[info] System.getProperty("java.vendor") == 'Oracle Corporation'
[info] System.getProperty("sun.arch.data.model") == '64'
[info] System.getProperty("sun.java2d.opengl") == 'null'
[info] System.getProperty("sun.java2d.accthreshold") == 'null'
[info] System.getProperty("sun.java2d.d3d") == 'null'
[info] System.getProperty("sun.java2d.ddoffscreen") == 'null'
[info] System.getProperty("sun.java2d.noddraw") == 'null'
Feb 20, 2016 5:07:17 AM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
[info] Biome profile activated: default
[info] Graphics Acceleration: enabled
[info] System.getProperty("sun.java2d.opengl") == 'True'
[info] System.getProperty("sun.java2d.accthreshold") == '0'
[info] using '.minecraft' directory at: 'C:\Users\stefan\AppData\Roaming\.minecraft', libraries: 'C:\Users\stefan\AppData\Roaming\.minecraft\libraries'
[info] using biome profiles at: 'biome'
OpenGL pipeline enabled for default config on screen 0
New Default Acceleration Threshold: 0
[info] Scanning for profiles.
[info] Successfully loaded profile list.
[info] Beginning latest version list load.
[info] Attempting to download remote version list...
[info] Successfully loaded version list. URL: https://s3.amazonaws.com/Minecraft.Download/versions/versions.json

from amidst.

I wasn't able to check the values of d3d and opengl directly, I noticed the default values stated in the documentation for Java2D System properties.

If you're sure that setting the LAF first prevents these settings from taking effect, then it sounds like it's solved: Don't set opengl to true on windows machines. But didn't you recently swap the order around? Did Amidst4 never set LAF first on Windows? [answered in next post]

Given that AmidstExporter doesn't have the white-screen issue I think this will fix that as well - it seems plausible that some low-end AMD cards provide limited OpenGL support, enough that Amidst actually becomes accelerated under opengl, but not enough OpenGL support for Amidst to work properly. Meanwhile my VM video driver presumably provides no opengl support, only d3d.

I assume Amidst4 is accelerated when I run it natively because natively this machine has a high end nvidia gaming card that should provide full opengl support.

My Amidst4 logging output is pretty much the same as yours.

[info] Amidst v4.0-beta9
[info] Current system time: 2016-02-20 16:18:48.636
[info] System.getProperty("os.name") == 'Windows 10'
[info] System.getProperty("os.version") == '10.0'
[info] System.getProperty("os.arch") == 'amd64'
[info] System.getProperty("java.version") == '1.8.0_71'
[info] System.getProperty("java.vendor") == 'Oracle Corporation'
[info] System.getProperty("sun.arch.data.model") == '64'
[info] System.getProperty("sun.java2d.opengl") == 'null'
[info] System.getProperty("sun.java2d.accthreshold") == 'null'
[info] System.getProperty("sun.java2d.d3d") == 'null'
[info] System.getProperty("sun.java2d.ddoffscreen") == 'null'
[info] System.getProperty("sun.java2d.noddraw") == 'null'
[info] Biome profile activated: default
[info] Graphics Acceleration: enabled
[info] System.getProperty("sun.java2d.opengl") == 'True'
[info] System.getProperty("sun.java2d.accthreshold") == '0'
[info] using '.minecraft' directory at: 'Z:\.minecraft', libraries: 'Z:\.minecraft\libraries'
[info] using biome profiles at: 'biome'
Could not enable OpenGL pipeline for default config on screen 0
New Default Acceleration Threshold: 0
[info] Scanning for profiles.
[info] Successfully loaded profile list.
[info] Beginning latest version list load.
[info] Attempting to download remote version list...
[warning] cannot find valid profile directory for launcher profile 'CookieMon 15w51b': C:\Users\Glenn\AppData\Roaming\.minecraft_snapshots
[warning] cannot find valid profile directory for launcher profile 'Snapshots': C:\Users\Glenn\AppData\Roaming\.minecraft_snapshots
[info] Successfully loaded version list. URL: https://s3.amazonaws.com/Minecraft.Download/versions/versions.json

I copied setAndLogProperty() into AmidstExporter, and it reports the same thing as Amidst4, so we can't assume that values read from these properties reflect whether they were set in time to have an effect.

[info] System.getProperty("sun.java2d.opengl") == 'True'
[info] System.getProperty("sun.java2d.accthreshold") == '0'
[info] Searching for biome color profiles.
[info] Beginning latest version list load.

from amidst.

Ah hah!

Amidst4 was calling initLookAndFeel() before turning on opengl, but because there was a bug in isWindows() it never actually set the LAF, so the call to turn on opengl always worked!

So now I'm satisfied the acceleration bug and the white-screen bug were caused by the opengl setting.

from amidst.

I always thought we need to enable OpenGL to enable the graphics acceleration. I did not even think about disabling it to allow another acceleration framework to do its thing. Good thing you thought about it :-)

I documented the problem, the solution and some still open questions in the pull-request. I hope we will not have to deal with this anymore. I will soon create a new release which contains the fix.

I will leave this open until you was able to test the new release on all your machines.

from amidst.

@Treer Is this issue done or do you still have performance issues?

from amidst.

It's done for me. It's fine to close it.

from amidst.

Good to hear 👍

from amidst.