Fullscreen (focus?) problems in 1.6 [update: and with 1.7.2]

[xDan]

(sorry this is not necessarily an actual bug report, but still this forum seems the most appropriate)

I'm using Irrlicht 1.6 and for various reasons upgrading to a newer version is not an option.

The problem I'm having is in Linux, sometimes when starting my game, the video mode will change, but I will not see my app and the desktop will remain visible and everything will freeze. (but I will still hear audio from my game playing, and can interact with it using the mouse + keys, so it seems it is not totally crashed, just the focus has gone off to some strange other dimension). The only way to get out of this is to switch to another virtual terminal then switch back, and sometimes that fixes it, or otherwise I have to quit the game - either by randomly clicking around until I find the game's Exit button, or by killing the process from the other terminal.

Also, at least once I've got a very similar problem in Windows! The screen mode changes, but I can't see my app (instead I see my web browser or whatever else is open at the wrong resolution). This is easily remedied by pressing the windows button to minimise, and then clicking the app in the taskbar restores it to full screen and all works.

In both Linux and Windows I haven't found the problem to be repeatable on demand...

Now my question is..... are these problems known and have they been fixed in a newer version of Irrlicht?

And if so, can anyone point me to the actual revision where these were fixed? So I can apply the fixes to my Irrlicht 1.6.

