You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <li...@pbw.id.au> on 2004/12/26 02:13:46 UTC
GraphicsEnvironment, GraphicsDevice and Graphics2D
Jeremias or Thomas in particular, help!
I'm having trouble working out the relationships between the various
parts of Java2D, especially as regards the bits named above. At the end
of the day, the Graphics2D-GraphicsDevice combination is central to the
2D rendering process.
One instantiates a BufferedImage without specifically referring to any
elements of the GraphicsEnvironment, as for example in
PDFGraphicsConfiguration:
class PDFGraphicsConfiguration extends GraphicsConfiguration {
// We use this to get a good colormodel..
private static final BufferedImage BI_WITH_ALPHA =
new BufferedImage(1, 1, BufferedImage.TYPE_INT_ARGB);
// We use this to get a good colormodel..
private static final BufferedImage BI_WITHOUT_ALPHA =
new BufferedImage(1, 1, BufferedImage.TYPE_INT_RGB);
...
}
From the instance of BufferedImage, we can get a Graphics2D instance:
BufferedImage bufim = new
BufferedImage(1,1,BufferedImage.TYPE_INT_ARGB);
Graphics2D g2D = bufim.createGraphics();
From the Graphics2D, we get a GraphicsConfiguration and a
FontRenderContext:
GraphicsConfiguration grconf = g2D.getDeviceConfiguration();
FontRenderContext frc = g2D.getFontRenderContext();
The GraphicsConfiguration gets us back to the GraphicsDevice:
GraphicsDevice grdev = getDevice();
The GraphicsDevice won't take us back to its GraphicsEnvironment.
The implication of all of this, for me, is that a BufferedImage is not
created ex nihilo, but out of an understood context of GEnv, GDev and GConf.
GraphicsEnvironment provides a static method for retrieving the
underlying GraphicsEnvironment:
GraphicsEnvironment grenv =
GraphicsEnvironment.getLocalGraphicsEnvironment()
Given a GraphicsEnvironment and a BufferedImage, we can go the other way.
BufferedImage bufim = new
BufferedImage(1,1,BufferedImage.TYPE_INT_ARGB);
Graphics2D g2D = grenv.createGraphics(bufim);
All of which seems redundant, given that we can get to a Graphics2d
directly from a BufferedImage. I assume, though, that this is the way
to introduce a "foreign" GraphicsEnvironment, e.g.,
PDFGraphicsEnvironment. Is this a fair assessment?
What puzzles me is the circularity of requiring a BufferedImage, with
its implicit dependency upon getLocalGraphicsEnvironment(), which seems
to be the only way to directly discover a GraphicsEnvironment. It's as
though there is no formal way to introduce your own GraphicsDevices,
apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf
through the reliance on BufferedImage.
What am I missing?
Peter
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 28.12.2004 11:54:10 Peter B. West wrote:
> Jeremias Maerki wrote:
> > On 28.12.2004 02:26:51 Peter B. West wrote:
> > <snip/>
> >
> >>Did you find the reference to java.awt.graphicsenv in PJA?
> >
> >
> > Just downloaded PJA. There's no reference in PJA other than in the
> > javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the
> > developer has to make sure that the system property is set (as could be
> > expected). It's interesting to note that PJA subclasses
> > SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are
> > dependent on Sun-private classes.
> >
> So I saw. It's only for PJAGraphicsEnvironment. Where do the
> Sun-private classes come from?
From the JDK/JRE (rt.jar).
> Where else have you seen a reference to java.awt.graphicsenv?
Nowhere else in PJA.
Jeremias Maerki
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Posted by "Peter B. West" <li...@pbw.id.au>.
Jeremias Maerki wrote:
> On 28.12.2004 02:26:51 Peter B. West wrote:
> <snip/>
>
>>Did you find the reference to java.awt.graphicsenv in PJA?
>
>
> Just downloaded PJA. There's no reference in PJA other than in the
> javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the
> developer has to make sure that the system property is set (as could be
> expected). It's interesting to note that PJA subclasses
> SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are
> dependent on Sun-private classes.
>
So I saw. It's only for PJAGraphicsEnvironment. Where do the
Sun-private classes come from?
Where else have you seen a reference to java.awt.graphicsenv?
Peter
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 28.12.2004 02:26:51 Peter B. West wrote:
<snip/>
> Did you find the reference to java.awt.graphicsenv in PJA?
Just downloaded PJA. There's no reference in PJA other than in the
javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the
developer has to make sure that the system property is set (as could be
expected). It's interesting to note that PJA subclasses
SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are
dependent on Sun-private classes.
> >>What am I missing?
> >
> >
> > I don't know. What are you trying to do? Is this about changing font
> > support for the PDFGraphics2D? Knowing that I might have some better
> > ideas.
>
> I'm just trying to understand what I'm doing when I fiddle with GEnv and
> GDev. When I first looked at using Java2D methods for all rendering, I
> concluded that the GraphicsEnvironment was "closed", because there
> seemed to be no independent pathway to the creation of a modified
> GraphicsEnvironment. That's why I was so excited when SVGGraphics2D was
> mentioned on fop-dev. Looking at the implementation, though, I see that
> the same problems exist. I don't know quite how to express my disquiet
> about this, but in PJA's terms, it amounts to the implicit dependency on
> the underlying native graphics rendering.
> <q>
> java.awt.Graphics methods such as drawLine (), fillOval (), drawString
> (),... are implemented in the default JVM with native graphical
> functions (except in some cases for Java2D) : That means that drawLine
> () finally calls a GDI system function on Windows or X11 function on a
> X11/UNIX machine even if the drawing is done in an off-screen image
> using the class java.awt.Image. This ensures the best performance for
> drawing graphics with Java.
> </q>
I can see nothing disturbing in here. I still think there's no need to
replace the default GraphicsEnvironment because you would have to start
doing the same thing PJA has to do to support BufferedImage etc.
> > Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get
> > a better understanding of what is involved in the whole thing.
>
> I just took a glance at PJA. I'll have a look at the 2D implementation
> code. PJA seems to have gone right back to the root of
> GraphicsEnvironment and built its own from scratch.
Except that they built upon Sun-private classes.
> However,
> <q>
> Starting with release J2SETM 5.0, AWT has been re-implemented on the
> Solaris and Linux platforms. The new Toolkit implementation provides the
> following advantages:
>
> * Removes the dependency on Motif and Xt libraries.
> * Interoperates better with other GUI Toolkits.
> * Provides better performance and quality.
> </q>
> I'll ask eTeks what the implications of this are for PJA.
Jeremias Maerki
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Posted by "Peter B. West" <li...@pbw.id.au>.
Jeremias Maerki wrote:
> (not a real specialist in this area but...)
>
> On 26.12.2004 02:13:46 Peter B. West wrote:
> <snip/>
...
>
>>What puzzles me is the circularity of requiring a BufferedImage, with
>>its implicit dependency upon getLocalGraphicsEnvironment(), which seems
>>to be the only way to directly discover a GraphicsEnvironment. It's as
>>though there is no formal way to introduce your own GraphicsDevices,
>>apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf
>>through the reliance on BufferedImage.
>
>
> Yes, I think there's no such thing, although I don't think it's
> necessary. The PDFGraphicsConfiguration and PDFGraphicsDevice is all
> that's necessary to support Graphics2D output to PDF. And PDFGraphics2D
> instantiates the PDFGraphicsConfiguration as necessary. If you want to
> replace the default GraphicsEnvironment you'd probably set the
> "java.awt.graphicsenv" system property accordingly. But that's most
> probably not something you will want to do as it has consequences on the
> whole AWT subsystem in normal operations.
>
Did you find the reference to java.awt.graphicsenv in PJA?
>
>>What am I missing?
>
>
> I don't know. What are you trying to do? Is this about changing font
> support for the PDFGraphics2D? Knowing that I might have some better
> ideas.
I'm just trying to understand what I'm doing when I fiddle with GEnv and
GDev. When I first looked at using Java2D methods for all rendering, I
concluded that the GraphicsEnvironment was "closed", because there
seemed to be no independent pathway to the creation of a modified
GraphicsEnvironment. That's why I was so excited when SVGGraphics2D was
mentioned on fop-dev. Looking at the implementation, though, I see that
the same problems exist. I don't know quite how to express my disquiet
about this, but in PJA's terms, it amounts to the implicit dependency on
the underlying native graphics rendering.
<q>
java.awt.Graphics methods such as drawLine (), fillOval (), drawString
(),... are implemented in the default JVM with native graphical
functions (except in some cases for Java2D) : That means that drawLine
() finally calls a GDI system function on Windows or X11 function on a
X11/UNIX machine even if the drawing is done in an off-screen image
using the class java.awt.Image. This ensures the best performance for
drawing graphics with Java.
</q>
> Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get
> a better understanding of what is involved in the whole thing.
I just took a glance at PJA. I'll have a look at the 2D implementation
code. PJA seems to have gone right back to the root of
GraphicsEnvironment and built its own from scratch.
However,
<q>
Starting with release J2SETM 5.0, AWT has been re-implemented on the
Solaris and Linux platforms. The new Toolkit implementation provides the
following advantages:
* Removes the dependency on Motif and Xt libraries.
* Interoperates better with other GUI Toolkits.
* Provides better performance and quality.
</q>
I'll ask eTeks what the implications of this are for PJA.
Peter
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Posted by Jeremias Maerki <de...@greenmail.ch>.
(not a real specialist in this area but...)
On 26.12.2004 02:13:46 Peter B. West wrote:
<snip/>
> All of which seems redundant, given that we can get to a Graphics2d
> directly from a BufferedImage. I assume, though, that this is the way
> to introduce a "foreign" GraphicsEnvironment, e.g.,
> PDFGraphicsEnvironment. Is this a fair assessment?
<fx type="serious-head-scratching"/>
IMO for BufferedImage you don't need any foreign GraphicsEnvironment.
I wouldn't care what GraphicsEnvironment class is used for a
BufferedImage.
> What puzzles me is the circularity of requiring a BufferedImage, with
> its implicit dependency upon getLocalGraphicsEnvironment(), which seems
> to be the only way to directly discover a GraphicsEnvironment. It's as
> though there is no formal way to introduce your own GraphicsDevices,
> apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf
> through the reliance on BufferedImage.
Yes, I think there's no such thing, although I don't think it's
necessary. The PDFGraphicsConfiguration and PDFGraphicsDevice is all
that's necessary to support Graphics2D output to PDF. And PDFGraphics2D
instantiates the PDFGraphicsConfiguration as necessary. If you want to
replace the default GraphicsEnvironment you'd probably set the
"java.awt.graphicsenv" system property accordingly. But that's most
probably not something you will want to do as it has consequences on the
whole AWT subsystem in normal operations.
> What am I missing?
I don't know. What are you trying to do? Is this about changing font
support for the PDFGraphics2D? Knowing that I might have some better
ideas.
Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get
a better understanding of what is involved in the whole thing.
Jeremias Maerki