Full screen dual monitors, How ?

Started by
3 comments, last by haegarr 17 years, 5 months ago
Hello everyone. I have a problem working full screen on a Dual monitor ATI (X600) setup. I am using GLUT, if I try to set the resolution to 2048x768 I get a non-fullscreen window. With nVideo cards there is an option to create a giant 2048x768 desktop (this is not the normal "extend my desktop" option) I could not find a way to do this with ATI cards. Ideas ? What is the standard procedure with rendering to a dual monitor setup ? thanks ! Shachar Weis.
Advertisement
I don't know how it really is (it depends on your OS and driver implementation), but these are my thoughts ...

I would be careful with using 3D graphics rendering splitted by a screen boundary at all. In principle one cannot guarantee that any 3D graphics API functionality is constantly available over 2 gfx cards (unless you restrict the funtionality to the common minimum). Although this might be handled less restrictive on a single card with dual heads. It may happen that the driver will switch back to software rendering if the surface crosses screen boundaries.

Moreover, GLUT is more a cross platform solution invented for test and demo purposes. Don't expect it being a full featured framework for every thinkable use case.

IMHO, the best solution (at least in the sense of portability) is to work with 2 full-screens sharing a single context and scene, of course. Set-up the VIEW matrix and ViewPort accordingly to which side you're currently rendering.
I want to use a single dual-head card, I don't need to support dual-cards.
How do you share a single context with two fullscreen windows ?
Is there an example somewhere ?
I am unable to find any examples or documentation on this subject.

Thanks !
On my system, I can in general "simply" open a window on the primary display and make it wide enough, so it fills both screens. It's the graphic card's problem to make something of it.

However, be warned: As haegarr already pointed out, you're walking on thin ice. You have no guarantees that this works, and no way of knowing if/when it will work (and when something is running in hardware or software).
Dual monitor setup is a nasty driver hack which mostly works, but it may as well bite you in the rear.
For example, on my card, hardware video acceleration doesn't work properly in that context. With hardware acceleration enabled (which generally makes sense, of course), a video on *either* screen shows just fine, but if I split a window between screens or if I have one window on the primary, and another on the secondary screen, the part on the secondary screen shows all black!
With software decoding, I can split a video between screens, and both pieces show nicely -- but it's running entirely on the CPU of course.

Similar things could happen to anything you draw in OpenGL, and you have no way to know.

Also, you need to be aware that two desktops do not necessarily have the same dimensions or be aligned left-right. You can very well configure 1280x1024 on one display (a normal 19'' TFT, for example) and 800x600 on another (your good old, venerable CRT). Unless you are writing something that is supposed to *never* run on anybody else's PC, you are in trouble here, as you don't know what configuration someone else might have.
The driver will somehow arrange everything so the desktop shows on both monitors and you can drag things from one to the other, but you cannot simply assume that you can make your window twice as wide and twice as tall... in that case, part of your window will be invisible.

Finding the displayable area is certainly possible, but it is a pain in the rear to get it to work in a semi-reliable way, let's not even talk about portability (under X, it's still more painful than under Windows).
Quote:Original post by ShacharWeis
How do you share a single context with two fullscreen windows ?

In general, sharing contexts is possible by overhanding an existing context to the creation routine for another context. Contexts are OS dependently supported by WGL (win32), GLX (linux), AGL (Mac OS X), and so on. Wrapper libraries may provide a way, too. Unfortunately, GLUT _seems me_ to not provide access to the contexts, and hence I don't know how to do (if anyhow possible) the job under GLUT, sorry.

Perhaps a GLUT freak can tell you more. I personally have dropped the use of GLUT years ago due to its many restrictions if it comes to extra-ordinary use cases (and that happens earlier or later, as you can see).

This topic is closed to new replies.

Advertisement