-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Low framerate and high CPU usage #43
Comments
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. |
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:
Place this in the class
with
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 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. |
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) |
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. |
@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. |
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. |
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) |
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. |
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
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. |
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:
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:
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. |
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). |
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:
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.
|
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:
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. |
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. |
This is indeed a good observation. How did you check whether d3d and opengl are turned on or off? Did you use the
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 |
And here is the output from Windows. Seems to be pretty much the same.
|
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. 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.
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.
|
Ah hah! Amidst4 was calling So now I'm satisfied the acceleration bug and the white-screen bug were caused by the opengl setting. |
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. |
@Treer Is this issue done or do you still have performance issues? |
It's done for me. It's fine to close it. |
Good to hear 👍 |
If I run the original amidst and make it full screen, it sits at 50fps using little CPU.
If I run Amidst4 and make it full screen, it sits at about 25fps using full CPU.
(I believe Amidst is limited to 50fps, and obviously the Amidst4 framerate will depend on the computer you run it on - mine is a virtual machine running on an old underpowered computer, which makes the difference noticeable. FWIW the VM supports hardware graphics acceleration)
The text was updated successfully, but these errors were encountered: