On Mon, Jan 19, 2004 at 04:41:06PM +0100, Martijn Sipkema wrote: IIRC Matrox cards have a way of making a single framebuffer (with xinerama hints) that appears on two monitors. That way you should get 3d accel on both displays. - Steve

[...] Most (all?) hardware will support this (and all should). It is to be expected that a single rendering context has only one framebuffer configuration. "Consumer" hardware does not have a per pixel framebuffer configuration stored in the framebuffer together with the color (and possibly clipping) data; a rendering operation expects a single config. --ms

[...] True, this should be possible as long as the pixel format is the same; I misunderstood before, this is indeed a driver limitation. That is a problem since there is no way an application can know about this limitation and I don't think X has a way of returning "window too large" on a window config request. --ms

I know SGI hardware supports multiple pixel formats in one framebuffer, but I'm not sure it is possible to render to more than visual at a time; I doubt it. Perhaps, with a performance penalty, these very large windows could be rendered in multiple passes... --ms

On Tuesday 20 January 2004 16.53, Martijn Sipkema wrote: [...] Yes... The driver actually contains that kind of code already. It's used when rendering directly into a window (ie single buffered) that is partially covered by other windows, so that the OpenGL area becomes non-rectangular. (Seems like most drivers simply don't support single buffering in windowed mode, thus avoiding this stuff entirely.) I accidentally found out because the retrace sync is done in the wrong place. The driver ends up sync'ing once for each one of the sub rectangles that the window is split into... *hehe* //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 20 January 2004 00.34, Martijn Sipkema wrote: That's probably the problem. Maintaining multiple contexts without actual h/w support means the driver has lots of stuff to move around. Still a serious bug if the driver doesn't implement it... I can't see why it would make a difference from the h/w POV, but it could be a big difference to the driver. Still, if the driver can manage multiple contexts *at all*, it must be some obscure bug that causes it to break in the special case where some of the contexts belong to the same process. Actually, IIRC it works with *some* applications, so it's not a matter of multiple contexts per process, but rather a bug that's triggered by some unfortunate applications for reasons unknown so far. It *could* just be that the "working" applications actually use only one context, though... That would make sense for applications with custom OpenGL toolkits and OpenGL based child windows. They could still look pretty much like ordinary Windoze/GTK+/Qt/whatever apps, depending on the theme of the OpenGL toolkit. Yes. If M$ weren't punishing their users for trying to use OpenGL apps, and OpenGL support was more widely available, there wouldn't be any reason to use anything else for serious graphics - 2D or 3D. It's hard to find a card without 3D acceleration these days, though there seem to be a few Windoze-only chipets that don't have OpenGL support... //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---