[OpenJDK 2D-Dev] Question regarding GraphicsConfiguration/DisplayMode
Dmitri Trembovetski
Dmitri.Trembovetski at Sun.COM
Tue Mar 31 21:27:15 UTC 2009
Hi Roman,
Roman Kennke wrote:
>> 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
That's the thing. GC doesn't represent a screen, virtual or otherwise. It
represents one of several possible (color model-related) configurations of a
GraphicsDevice, which represents a screen.
So you could create a Window using one of those graphics configurations, and
it will happen to be on the same screen the configuration belongs to.
> 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...
In an ideal world we wouldn't have had bounds in GCs. The GC represent
different visuals, nothing to do with screens' geometry.
>> 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.
Yes.
>>> 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.
>> 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.
I see. Indeed, this situation wasn't foreseen.
Thanks,
Dmitri
>>> 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
>
>
More information about the 2d-dev
mailing list