Slow and choppy zooming in/out of logs

[lagos]

I have two laptops:

One is an older Thinkpad x60s with an Intel Dual Core 1.66ghz with 2 gigs of ram and a mechanical hard drive running Linux Mint.
The other is a much newer ultrabook with an I5 processor, 4 gigs of ram and an SSD drive running windows 10.

On the newer Windows machine there is a lot of lag when zooming in and out of log files, especially when the zoom level is around 0.01x. The application becomes unresponsive and it can take 10 seconds or more to zoom back in. The whole thing just feels slow and choppy regardless of what log file I am looking at.

None of these issues exist on the older Linux machine. Everything is very snappy and I can zoom all the way out of a log and back into it with perfect smoothness.

Any ideas on how to fix this?

[LT401Vette]

It sounds like there is some type of exception occurring...

Can you post / send the MegaLogViewerMSLogFile.txt file in the dir:

[YourUserHome]/.efiAnalytics/

[lagos]

MegaLogViewerHDLogFile.txt

[lagos]

MegaLogViewerHDLogFileNEW.txt

Here is a cleaner log. I deleted the old log and let the program generate a fresh log where I loaded up two data logs and did some zooming in/out in both.

[LT401Vette]

Hmm, I don't see any issue in that log file.

Is it just zooming in and out that it lags, or overall laggy?

[lagos]

Zooming in and out and also trying to do anything with the log zoomed out is extremely slow. Once you zoom into it, the performance is acceptable.

[LT401Vette]

How big of a log?
Is if fully loading the log?

I'm assuming if you are zoomed out to a 0.01, it must be a big log.
I didn't see any Exceptions/Errors in those log files though..

[lagos]

Its a 40meg file, and yes its fully loaded.
I loaded up the same file on my Windows 10 Desktop (i5, 16 gigs of ram) and had zero issues.

Here is the log from the desktop for comparison.

MegaLogViewerHDLogFileDesktop.txt

[lagos]

I loaded up a Linux distro from a usb drive onto the i5 ultrabook. MLV ran flawlessly under Linux, so something is going on with the windows side of things on this machine.

Is there hardware acceleration being used to render the log? Is it possible that things are falling back to a slower software render on the windows side?

[LT401Vette]

Is there hardware acceleration being used to render the log? Is it possible that things are falling back to a slower software render on the windows side?

There is, but just the default java, by default on windows it uses directx, on linux it uses OpenGL.

I have other reasons to try forcing OpenGL on windows, I will put an option to try that in the next release.

I'm assuming that machine does have the proper video drivers in?
Doe TS work fine on it? That is much more graphics intensive.

[lagos]

Yes all of the drivers are installed and up to date. Tunerstudio seems to run just fine.

Is there a way to check that directX is being used in java or a way to force enable it?

[lagos]

I think I figured out whats causing the problem.

This laptop has a hiDPI display with a 3200x1800 native resolution. Since some apps dont support hiDPI, I run it at 1920x1080. In windows this resolution recommends that I set the text scaling to 150%. This is whats causing the slowdown in MLV.

I set the text scaling to 100% @ 1920x1080 and logged out/in. Then I opened up my log in MLV and it worked perfectly. While the log was open I changed the scaling back to 150%. The applications interface scaled up just fine and performance was still good. Then I closed the application and logged out of windows. Logged back in and launched MLV again and the poor performance returned.

[lagos]

I did some more testing....

At 3200x1800 with 100% resolution scaling (almost impossible to see anything on the desktop!), the performance of MLV was just fine. I then set the resolution scaling to 300% and relaunched MLV. All of the text in the application was zoomed in and a bit grainy, but the performance was still good. Then i signed in/out of windows and launched MLV again. This time the text in the application was clear, but the performance was poor.

I tried using compatibility settings to disable hiDPI scaling, but this did nothing to fix the problem.

So basically this is an issue with how MLV handles resolution scaling under windows.

[LT401Vette]

Thanks for figuring out the cause...

The current versions of MLV support hiDPI. That was like herding cats, I had to go through every place in the app that any size was set and make sure it scales for the DPI. But I have not tried running on my high DPI laptop while it was in 1080P and scaled to 100% I used to have to do that before MLV and TS supported Hi DPI, but now it is always using the default scaling and resolution.

You are using the regular installer of MLV with the bundled 1.8 JRE?
The 1.9 JRE has started to finally try compensating for HiDPI, but doesn't work with MLV as you get double compensation and it seems to make things blocky when I tried it last. It seemed to be scaling up the screen, not the font size, so while it made things big enough to see, it didn't take advantage of the hi res. My own handling scales up every font and image individually.

It seems TS would suffer the slow down much worse.

I will try changing resolutions and see if I can reproduce.

[lagos]

I will try changing resolutions and see if I can reproduce.

Make sure that you are not only changing resolution, but changing the interface scaling slider. Thats really more of the issue than the resolution itself.

[LT401Vette]

I'm not reproducing it here, but I have a different machine. For HiDPI testing I am using a Lenovo Carbon X1 with 2560x1440 resolution, so not so extreme as your 3200x1800.
It sounds like a an issue with scaling in the video driver. But I'm not sure why it seems related to MLV.

[lagos]

I'm not reproducing it here, but I have a different machine. For HiDPI testing I am using a Lenovo Carbon X1 with 2560x1440 resolution, so not so extreme as your 3200x1800.
It sounds like a an issue with scaling in the video driver. But I'm not sure why it seems related to MLV.

Make sure you log out of windows after each setting change.

Could it be caused by the fact that you are scaling things in your code AND java is trying to do its own scaling based on the settings in windows causing the graphs to render too many times?

Is there a way to ignore HiDPI scaling just in the graph windows and then set a custom smaller resolution resolution of those with a higher font and higher line width?

[lagos]

I just tried JRE 1.9, and had the same experience as you did. Everything was too big and I wasn't even able to see the log graph.

[LT401Vette]

I think I am reproducing it when using the settings you have above: 1920x1080 with 150%.
I needed to use a bigger log file.

Normally in 1920x1080 I don't have it scaled up as everything is already big... 150% is what I normally use at 2560x1440.

So at 1920x1080 at 100% it seems fine, 2560x1440 at 150% seems fine, but 1920x1080 at 150% doesn't seem happy at all with a big log.

[lagos]

Really glad you are able to reproduce it!