(I do see two possibilities in the changelog:
"Fix problem that the window did sometimes not get the keyboard focus in X11 in fullscreen"
"Fullscreen handling has been enhanced for Windows, now proper resolution is restored on Alt-Tab etc. "
...but I'm not certain if they are exact fixes for this problem or not. It seems to me my app DOES get the keyboard focus, just somehow the window is not brought to the front...)

[CuteAlien]

I think at least the Linux problem was the bug that was fixed in r3056 (but 3055 should also be installed). But that's still in the 1.6 branch - although not sure if it's in the official release or got changed later. But can't you update at least to a newer 1.6? Then it would be fixed.

I don't remember the problem in Windows. I know there had been some bugs in windowed mode when the resolution was larger than the one which was available from the desktop, but don't remember a problem in fullscreen.

[xDan]

Oops, sorry, this is actually 1.6.1 I am using. I forgot I upgraded So it seems it cannot be that bug.

I'll try the latest version and see if I can reproduce it with the example apps...

[xDan]

*bump*

I've finally got around to looking at this again. And I've managed to reproduce the problem on 1.7.2, in the example apps. So the problem still seems to be there, and is not in my own code.

See the example below. I have encountered the problem using that exact code. It's quite rare though, it seems random and not easily reproducible.

Also you can reproduce the *effect* of the problem by commenting out smgr->drawAll. (try it in the example). So possibly the problem is in drawAll then. I'm having a poke around myself in the drawall source to see what I can find but I'm not expecting to solve the problem...

EDIT: actually, commenting out drawAll doesn't seem to reproduce the problem... I don't know what's going on, it seemed to produce it at one point but now it's not doing it any more... uhg, it really is random.

(note this is on Linux, I'm not sure if it's related to the similar problem I had on windows. I haven't tested disabling drawAll there yet)

Code: Select all

#include <irrlicht.h>

#include <iostream>



using namespace irr;



// can reproduce what the problem looks like by disabling smgr->drawAll



int main()

{

	IrrlichtDevice *device =

		createDevice(video::EDT_OPENGL, core::dimension2d<u32>(1024,768), 32, true);



	video::IVideoDriver* driver = device->getVideoDriver();

	scene::ISceneManager* smgr = device->getSceneManager();



	device->getFileSystem()->addZipFileArchive("../../media/map-20kdm2.pk3");

	scene::IAnimatedMesh* mesh = smgr->getMesh("20kdm2.bsp");

	scene::ISceneNode* node = 0;



	if (mesh)

		node = smgr->addOctreeSceneNode(mesh->getMesh(0), 0, -1, 1024);

	

	if (node)

		node->setPosition(core::vector3df(-1300,-144,-1249));



	smgr->addCameraSceneNodeFPS();



	device->getCursorControl()->setVisible(false);



       // we halt after 4 seconds in case the screen froze up
	while(device->run() && device->getTimer()->getTime() < 4000)

	{

		driver->beginScene(true, true, video::SColor(255,200,200,200));

		smgr->drawAll();

		driver->endScene();

	}



	device->drop();

	return 0;

}

[xDan]

Unless I speak too soon, it seems to me commenting out
glXSwapBuffers(X11Display, Drawable);
in COpenGLDriver::endScene causes a similar effect...

Are there any situations glXSwapBuffers could fail and thus be causing my problem?

I notice some glX docs say glXSwapBuffers can give some errors, but I'm unfamiliar with X11 and cannot figure out how you are supposed to detect the errors. (since glXSwapBuffers returns void and I can't find any glXGetError type function...) Can anyone help?

Probably it's completely unrelated to the bug but I'm lost for other ideas.

Errors
GLXBadDrawable is generated if drawable is not a valid GLX drawable.
GLXBadCurrentWindow is generated if dpy and drawable are
respectively the display and drawable associated with the current
context of the calling thread, and drawable identifies a window that
is no longer valid.

[agamemnus]

Quick question: is your program full screen size the same as your OS (ie: Windows) screen size?

[xDan]

No, though actually this problem has occurred in windowed mode too... (and the window just freezes and no rendering occurs)... Yet input still works (i.e. I can move the mouse + select menu items in my game), just rendering has frozen.

and this is only on Linux, I think the Windows problem I had may be unrelated.

Other Linux users of my game have reported this problem too, so it's not just some glitch on my system.

It's just proving so hard to debug since it never occurs when I want it to... I can go for tens of launches and it works fine, it's just occasionally... :S

[agamemnus]

Try to log the screen size of your program right before it freezes. I think it may have something to do with this bug.

[CuteAlien]

I know the problem from the past, but can't seem to reproduce it currently. Is there any interesting console output when this happens?

[hybrid]

If some glx error would occur, it is output to console.

[xDan]

No, nothing unusual on the console.

Another note, I think alt+tabbing away and then back again fixed the problem when it occurred when in windowed mode. (I can't 100% state that is true though due to not being able to reproduce it right now)

@agamemnus, I'll try that tomorrow, thanks.

[xDan]

Ok ok ok. The following procedure is currently reproducing the bug for me - or at least a bug that appears similar...

Can anyone please confirm this does indeed reproduce the bug for them?

(try it a few times - at least once it *hasn't* reproduced the effect, but most of the time it seems to)

Using this script:

Code: Select all

#!/bin/sh

./02.Quake3Map &
nautilus

Or even just this command:

Code: Select all

./02.Quake3Map & nautilus

(to run the Irrlicht example in the background, then launch another app in front of it.)

And this exact code for the Irrlicht program (note that it makes use of isWindowActive, for this reproduction of the bug it doesn't seem to appear if isWindowActive test is not there... despite me encountering the bug when not using isWindowActive as in the last example code I posted):

Code: Select all

#include <irrlicht.h>

#include <iostream>



using namespace irr;


int main()

{

	core::stringc t;

	t += (int)time(NULL);

	

	core::stringc stdoutFile = core::stringc("stdout")+t+".txt";

	core::stringc stderrFile = core::stringc("stderr")+t+".txt";

	

	freopen(stdoutFile.c_str(),"w",stdout);

	freopen(stderrFile.c_str(),"w",stderr);

	

	SIrrlichtCreationParameters params;

	params.DriverType = video::EDT_OPENGL;

	params.Bits = 32;

	params.Fullscreen = true;

	//params.Doublebuffer = false;

	params.WindowSize = core::dimension2d<u32>(1024,768);

	

	IrrlichtDevice *device = createDeviceEx(params);

	

	

	//IrrlichtDevice *device =

	//	createDevice(video::EDT_OPENGL, core::dimension2d<u32>(1024,768), 32, true);



	video::IVideoDriver* driver = device->getVideoDriver();

	scene::ISceneManager* smgr = device->getSceneManager();



	device->getFileSystem()->addZipFileArchive("../../media/map-20kdm2.pk3");

	scene::IAnimatedMesh* mesh = smgr->getMesh("20kdm2.bsp");

	scene::ISceneNode* node = 0;



	if (mesh)

		node = smgr->addOctreeSceneNode(mesh->getMesh(0), 0, -1, 1024);

	

	if (node)

		node->setPosition(core::vector3df(-1300,-144,-1249));



	smgr->addCameraSceneNodeFPS();

	device->getCursorControl()->setVisible(false); 



	printf("Begin...\n");



	while(device->run() && device->getTimer()->getTime() < 4000)

	{

		core::dimension2du screenSize = driver->getScreenSize();

		

		if (screenSize.Width != 1024 || screenSize.Height != 768)

			printf("***** SCREEN SIZE INCORRECT: %i,%i\n", screenSize.Width,screenSize.Height);

		

		if (device->isWindowActive())

		{

			driver->beginScene(true, true, video::SColor(255,200,200,200));

			smgr->drawAll();

			driver->endScene();

		}

		else

			device->yield();

	}



	device->drop();

	

	printf("Finished successfully.\n");

	

	return 0;

}

so I wonder if the problem is some other app wants focus or something but Irrlicht is not relinquishing it properly???

It appears that an X11 FocusOut event is generated with the procedure above, that does not appear normally:

Begin...
XEvent: MapNotify (type 19) (time 1368)
XEvent: Expose (type 12) (time 1368)
XEvent: FocusIn (type 9) (time 1368)
XEvent: MotionNotify (type 6) (time 1368)
XEvent: FocusOut (type 10) (time 1368)
switchToFullscreen reset = true
Finished successfully.

Though I'm not certain that a FocusOut was generated in other random occurrences of the problem when not using this test situation.

I'm also not certain that this is a reproduction of the same bug I've encountered before, I only know that the appearance when running it full screen is the same...

[agamemnus]

Or perhaps something was fired in the incorrect order.

[CuteAlien]

And you still have the original problem? That the desktop is still visible?

When using your trick with starting another application behind it I can reproduce that I don't get the focus. But I must admit I don't really know what the correct focus behaviour would be for an application started in the background when another is started afterward. But I still see the example-render and not the desktop background. Just focus is messed up.

[xDan]

> And you still have the original problem? That the desktop is still visible?

yes

> But I must admit I don't really know what the correct focus behaviour would be for an application started in the background when another is started afterward

Assuming that X11 is choosing to give the focus to the other app... then I would assume the correct behaviour is for the Irrlicht app to minimise itself and restore the original resolution [or is X11 supposed to do that and is failing to? or maybe full screen apps should never be affected in such a way!?]. I tried doing this myself in response to the XFocusOut event but couldn't get it to work. (using Irrlicht's minimize method, also the method that restores the original screen mode. I could get the screen mode to be restored but the app would not minimise and everything still remained frozen until it exited)

Sorry though, I really don't know much about this stuff at all, I'm completely unfamiliar with X11 and Linux. So I'm probably talking nonsense.

Unless someone else knows more about all this I'll look into using the SDL device and see if that works better...