|
Re: ANN: article "Java 2D imaging for the Standard Widget Toolkit" [message #437289 is a reply to message #437282] |
Wed, 02 June 2004 16:13 |
No real name Messages: 30 Registered: July 2009 |
Member |
|
|
Yannick,
Nice article.
The only problem I see with your approach is that a new SWT Image is being
created every time the AWT image is redrawn. In an animated application
this would probably be too slow.
Have you taken a look at Christophe Avare's "Java2D for SWT" package,
available from www.holongate.org? It's framework is a little more
sophisticated than your Graphics2DRenderer (but much harder to explain in
an article, so I think you took the right approach), but the main
difference
is that, when available, it uses a native method to transfer pixels from
the
AWT image to the SWT image, which foregoes the need to create a new SWT
image each time. Unfortunately this native accelaration is only available
on a couple of platforms.
What we really need is for the SWT library to provide a native
implementation
of your transferPixels method. On Windows this can be implemented via the
SetDIBitsToDevice function, but I don't know if it's possible on other
platforms.
Cheers,
Alun
Yannick Saillet wrote:
> This article explains how to use Java 2D routines in SWT or Draw2D painting
> operations. It also explains how to convert an AWT BufferedImage to an SWT
> image.
> http://www-106.ibm.com/developerworks/java/library/j-2dswt/
> Yannick
|
|
|
Re: ANN: article "Java 2D imaging for the Standard Widget Toolkit" [message #437363 is a reply to message #437289] |
Thu, 03 June 2004 11:43 |
Yannick Saillet Messages: 24 Registered: July 2009 |
Junior Member |
|
|
Hi Alun,
thanks for your comment.
Yes I know of holongate solution and I agree that the technique presented in
my article may not be the most performant in animation.
The reason why I originally developped this simple technique is that I
needed a rotated fonts in GEF figures. For this kind of problem (no
animation and reduced clipping region), the performance was sufficient and
the solution was much more flexible than depending on a foreign plugin.
For heavy large size animations I would probably have chosen another
approach as well.
But the first purpose of the article is education and in particular to
explain how to convert an image between the AWT and SWT words, and how the
AWT/SWT methods work to transfer the pixels. (Methods like getRGB(...) are
not very well documented, so that you have to try a lot before you find out
how they work). That's what I've tried to bring in the article.
Yannick
Alun Evans wrote:
>
> Yannick,
>
> Nice article.
>
> The only problem I see with your approach is that a new SWT Image is being
> created every time the AWT image is redrawn. In an animated application
> this would probably be too slow.
>
> Have you taken a look at Christophe Avare's "Java2D for SWT" package,
> available from www.holongate.org? It's framework is a little more
> sophisticated than your Graphics2DRenderer (but much harder to explain in
> an article, so I think you took the right approach), but the main
> difference
> is that, when available, it uses a native method to transfer pixels from
> the
> AWT image to the SWT image, which foregoes the need to create a new SWT
> image each time. Unfortunately this native accelaration is only available
> on a couple of platforms.
>
> What we really need is for the SWT library to provide a native
> implementation
> of your transferPixels method. On Windows this can be implemented via the
> SetDIBitsToDevice function, but I don't know if it's possible on other
> platforms.
>
> Cheers,
>
> Alun
>
>
> Yannick Saillet wrote:
>
>> This article explains how to use Java 2D routines in SWT or Draw2D
>> painting operations. It also explains how to convert an AWT BufferedImage
>> to an SWT image.
>
>> http://www-106.ibm.com/developerworks/java/library/j-2dswt/
>
>> Yannick
|
|
|
Re: ANN: article "Java 2D imaging for the Standard Widget Toolkit" [message #437411 is a reply to message #437363] |
Thu, 03 June 2004 22:51 |
No real name Messages: 30 Registered: July 2009 |
Member |
|
|
Yannick,
I agree completely - the approach you took in the article was absolutely
correct. I just wanted to make sure you were aware of the holongate work,
and I certainly didn't mean to sound critical.
Cheers,
Alun
Yannick Saillet wrote:
> Hi Alun,
> thanks for your comment.
> Yes I know of holongate solution and I agree that the technique presented in
> my article may not be the most performant in animation.
> The reason why I originally developped this simple technique is that I
> needed a rotated fonts in GEF figures. For this kind of problem (no
> animation and reduced clipping region), the performance was sufficient and
> the solution was much more flexible than depending on a foreign plugin.
> For heavy large size animations I would probably have chosen another
> approach as well.
> But the first purpose of the article is education and in particular to
> explain how to convert an image between the AWT and SWT words, and how the
> AWT/SWT methods work to transfer the pixels. (Methods like getRGB(...) are
> not very well documented, so that you have to try a lot before you find out
> how they work). That's what I've tried to bring in the article.
> Yannick
> Alun Evans wrote:
> >
> > Yannick,
> >
> > Nice article.
> >
> > The only problem I see with your approach is that a new SWT Image is being
> > created every time the AWT image is redrawn. In an animated application
> > this would probably be too slow.
> >
> > Have you taken a look at Christophe Avare's "Java2D for SWT" package,
> > available from www.holongate.org? It's framework is a little more
> > sophisticated than your Graphics2DRenderer (but much harder to explain in
> > an article, so I think you took the right approach), but the main
> > difference
> > is that, when available, it uses a native method to transfer pixels from
> > the
> > AWT image to the SWT image, which foregoes the need to create a new SWT
> > image each time. Unfortunately this native accelaration is only available
> > on a couple of platforms.
> >
> > What we really need is for the SWT library to provide a native
> > implementation
> > of your transferPixels method. On Windows this can be implemented via the
> > SetDIBitsToDevice function, but I don't know if it's possible on other
> > platforms.
> >
> > Cheers,
> >
> > Alun
> >
> >
> > Yannick Saillet wrote:
> >
> >> This article explains how to use Java 2D routines in SWT or Draw2D
> >> painting operations. It also explains how to convert an AWT BufferedImage
> >> to an SWT image.
> >
> >> http://www-106.ibm.com/developerworks/java/library/j-2dswt/
> >
> >> Yannick
|
|
|
|
Powered by
FUDForum. Page generated in 0.03055 seconds