search

eivindveg / HotSUploader

JavaFX-based Replay Uploader for Heroes of the Storm
Apache License 2.0
185 stars 36 forks source link

[WIN] Performance degradation with multiple open applications #98

Open cgriff32 opened 8 years ago

cgriff32 commented 8 years ago

As the title states. The uploader stays open as a background task even after closing with the x. This wouldn't be a big deal as it's not really a process hog, but it does make videos and gifs skip whenever it checks for new replays.

Windows 10 Newest version

zhedar commented 8 years ago

That's intended behaviour, you can close the program via the system tray. There must be an icon, which you may rightclick on, if I'm correct.
However that second thing sounds suspicious... what exactly do you mean by making videos and gifs skip?

cgriff32 commented 8 years ago

It's almost like the CPU is being bogged down at consistent intervals. so if a video is playing the video playback will stutter slightly and resume. Audio is not affected. Same thing with Gifs, in which they will stutter slightly. I'll test it tomorrow and give you the timing. The problem is solved by ending the program with task manager.

zhedar commented 8 years ago

Actually, if the program is idle, it is currently not blocking efficiently. It's using some busy wait, but that shouldn't really use a lot of CPU cycles...

I already fixed this, but we didn't publish it with 2.0.1 yet. However it will be part of the 2.1. release. Maybe we can test this by running a current snaphot, which contains these fixes.

The busy wait in this scenario happens every 2 seconds, is that the interval it hangs?

cgriff32 commented 8 years ago

Alright, so poking around a bit more to recreate the problem. It hangs at about every 2 seconds, but only when two or more instances of the program are running in the background.

When closing with the x on Windows 10, the program does not go to the taskbar. So when I click the x it is removed from the taskbar, but the background task persists. Opening it again will cause the hang ups.

Sorry for not fleshing out the details earlier.

zhedar commented 8 years ago

The fact, that it does't go back into the taskbar is intended as well, but it should be minimized into the system tray (normally in the lower righthand side of the screen) instead. That's where you can redisplay or close it properly via it's context menu. Can you see it's icon in there? It may be hidden though, I'm not sure about W10's tray behaviour.

Two or more instances really shouldn't run, but if the busy wait may cause these problems, we may include the fix in 2.0.2, what do you think @eivindveg ? Atleast if there will be an 2.0.2 before 2.1.

eivindveg commented 8 years ago

For the delays, I'd like to know a bit more about your computer. Even with my aging laptop I notice no adverse behaviour when the application is open an idle.

As for the system tray, it really should be located in the bottom right hand corner. It's not an active tray icon like the WiFi or Volume controls, but likely hidden alongside Java update notifications, anti-virus, bluetooth, etc.

eivindveg commented 8 years ago

Also, as far as singleton-application goes, I have some ideas I want to test for 2.1

cgriff32 commented 8 years ago

I see the icon in the system tray now, it was being hidden immediately.

For my computer specs: Core i7 920 12 GB Ram 64bit Windows 10 GTX 570

It's a fairly fresh install of Windows 10 (< 1 month) and the stuttering is ended after having <2 instances open. It seems it was mostly user error in opening the program more than once. Maybe having it bring the currently running instance back rather than opening again may help?

Thanks for the help guys, super quick responses.

eivindveg commented 8 years ago

The problem was probably entirely the lack of multi-run prevention. I'll make sure a framework for this gets in for 2.1. It's very possible the two different processes were locking to the same file.

zhedar commented 8 years ago

We may be able to provide a lightweight solution by adding a socket based solution, which can bring the application back up. Webstart's javax.jnlp.SingleInstanceService may also be ok, but I'm not familiar with Webstart yet and don't know, if it's deployable easily. However this isn't an issue for OSX, since bringing the application back up, when already started is the default action (that's quite nice actually).

eivindveg commented 8 years ago

I'm reluctant to implement sockets in a bundled-runtime application. This would open our applications more up to Java's potential vulnerabilities, meaning we'd have to start updating the application builds on new Java releases. It may be the only way to force a bring-up without using pipes.

eivindveg commented 8 years ago

And I haven't even checked if you can use pipes in Java, let alone Windows.

zhedar commented 8 years ago

PipedInputStream works quite well, already ran that on Windows. Although I don't think that Sockets are a real security vulnerability, if used correctly, I understand that bad feeling. Opening an application always feels bad, but pipes could bear the same risks. Maybe there's a better non-code solution.

rogusdev commented 8 years ago

Using a file in a system tmp dir for locking would probably be better. There are also examples of that approach on the stackoverflow page that @zhedar linked to above.