Client randomly stops rendering on second monitor

[kris_hole]

I think the issue is somethign to do with my Radeon card perhaps, but i'm not 100% certain.

My setup is this:
AMD Ryzen 9 3900X 12-core 24t @3.8Ghz
64gb DDR4 Ram
Radeon 5700XT

My monitor setup is this:
1 2 3
1: 1080p @ 60hz
2: 1080p @ 144hz
3: 1080p @ 60hz

I have the latest radeon drivers installed
I'm using Java 8 Update 271


I have another pc with similar specs that uses a GTX 3070, this doesn't have this issue, the monitor setup on that pc is:
1 2
1: 1440p @ 120-hz
2: 1080p @ 60hz



I have also tried swapping out my middle (main) display for another 1080p @60hz display to rule that out and the issue still happens.

What happens is if I move my client to either screen either side of my main then it will eventually (usually within 30 seconds or so) stop rendering and will be frozen. The game does not crash, task manage is showing that it is still doing something on the CPU with GPU utilization at zero.

I have no idea how to attach a remote debugger to haven to figure out where it is stuck in an endless loop somewhere.

[loftar]

It could perhaps be related to the OpenGL context being lost. The client isn't currently great at handling that, which is also part of the reason why the full-screen mode doesn't work great. Does it work better if you start the client on one of the secondary monitors instead of moving it to them?

I have no idea how to attach a remote debugger to haven to figure out where it is stuck in an endless loop somewhere.

The easiest thing would probably be to get VisualVM and use it to get a thread dump.

[Pills]

It could perhaps be related to the OpenGL context being lost. The client isn't currently great at handling that, which is also part of the reason why the full-screen mode doesn't work great. Does it work better if you start the client on one of the secondary monitors instead of moving it to them?

I have no idea how to attach a remote debugger to haven to figure out where it is stuck in an endless loop somewhere.

The easiest thing would probably be to get VisualVM and use it to get a thread dump.

Used my old account to post the first time it appears.

I don't seem to be able to force windows 10 to open the client to a secondary screen, it always opens on whichever is marked as "main display". I'm not sure how to use visualVM with intelliJ, i've installed it and set it up but i've no idea how to use it with ant builds. If you can point me to where I go to get a thread dump I can grab that from a stalled client

[loftar]

I'm not sure how to use visualVM with intelliJ

It's not meant to be used with IntelliJ, rather it is a standalone tool. Whenever the client is running, you can simply attach to it in VisualVM.

[Pills]

I'm not sure how to use visualVM with intelliJ

It's not meant to be used with IntelliJ, rather it is a standalone tool. Whenever the client is running, you can simply attach to it in VisualVM.

Ah my bad. I've uploaded a dump of a stalled client here:

https://pastebin.com/k5jcxazE

I'm not entirely sure what i'm looking at for the most part as I haven't really worked with the haven source much, but it looks like everything is locked up waiting for at jogamp.nativewindow.windows.GDI.SwapBuffers(Native Method) perhaps?

[magisticus]

It could perhaps be related to the OpenGL context being lost. The client isn't currently great at handling that, which is also part of the reason why the full-screen mode doesn't work great. Does it work better if you start the client on one of the secondary monitors instead of moving it to them?

I have no idea how to attach a remote debugger to haven to figure out where it is stuck in an endless loop somewhere.

The easiest thing would probably be to get VisualVM and use it to get a thread dump.

Used my old account to post the first time it appears.

I don't seem to be able to force windows 10 to open the client to a secondary screen, it always opens on whichever is marked as "main display". I'm not sure how to use visualVM with intelliJ, i've installed it and set it up but i've no idea how to use it with ant builds. If you can point me to where I go to get a thread dump I can grab that from a stalled client

I suppose from what you've said you are using 'Extended Display' rather than 'Duplicated', in that mode you can change which is your primary monitor in display settings (click on icon of secondary monitor at top and then select 'make this my primary display further down the page') which might solve your problem depending on what you are trying to achieve. From my own experience, moving the client across an extended display and then using full screen will freeze the client. Unfortunately one of the annoying upgrades with windows 10 over previous versions is you can't dictate to it which monitor a program opens on, it dumps everything on the primary and you have to move it (there are I believe 3rd party applications that can get around this). This is pretty much the same with other java applications so I'd say blame microsoft rather than Loftar.

[Pills]

I suppose from what you've said...

The problem is that I can't just move the client as I like, literally just moving it to any display other than the one which is my main causes the client to stall and stop updating. Which means if I suddenly decide I want to do literally anything else on my main screen and have the game on my second I simply can't.

It doesn't always stall straight away, but its always within 30seconds of moving it to any other display on this pc causes it to lock up

[magisticus]

Maybe try disabling direct 3D, not sure how much that would bugger with Haven but worth a try and you can always undo:

Open Java Configuration Panel

Select Java Tab
View
Double Click in Runtime Parameters and add the following

-Dsun.java2d.d3d=false

Click OK and then apply
If no joy delete the parameter

(note OpenGl built on top of DirectX for windows)

[loftar]

Code: Select all

"AWT-EventQueue-0" #27 prio=6 os_prio=0 cpu=19390.63ms elapsed=45.59s tid=0x000001921e11a000 nid=0x428 runnable  [0x00000087308fc000]
   java.lang.Thread.State: RUNNABLE
        at jogamp.nativewindow.windows.GDI.SwapBuffers(Native Method)


That's interesting. I had expected this to be related to the fullscreen mode problems, but according to your stacktrace, it seems to be stuck in buffer swapping. I'm not immediately sure what that would happen, but I'm getting vibes of an OpenGL driver bug. Perhaps there is some upgrade/downgrade/options that you could try?

[Pills]

Code: Select all

"AWT-EventQueue-0" #27 prio=6 os_prio=0 cpu=19390.63ms elapsed=45.59s tid=0x000001921e11a000 nid=0x428 runnable  [0x00000087308fc000]
   java.lang.Thread.State: RUNNABLE
        at jogamp.nativewindow.windows.GDI.SwapBuffers(Native Method)


That's interesting. I had expected this to be related to the fullscreen mode problems, but according to your stacktrace, it seems to be stuck in buffer swapping. I'm not immediately sure what that would happen, but I'm getting vibes of an OpenGL driver bug. Perhaps there is some upgrade/downgrade/options that you could try?

I've tried doing some digging but it looks like this probably is just a bug with AMD's openGL drivers. Nvidia ones don't follow the specs and do all sorts of funky stuff where as AMD's follow it to a tee. The problem is probably that the specs aren't fit for purpose anymore or maybe the newer drivers break some of the older stuff?

My drivers say full support for OpenGL 4.6 so maybe that breaks something with older OpenGL 3 applications? Who knows. Either way it doesn't look like its something I can fix easily and I don't particularly want to spend the entire weekend installing older drivers for the card to see if it ever worked