Hi Dmitri, > > I think my mental model regarding the GD/GC/DisplayMode API is a bit > > messed up, or the API is a bit messed up. > > It's the API that's a bit messed up.
Phew. ;-) > Basically, GD represents a real graphics device - like a video board on > windows, and screen on X11 (w/o xinerama). If your video board has two > outputs, > depending on the settings GD may represent the board, or each of the outputs > - > "physical screens". Ok, good. > GCs represent Visuals on X11, and pixel formats on Windows. > > It makes a little less sense on Windows as there Pixel Formats are only > relevant for creating windows that work well with OpenGL so that third party > applications can use HWNDs from AWT windows for rendering OpenGL content. > > For d3d (and somewhat confusingly, for the built-in opengl pipeline) > we have one single GraphicsConfiguration. > > This doesn't explain some methods that crept up into this class (like > getBounds and getNormalizingTransform). They should have been on > GraphicsDevice. Why? Isn't getBounds() used to indicate which part of the whole virtual screen (Xinerama) a GC is representing? At least, this is what the API docs tell me. I suppose in the ideal world we'd need getBounds() in both the GD (the bounds of the whole virtual screen) and the GC (the bounds of the sub-screen). Ok, in an ideal world, Xinerama would be represented by a different class then GC I suppose... > So suppose you have an X11 system with single board with two screens (no > xinerama), 32 bit IntBgr default visual, and the board is capable of > simultaneously displaying a 8-bit grayscale visual windows. > > But also imagine that this system supports changing display nodes to 16 > bit > (I hope you have good imagination!), and different resolutions. > > Then you'll have two GD with two GC each (32-bit Bgr and 8-bit GrayScale). > > The DisplayMode[] will have entries for 32 and 16 bit modes, and whatever > different resolutions you have. Ok, this makes sense. So in my case, where I can display windows only in one color model simultanously (and no Xinerama of course on this poor embedded box), I'd only return one GC at any time. Good. > > So far I was always assuming that the GCs (as returned by > > GD.getGraphicsConfigurations()) represent all the possible settings > > (resolution, color model, etc) that the GD can use. BUT, then we also > > This was an incorrect assumption. I see. > > have GD.getDisplayModes(). And GC is also used for Xinerama support, > > right? So what does GC represent? I am implementing on an embedded > > platform right now, I only have one screen, but a couple of different > > settings, and would like to know what is correct here. Is there a > > relationship between the list of display modes and the list of GCs? If > > No. List of display modes is the list of possible display modes the > graphics > device can be switched to. That includes different resolutions, as well as > bit > depths. (see below for more) Ok, so this is what I assumed the GCs are for. Good to know. > > so, how are color models in DisplayMode handled? I only see a bitDepth > > property there, but for example how to differenciate between a RGB565 > > and RGB556 setup in the DisplayMode API? > > DisplayMode for a device represents the desktop resolution and (where > applicable) the bit depth. > > It makes less sense if your device can display windows with different bit > depths simultaneously so there isn't one "desktop bit depth", which is why > there's DisplayMode.BIT_DEPTH_MULTI to indicate that case. I think I mean something different. Suppose your graphics board is capable of using 2 different resolutions (1024x768 and 800x600) in two different color modes (RGB565 and RGB556) (not simultanously). This would make 4 DMs. The problem I see is that bitDepth is not expressive enough to differentiate between RGB565 and RGB556, both use 16 bits. > > Then: what is the default configuration? Is it just some random > > This is tricky. > > In _most_ cases it corresponds to the screen's default visual / pixel > format. > > Except for the cases where the default visual is say 8-bit, but there's a > 32-bit visual available. This happens on older SunOS systems with CDE where > the > default visual is 8 bit. There are Sun adapters for sparc which can display > windows with different bit depths (and palettes, and gamma correction) > simultaneously. Ok, I guess when I only ever have one GC (see above) that's easy now :-) > > What is (and how to use) GD.getBestConfiguration()? The > > GraphicsConfigTemplate class seems pretty useless to me. > > It is. =) I'm not sure anyone uses this stuff. Haha, good. :-) Thanks a lot for clearing this up Dmitri. Oh, it means I have to rework lots of code. THANKS! ;-) /Roman
