Fullscreen and Linux once again...

Java 2D
#1

Hi all,

I tried to use fullscreen mode with jdk 6 b104 on a Fedora Core 6 Linux thinking that with the nice improvements sun mades in fullscreen support on Linux it would roll easily.
So I was a little disappointed seeing that my application (and a small test borrowed on the internet ) was displayed in fullscreen BUT below the window manager task bar. :’( :’( :’(

I browsed a little, found some relevant supposed corrected bug in the database…
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6364134
It talks about a _NET_WM_FULLSCREEN thing but it sounds to me like a way to do the trick in jdk source code…

I am missing something (high probability here I guess) or is there a little regression in java 6 ?
Did someone experienced this kind of trouble?

Thanks for any help or hint.

PS : I know that I can hide the taskbar but that not really a good solution for me, sorry :wink:

#2

Sigh. Fullscreen in JDK 6 was working great on all the Linux distros we tried. The whole point of the _NET_WM_FULLSCREEN hint is to allow the WM to determine how/when to place a fullscreen window over the taskbar, so if the WM isn’t honoring that hint, there’s not much we can do. There may have been some change in FC6 that causes the problem you’re seeing. Please file a bug report at bugs.sun.com, and include your fullscreen testcase as well as any other details that might be helpful.

Chris

#3

Hi,
Thanks for the tips chris, I’m going to narrow down a small test case to provide and fill a bug…
But if it’s due to the WM I’ll try the task bar hiding trick… not a good solution as I said but a solution nevertheless.

Thanks again.

#4

Hello,
Trying to send a small test case as a bug I found something interresting.
If I forget to call setResizable( false ) on the JFrame going to be “fullscreened” it do appears on top of the task bar.
BUT if the JFrame is not resizable it appears below the task bar.
In the fullscreen tutorial, it’s strongly recommended to use unresizable frames…

So, I’ll try to fill a bug report with these remarks.

#5

This is most likely a problem with your windowmanager and not with java…

lg Clemens

#6

Well, yes i though so but what is strange is that the behaviour changes depending on resizable property. Not a big deal but it should not should it?

#7

Well if you window-manager is doing the wrong thing if the window is resizeable … theres not a lot that can be done.
Either you can work arround (as you did) or better the window manager should been fixed…

lg Clemens

#8

Let’s wait till the bug report is filed before we jump to any conclusions. I’ll need to do some testing on FC6 and see if the WM is behaving differently than other releases; it may just be that we’d want to workaround this case on the JDK side.

Chris

#9

Hi, I filled the bug report yesterday and it was accepted today.
The bug id was sent to my work so I’ll update this post with this id when I go back to the office.

Thanks Chris for your future investigations.

EDIT : Here is the bug number (not already present on the web site, but will be soon) :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500686

#10

Just FYI: I’ve seen issues with fullscreen mode on Windows if
resizing is disabled on the fullscreen frame. Especially if
the frame is first show on the screen, and later used
as full screen window.

So I would suggest not to disable resizing.

Dmitri

#11

The following code worked fine for me in Java 5. I just installed Java 6, and the task bar flickers on the screen. If I click on the task bar (which minimizes the program) and then restore the program, it works fine. I’m using Windows and have not tried my code on any other Operating System.

I’ve tried not calling setResizable, and I’ve fiddled around with it a bit. But nothing seems to help.

	//determine the display mode
	DisplayMode displayMode = new DisplayMode(width, height, colorDepth,
		DisplayMode.REFRESH_RATE_UNKNOWN);
	
	//create the full screen JFrame
	GraphicsDevice device = GraphicsEnvironment.
		getLocalGraphicsEnvironment().getDefaultScreenDevice();
	GameFrame gameFrame = new GameFrame(device.getDefaultConfiguration());
	gameFrame.setResizable(false);
	gameFrame.setUndecorated(true);

	//initialize fullscreen mode
	device.setFullScreenWindow(gameFrame);
	if(device.isDisplayChangeSupported()) {
		try {
			device.setDisplayMode(displayMode);
		} catch(IllegalArgumentException exception) {
			//Java emulates the unsupported full screen mode
		}
	
		//required for mac os x
		gameFrame.setSize(width, height);
	} else { //else the display couldn't be changed
		ErrorLog.output(ErrorList.fullScreenGameFrameScreenModeNotSupported);
		System.exit(0);
	} //end else the display couldn't be changed
	
	//disable "input methods"
	gameFrame.enableInputMethods(false);
	
	//regular GameFrame stuff
	gameFrame.initializeBufferStrategy();

P.S. Class GameFrame is just an extended JFrame with a few extra methods (such as initializeBufferStrategy).

#12

The code looks fine to me, so this must be a bug (I would still remove the setResizable(false)).

Also, if you’re using fullscreen/active rendering (especially for games) I would
not use swing components, just awt.

Also, try running with -Dsun.java2d.d3d=false , see if it helps.

Thanks,
Dmitri

#13

Forgot that I posted this. :frowning:

I figured out that it wasn’t a problem with the code I posted. It was from a line of code that I had elsewhere from when the game was in a window instead of full-screen. I called “pack” on the main JFrame after all the Swing components were added, and removing that stopped the problem. Since it resizes a Window, it makes sense that it shouldn’t be called on a full-screen exclusive mode window.

I had thought that the problem was with my class that went FSEM mode because I moved it into another program, which caused the same problem. But that program was calling pack on the main frame too.

I believe it only started occurring after I refactored a custom component I made, though it wasn’t immediately apparent. I also see no reason why changing how two classes pass events around has any relation to the pack method.

Out of curiosity, what’s the problem with Swing components? They seem to work fine in FSEM to me.

#14

OK, glad that the mystery was solved.

Out of curiosity, what’s the problem with Swing components? They seem to work fine in FSEM to me.

They do, it’s just that they have their own back-buffer, and updating mechanism, and they
pull a lot of classes, so unless you really need them, I’d use awt.

Thanks,
Dmitri