Off screen Canvas3D crushes when graphics mode of the display changes

Dear colleagues,

I have discovered a strange behavior of Java3D in the Off Screen mode. I have created a program that renders a 3D scene and creates instances of the BufferedImage class in a loop. Thus, this program can be considered as a way to convert a dynamic 3D scene to the sequence of 2D images.

Here is the text of the program:
OffScreenTest5.java

Here is a screenshot of working program:


The program works well, but under special conditions it does things that can never happen. If I switch display to the text mode, it crushes in different ways. In detail, one can implement the following steps to reproduce the error:
1. I have started the Far manager in the text mode. I work under Windows XP SP3 that supports the text mode of the display still.

2. I have started a command window.
3. I have started the test program in the command window.
4. I have switched the focus of the graphic user interface to the Far manager using the Alt-Tab key.
5. The test program has crushed.

I repeated the exercise several times. The program crushes in different ways (it outputs different error messages; sometimes even JVM crushes).

Here is a screenshot:


Theoretically speaking, the Off Screen mode should not depend on the current graphic mode of the display. Thus, I consider this behavior as ``impossible’’. Please help me to discover the reason of this strange behavior of Java3D.

Here are examples of crush reports created by the program:
log01.txt
log03.txt
log06.txt

Thank you,

Alexei A. Morozov

http://www.fullvision.ru

Hi

Is it reproducible under a more recent version of Windows? There is no chance that we test under Windows XP. Please reproduce your bug under Windows 7, 8 or 10.

Hi, Julien!

Unfortunately, recent versions of Windows do not support the text mode and I have no ideas still how to switch screen to the text mode during the execution of the test. Thus, this may be the last chance to discover what is wrong in Java3D / OpenGL code. Could you please comment the log files that I have published? If additional experiments are necessary I could implement them on our computers with old versions of Windows.

Best regards,

Alexei A. Morozov

http://www.fullvision.ru

Alexei,
The log files you've attached simply show that there is no real 3D drivers available under Text Mode, and the only driver found was a software emulated OpenGL 1.1 driver, which won't work for Java3D (or anything really). So when Java3D asks for a new Frame Buffer Object (or probably any 3D operation at all) it gets told their is nothing available to support that operation.

This is exactly as expected of course, you are forcing the OS completely swap it's graphics system to a character buffer, so it's not surprising it no longer has any concept of pixels.

The only way anyone could look into this is by installing an XP virtual machine
http://www.download3k.com/articles/How-to-add-an-XP-Mode-Virtual-Machine-to-Windows-10-or-8-using-Hyper-V-00770
and seeing if it uses a real Text Mode for full screen console.

I suspect however that it will use an emulated Text Mode, by way of a real graphics driver forcing the output down to a character buffer. This would probably mean that Java3D would work fine under this environment.

So the problem is really one of return on investment, if someone spends half a day setting up this virtual machine and discovers the graphics drivers are running fine, then we can't solve your issue (as it hasn't been reproduced).

If some one sets up this environment and finds it does truly swap to Text Mode, then it's really likely that there is no way to force the OS to run the graphics driver that's needed, presumably it's totally unloaded and gone.

So what I'm saying is there really isn't a good enough reason to invest it "solving" this issue.

I'd suggest you'd be better off trying to detect the app swap situation and pause all 3D operations and restart them when context switches back to your app, or at least the right graphics mode. But to be honest I expect that all the resources will have been disposed of you and you'll have to rebuild your Java3D universe from scratch in this case.

Sorry I can't be of more help, your project certainly looks very interesting.
Phil.

Hi

I agree with Phil. I looked at your logs. The Microsoft GDI renderer supporting only OpenGL 1.1 is unable to run anything remotely useful. Java3D is a scenegraph API based on the retained mode like all frameworks and engines based on JOGL. Using OpenGL 1.1 will lead you to nowhere.

Dear Phil and Julien,

Thank you very much for your considerations!

Well, I afraid that you do not grasp the essence of my question. :) I am not surprised that Java3D do not work in the text mode. I am surprised that after the return to the previous graphics mode the OnScreen Canvas3D continues to work in a normal way, but the OffScreen Canvas3D crushes. It is strange at least. One could expect that OnScreen canvas will crush, but not OffScreen canvas. But the test demonstrates that exactly OffScreen Canvas3D crushes in this situation. What is the reason for this strange behavior, what is your opinion?

Best regards,

Alexei A. Morozov

http://www.fullvision.ru

P.S. I have implemented a workaround for the problem. I just check whether OffScreen Canvas3D isRendererRunning() and, if it is not, create a new OffScreen Canvas3D instead of previous one. This method does work, but it has the following disadvantages: (1) Sometimes JVM crushes during the test (when the display switches to the text mode and back) and I can fix this problem in no way; (2) Java3D prints a lot of error messages in stderr and I cannot switch off this output without complete rewriting all the sources of Java3D: the “silent” mode is not provided in Java3D. :) Thus, the problem under consideration opens a possibility for interference between independent programs: one program switches the display mode and another program crushes because of this.

Alexei,
You are totally right, I didn't understand the issue correctly. Please give me some time and I'll go back and consider what might be happening differently between On and Off screen with regards to  the order of operations.

Also the off-screen shouldn't be trying to re-create FBO's any more than the on-screen should. That is to say it should allocate once at the beginning and not need to reallocate whilst the OS is in Text Mode.

Thanks for clarifying that,
Phil.