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 represent
FYI, the join miter patch seems to have gone in:
http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9318628e8eee
but probably the other patches didn't. I also would like to see these
patches go into openjdk soon.
Thanks,
Hiroshi
On Thu, Mar 26, 2009 at 7:16 AM, Roman Kennke wrote:
> Hi,
>
> Is it poss
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
Hi Roman,
Roman Kennke wrote:
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.
Basically, GD represents a real graphics device - like a video board on
windows, and screen on X11 (w/o xin
Hi,
I think my mental model regarding the GD/GC/DisplayMode API is a bit
messed up, or the API is a bit messed up.
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,
