Nabble - Sun - Java2D-Interest

Re: Text anti-aliasing settings/Changing LAF

2008-11-17T14:41:57Z

> Hopefully, JDK 7 will remove
> the bundled rasterizer(s), deprecate the existing
> rendering hints (in addition to the desktop property)
> and make them no-ops and start using native text
> rasterization exclusively based on the current
> settings of the user desktop environment.
Well, if it would be that simple ;)
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=317149

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: area.subtract and antialias problem

2008-11-17T11:51:48Z

Since both shapes are being rendered with an opaque color, why not just
render shape1 followed by shape3?

The problem you are running into with antialiasing is a common one and
it is due to the fact that the two operations work independently to fill
C (for fraction of coverage) of the pixel and then again to fill (1.0-C)
of the pixel. Geometrically you can see that the two operations should
be filling wholly separate parts of the pixel and so the new coverage
should be a full 1.0, but the operations are done in isolation and so
filling C of the pixel in the first operation leaves it C filled and
(1.0-C) remaining from the original background color. The second
operation then comes along and fills against the blended color and ends
up leaving some of the background still showing:

bg = original background color
c1 = color of first fill operation
ci = intermediate color after first fill operation
c2 = color of second fill operation
cf = final color
C = coverage of first shape
1-C = coverage of second, subtracted shape

First operation (fills the pixel with coverage C):

ci = C * c1 + (1-C) * bg

Second operation (fills again with coverage 1-C):

cf = (1-C) * c2 + (1-(1-C)) * ci
= (1-C) * c2 + C * ci
= (1-C) * c2 + C * C * c1 + C * (1-C) * bg

If the coverage was 0.5 then the background should still be contributing
to 0.25 of the color of the pixel. Note also that the first color is
also only contributing to 0.25 of the pixel and the second color is the
only one with a proper contribution at 0.5 of the pixel.

The only workarounds are:

- Render the entire scene non-antialiased at a higher resolution and
then use image subsampling in stages on the fully rendered image to
downsample while blending to create a "full scene antialiasing" technique

- Render a fringe around the second operation so that it fully bleeds
into its border pixels and then render the first operation on top of it
so that it correctly replaces exactly the "C" portion of the pixel and
leaves the remaining "1-C" portion set to the second color. (Someone
already suggested this technique here, but I am adding a little to it by
saying that it works better if you perform the second fill first with
its fringe and then have the first fill done in AA mode on top of it.)

Hope that helps!

...jim

davood wrote:

> Hi,
>
> In my application I'm creating new shape (Area) by subtracting a shape from
> another one but when I turn on the antialias in rendering I face with a
> white border around inner object. I'm not using composite because I need to
> create the shape by subtracting. Is there any solution for this problem?
> Here is a sample code,
>
> private void drawTest(Graphics2D g2) {
> g2.setColor(Color.WHITE);
> g2.fillRect(0, 0, getWidth(), getHeight());
>
> Ellipse2D shape1 = new Ellipse2D.Double(150, 185, 150, 60);
>
> Shape shape3 = new Rectangle2D.Double(100, 100, 250, 250);
> Area area = new Area(shape3);
> area.subtract(new Area(shape1));
>
> g2.setColor(new Color(86 / 256f, 114 / 256f, 142 / 256f, 1f));
> g2.fill(area);
>
> g2.setColor(new Color(86 / 256f, 144 / 256f, 182 / 256f, 1f));
> g2.fill(shape1);
> }
>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Text anti-aliasing settings/Changing LAF

2008-11-17T11:15:46Z

> Depending on the order in which I
> instantiate Swing components

This should only depend on the look-and-feel. This functionality is available under Metal (and all its derivatives), GTK and Windows look-and-feels. Third-party LAFs that extend Basic do not have this functionality built in unless they do some (completely unnecessary - see below) coding.

>
> 1. It's sufficient to get anti-aliased text to put
> [code]
> Toolkit.getDefaultToolkit().getDesktopProperty("awt.fon
> t.desktophints");
> [/code]
> before any other code. It's also sufficient to
> instantiate a JFrame before setting the Windows look
> and feel.

Post a complete (<100 lines) test app that illustrates your issue.

> 2. When the anti-aliased text is shown correctly,
> the system's UIDefaults contains an
> AATextInfoPropertyKey entry. When it's not shown, it
> doesn't.

I have addressed this issue before [1]. I had a quite unproductive discussion on the "free rides" that Metal, Windows and GTK look-and-feels get by their "virtue" of being core look-and-feels as far as the desktop AA settings go. You can see the discussion at [2] and the RFE that i filed at [3]. This discussion has not led to where i hoped it would (where the third-party look-and-feels extending Basic would get the same functionality as the third-party look-and-feels extending Metal). So i had to resort to injecting the hint installation myself.

In my opinion, the whole thing about exposing API to set the text rasterization hints is unnecessary. Java2D should use the native rasterizer on *all* platforms for all text rasterization APIs. This is partially done in 6u10 on Windows when the awt.font.desktophints property is used as mentioned in the original links. Hopefully, JDK 7 will remove the bundled rasterizer(s), deprecate the existing rendering hints (in addition to the desktop property) and make them no-ops and start using native text rasterization exclusively based on the current settings of the user desktop environment.

Kirill

[1] http://forums.java.net/jive/thread.jspa?threadID=46948
[2] http://www.javalobby.org/java/forums/t87243.html?start=0
[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6506298
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=317118

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Text anti-aliasing settings/Changing LAF

2008-11-17T10:44:03Z

I'm having issues with the anti-aliasing of text in Java 6. Depending on the order in which I instantiate Swing components, change look and feel (to getSystemLookAndFeelClassName, in this case WindowsLookAndFeel), what have you, I'm getting either aliased (bad) or anti-aliased (good) text in my menus, buttons, etc.

I'm still sorting through some of the order, but I'd appreciate if anyone had pointers on how to look. Key findings so far:

1. It's sufficient to get anti-aliased text to put
[code]
Toolkit.getDefaultToolkit().getDesktopProperty("awt.font.desktophints");
[/code]
before any other code. It's also sufficient to instantiate a JFrame before setting the Windows look and feel.

2. When the anti-aliased text is shown correctly, the system's UIDefaults contains an AATextInfoPropertyKey entry. When it's not shown, it doesn't.

Thanks much for any leads,
Michael
[Message sent by forum member 'kazoobrewer' (kazoobrewer)]

http://forums.java.net/jive/thread.jspa?messageID=317105

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Substance slows down app

2008-11-17T06:05:54Z

Thanks Again,

I left an update to the issue regarding JOGL and how a certain setting seems to affect the CPU utilization under certain conditions.
I also left a message with the JOGL group asking for advice.

I changed the title for this thread to better rpresent the issue.

Thanks,
-Tony
[Message sent by forum member 'tdanecito' (tdanecito)]

http://forums.java.net/jive/thread.jspa?messageID=317054

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Substance slows down app

2008-11-16T16:11:56Z

As with any other java.net based project, you first need to request an Observer role before being able to post to the project forums.

Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=317011

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Substance slows down app

2008-11-16T12:00:26Z

Thanks Kirillcool.

Sorry, the Substance forum I discovered does not allow posting even though I can sign in. I did enter in as a bug and I have an idea what it is now and left my thoughts about it in the bug detailed description.
After I work around the issue I will update the bug entry.

-Tony
[Message sent by forum member 'tdanecito' (tdanecito)]

http://forums.java.net/jive/thread.jspa?messageID=317003

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Substance slows down app

2008-11-16T09:51:18Z

> I am using Substance 5.0 and notice sometimes it
> throws the following exception and eventually my app
> slows down very slowly. This does not happen without
> Substance. Despite what the exceptions says the app
> is using it.

Please post a simple (<100 lines) test application that reproduces this exception to Substance forums or bug tracker. The Java2D list is hardly the right place to discuss project-specific exceptions.

About the performance issues - same as above. If this is only specific to Substance, please continue the discussion on the project forums or mailing lists.

Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=316994

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Substance slows down app

2008-11-16T09:15:34Z

Hi All,

I am using Substance 5.0 and notice sometimes it throws the following exception and eventually my app slows down very slowly. This does not happen without Substance. Despite what the exceptions says the app is using it.

Please any help appreciated.

-Tony

Exception in thread "AWT-EventQueue-1" java.lang.IllegalStateException: Substance delegate used when Substance is not the current LAF
at org.jvnet.substance.utils.SubstanceColorSchemeUtilities.getColorScheme(SubstanceColorSchemeUtilities.java:298)
at org.jvnet.substance.SubstanceCheckBoxUI.getIcon(SubstanceCheckBoxUI.java:189)
at org.jvnet.substance.SubstanceCheckBoxUI.getDefaultIcon(SubstanceCheckBoxUI.java:250)
at javax.swing.plaf.basic.BasicRadioButtonUI.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at Jlib.GenericAWT.ComponentTitledBorder.getBorderInsets(Unknown Source)
at javax.swing.JComponent.getInsets(Unknown Source)
at java.awt.GridBagLayout.ArrangeGrid(Unknown Source)
at java.awt.GridBagLayout.arrangeGrid(Unknown Source)
at java.awt.GridBagLayout.layoutContainer(Unknown Source)
at java.awt.Container.layout(Unknown Source)
at java.awt.Container.doLayout(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validate(Unknown Source)
at javax.swing.RepaintManager.validateInvalidComponents(Unknown Source)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
[Message sent by forum member 'tdanecito' (tdanecito)]

http://forums.java.net/jive/thread.jspa?messageID=316992

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: area.subtract and antialias problem

2008-11-16T01:01:54Z

Hi davood,

You may fill the gap by a draw operation that slightly overlaps the inner and outer area.

[code]
import java.awt.BasicStroke;
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.Shape;
import java.awt.geom.Area;
import java.awt.geom.Ellipse2D;
import java.awt.geom.Rectangle2D;

import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;

public class AreaTest extends JComponent {

private static final long serialVersionUID = 1L;

public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {

@Override
public void run() {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.add(new AreaTest(false), BorderLayout.LINE_START);
frame.add(new AreaTest(true), BorderLayout.LINE_END);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
}

private final boolean antiAlias;

public AreaTest(boolean antiAlias) {
this.antiAlias = antiAlias;
}

@Override
public Dimension getPreferredSize() {
return new Dimension(270, 270);
}

private void drawTest(Graphics2D g2) {
System.out.println("Drawing " + getBounds());
g2.setColor(Color.WHITE);

g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
antiAlias ? RenderingHints.VALUE_ANTIALIAS_ON
: RenderingHints.VALUE_ANTIALIAS_OFF);

g2.fillRect(0, 0, getWidth(), getHeight());

Ellipse2D shape1 = new Ellipse2D.Double(50, 85, 150, 60);

Shape shape3 = new Rectangle2D.Double(10, 10, 250, 250);
Area area = new Area(shape3);
area.subtract(new Area(shape1));

g2.setColor(new Color(86 / 256f, 114 / 256f, 142 / 256f, 1f));
g2.fill(area);

g2.setColor(new Color(86 / 256f, 144 / 256f, 182 / 256f, 1f));
g2.fill(shape1);

// fill the white gap by overlapping it
g2.setStroke(new BasicStroke(2f));
g2.draw(shape1);
}

@Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
drawTest((Graphics2D) g);
}

}
[/code]

Piet
[Message sent by forum member 'pietblok' (pietblok)]

http://forums.java.net/jive/thread.jspa?messageID=316968

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

area.subtract and antialias problem

2008-11-15T23:03:00Z

Hi,

In my application I'm creating new shape (Area) by subtracting a shape from another one but when I turn on the antialias in rendering I face with a white border around inner object. I'm not using composite because I need to create the shape by subtracting. Is there any solution for this problem?
Here is a sample code,

private void drawTest(Graphics2D g2) {
g2.setColor(Color.WHITE);
g2.fillRect(0, 0, getWidth(), getHeight());

Ellipse2D shape1 = new Ellipse2D.Double(150, 185, 150, 60);

Shape shape3 = new Rectangle2D.Double(100, 100, 250, 250);
Area area = new Area(shape3);
area.subtract(new Area(shape1));

g2.setColor(new Color(86 / 256f, 114 / 256f, 142 / 256f, 1f));
g2.fill(area);

g2.setColor(new Color(86 / 256f, 144 / 256f, 182 / 256f, 1f));
g2.fill(shape1);
}

Re: DocPrintJob doesn' work with Zebra printer

2008-11-13T02:46:16Z

Hello

did your resolved this problem?

how?

thanks

regards
[Message sent by forum member 'pjmorce' (pjmorce)]

http://forums.java.net/jive/thread.jspa?messageID=316510

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: testing, please ignore

2008-11-12T13:04:42Z

replying from the forum
[Message sent by forum member 'jdinkins' (jdinkins)]

http://forums.java.net/jive/thread.jspa?messageID=316401

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

testing, please ignore

2008-11-12T12:46:32Z

Attempting to get the forum<->mail list gateway working again.

jeff

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Availability of PhotoComposite API with hardware accelaration

2008-10-08T02:05:13Z

Hi Vince,

I know this is probably not what you are looking for (and it certainly
isn't hardware accelerated). Oh, and you proably already knew about
it.. But given the lack of response on this topic, I'll post it
anyway. ;-)

Romain Guy did some work on advanced blending modes for photo
compositing. You can find it here:
http://www.curious-creature.org/2006/09/20/new-blendings-modes-for-java2d/

Best regards,

.k

On 3. okt.. 2008, at 17.39, java2d@... wrote:

> Hi everyone,
>
> I am looking periodically at the status of RFE 6541868 (Synopsis
> RFE: hardware acceleration for advanced blending modes (aka
> PhotoComposite) ) and other related RFEs.
> With all the progress made within java 6 update 10 about the
> Direct3D and OpenGL pipelines, I was wondering when we could expect
> to see the hardware-accelerated PhotoComposite API.
> Now that java GUI can benefit by default from these pipelines, it
> would be seriously cool to be able to bring more advanced blending
> effects than the current Porter-Duff rules implementation in the
> AlphaComposite API.
>
> Does any of you guys have news on this ?
>
> Cheers.
>
> Vince.
> [Message sent by forum member 'vync79' (vync79)]
>
> http://forums.java.net/jive/thread.jspa?messageID=303194
>
> =
> =
> =
> =
> =
> ======================================================================
> To unsubscribe, send email to listserv@... and include in
> the body
> of the message "signoff JAVA2D-INTEREST". For general help, send
> email to
> listserv@... and include in the body of the message "help".

Re: Is there an optimized way to draw shapes with a gradient stroke ?

2008-10-06T13:00:31Z

Hi Jim,

thanks for your answer. That is what I thought... however I was still hoping someone would know some trick I am not aware of.

I think it would be an interesting graphical feature to be able to draw with some custom brush. For sure we can do without it, but it would be nice to have.
[Message sent by forum member 'vync79' (vync79)]

http://forums.java.net/jive/thread.jspa?messageID=303589

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Is there an optimized way to draw shapes with a gradient stroke ?

2008-10-06T11:00:31Z

Unfortunately the Stroke interface in 2D is defined as just a geometric
effect - it can turn a Path into an "outline to fill", but cannot
specify any color properties for the result. As a result, there would
be no "custom Stroke implementation" you could use to achieve this
result and I can't think of any better ways of doing it than what you
did short of writing your own rendering function(s)...

...jim

java2d@... wrote:

> Hi,
>
> in my application, I need to draw a shape with Graphics2D methods where the Stroke used is not a uniform color but instead some kind of gradient from solid color to semi-transparent color with a given thickness.
>
> The current way I am dealing with this is to draw the shape several times, each time with wider and more transparent stroke. This way I pretty much achieve the effect I wanted. However, this operation has to happen around 40 times per sec on quite a lot of shapes... I would like to know if there is a faster way I am not aware of that could do this in one single drawing path.
> In other word, is there a kind of GradientStroke that could be used as argument for the Graphics2D.setStroke() method.
>
> Regards.
>
> Vince
> [Message sent by forum member 'vync79' (vync79)]
>
> http://forums.java.net/jive/thread.jspa?messageID=303211
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@... and include in the body of the message "help".

Re: Simple printing example that raises many questions.

2008-10-04T00:55:21Z

Hi Robross, did you find a solution for this? I'm facing similar issues when trying to print using the Print API - the margins seem to be something not in our control!
[Message sent by forum member 'manudewan' (manudewan)]

http://forums.java.net/jive/thread.jspa?messageID=303317

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Is there an optimized way to draw shapes with a gradient stroke ?

2008-10-03T09:00:56Z

Hi,

in my application, I need to draw a shape with Graphics2D methods where the Stroke used is not a uniform color but instead some kind of gradient from solid color to semi-transparent color with a given thickness.

The current way I am dealing with this is to draw the shape several times, each time with wider and more transparent stroke. This way I pretty much achieve the effect I wanted. However, this operation has to happen around 40 times per sec on quite a lot of shapes... I would like to know if there is a faster way I am not aware of that could do this in one single drawing path.
In other word, is there a kind of GradientStroke that could be used as argument for the Graphics2D.setStroke() method.

Regards.

Vince
[Message sent by forum member 'vync79' (vync79)]

http://forums.java.net/jive/thread.jspa?messageID=303211

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Availability of PhotoComposite API with hardware accelaration

2008-10-03T08:39:00Z

Hi everyone,

I am looking periodically at the status of RFE 6541868 (Synopsis RFE: hardware acceleration for advanced blending modes (aka PhotoComposite) ) and other related RFEs.
With all the progress made within java 6 update 10 about the Direct3D and OpenGL pipelines, I was wondering when we could expect to see the hardware-accelerated PhotoComposite API.
Now that java GUI can benefit by default from these pipelines, it would be seriously cool to be able to bring more advanced blending effects than the current Porter-Duff rules implementation in the AlphaComposite API.

Does any of you guys have news on this ?

Cheers.

Vince.
[Message sent by forum member 'vync79' (vync79)]

http://forums.java.net/jive/thread.jspa?messageID=303194

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Full Screen Exclusive in two monitor setup

2008-09-29T13:05:39Z

Glad to hear that you worked something out.

The "simulated" fs mode (maximized undecorated window)
is actually acceptable for most cases. I would only
use fullscreen mode if you needed to change the display
mode as well.

Thanks,
Dmitri

java2d@... wrote:

> Hello Dmitri,
>
> Yes, it works as expected in single screen, FS mode. But, unfortunately, I no longer have a two monitor set up available to test this, and probably won't have one in a short term.
>
> I already delivered my program to the consumer. "Workaround" was not using full screen, I maximized the JFrame and disabled minimize, maximize and close buttons. Sure not a perfect solution, but it was acceptable for the task.
>
> I´d like to really thank you for your attention and feedbacks, and if there's any other info you would like me to post here, please let me know.
>
> Cheers from Brazil,
> Renan.
> [Message sent by forum member 'renanpolo' (renanpolo)]
>
> http://forums.java.net/jive/thread.jspa?messageID=302417
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@... and include in the body of the message "help".

Re: Full Screen Exclusive in two monitor setup

2008-09-29T12:46:32Z

Hello Dmitri,

Yes, it works as expected in single screen, FS mode. But, unfortunately, I no longer have a two monitor set up available to test this, and probably won't have one in a short term.

I already delivered my program to the consumer. "Workaround" was not using full screen, I maximized the JFrame and disabled minimize, maximize and close buttons. Sure not a perfect solution, but it was acceptable for the task.

I´d like to really thank you for your attention and feedbacks, and if there's any other info you would like me to post here, please let me know.

Cheers from Brazil,
Renan.
[Message sent by forum member 'renanpolo' (renanpolo)]

http://forums.java.net/jive/thread.jspa?messageID=302417

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Full Screen Exclusive in two monitor setup

2008-09-29T08:44:19Z

java2d@... wrote:
> Okay, thank you for your feedback. Here's the output printed when using J2D_TRACE_LEVEL=4. I'm not a specialist, but it seems everything is OK.

Yes, it looks fine. Now we'd need to run your app in fs mode in
multiscreen configuration with the same flag to see
if there are some errors.

Does it work in single screen setup?

Thanks,
Dmitri

>
> [I] OS Version = OS_WINXP Pro
> [I] CheckAdaptersInfo
> [I] ------------------
> [I] Adapter Ordinal : 0
> [I] Adapter Handle : 0x10001
> [I] Description : ATI Radeon Xpress 1200 Series
> [I] GDI Name, Driver : \\.\DISPLAY1, ati2dvag.dll
> [I] Vendor Id : 0x1002
> [I] Device Id : 0x7942
> [I] SubSys Id : 0x1231854
> [I] Driver Version : 6.14.10.6860
> [I] GUID : {D7B71EE2-3A02-11CF-2861-2921A1C2CB35}
> [I] D3DPPLM::CheckDeviceCaps: adapter 0: Passed
> [I] ------------------
> [I] D3DGD_getDeviceCapsNative
> [I] D3DContext::InitContext device 0
> [I] D3DContext::ConfigureContext device 0
> [V] dwBehaviorFlags=D3DCREATE_FPU_PRESERVE|D3DCREATE_HARDWARE_VERTEXPROCESSING
> [I] D3DContext::ConfigureContext: successfully created device: 0
> [I] D3DContext::InitDevice: device 0
> [I] D3DContext::InitDefice: successfully initialized device 0
> [V] | CAPS_DEVICE_OK
> [V] | CAPS_RT_PLAIN_ALPHA
> [V] | CAPS_RT_TEXTURE_ALPHA
> [V] | CAPS_RT_TEXTURE_OPAQUE
> [V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
> [V] | CAPS_MULTITEXTURE
> [V] | CAPS_TEXNONSQUARE
> [I] D3DContext::ResetContext
> [I] D3DContext::ConfigureContext device 0
> [I] D3DContext::ConfigureContext: successfully reset device: 0
> [I] D3DContext::InitDevice: device 0
> [I] D3DContext::InitDefice: successfully initialized device 0
> [V] | CAPS_DEVICE_OK
> [V] | CAPS_RT_PLAIN_ALPHA
> [V] | CAPS_RT_TEXTURE_ALPHA
> [V] | CAPS_RT_TEXTURE_OPAQUE
> [V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
> [V] | CAPS_MULTITEXTURE
> [V] | CAPS_TEXNONSQUARE
>
> Best Regards,
> Renan.
> [Message sent by forum member 'renanpolo' (renanpolo)]
>
> http://forums.java.net/jive/thread.jspa?messageID=302327
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@... and include in the body of the message "help".

Re: Full Screen Exclusive in two monitor setup

2008-09-29T05:21:48Z

Okay, thank you for your feedback. Here's the output printed when using J2D_TRACE_LEVEL=4. I'm not a specialist, but it seems everything is OK.

[I] OS Version = OS_WINXP Pro
[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal : 0
[I] Adapter Handle : 0x10001
[I] Description : ATI Radeon Xpress 1200 Series
[I] GDI Name, Driver : \\.\DISPLAY1, ati2dvag.dll
[I] Vendor Id : 0x1002
[I] Device Id : 0x7942
[I] SubSys Id : 0x1231854
[I] Driver Version : 6.14.10.6860
[I] GUID : {D7B71EE2-3A02-11CF-2861-2921A1C2CB35}
[I] D3DPPLM::CheckDeviceCaps: adapter 0: Passed
[I] ------------------
[I] D3DGD_getDeviceCapsNative
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[V] dwBehaviorFlags=D3DCREATE_FPU_PRESERVE|D3DCREATE_HARDWARE_VERTEXPROCESSING
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[I] D3DContext::InitDefice: successfully initialized device 0
[V] | CAPS_DEVICE_OK
[V] | CAPS_RT_PLAIN_ALPHA
[V] | CAPS_RT_TEXTURE_ALPHA
[V] | CAPS_RT_TEXTURE_OPAQUE
[V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
[V] | CAPS_MULTITEXTURE
[V] | CAPS_TEXNONSQUARE
[I] D3DContext::ResetContext
[I] D3DContext::ConfigureContext device 0
[I] D3DContext::ConfigureContext: successfully reset device: 0
[I] D3DContext::InitDevice: device 0
[I] D3DContext::InitDefice: successfully initialized device 0
[V] | CAPS_DEVICE_OK
[V] | CAPS_RT_PLAIN_ALPHA
[V] | CAPS_RT_TEXTURE_ALPHA
[V] | CAPS_RT_TEXTURE_OPAQUE
[V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
[V] | CAPS_MULTITEXTURE
[V] | CAPS_TEXNONSQUARE

Best Regards,
Renan.
[Message sent by forum member 'renanpolo' (renanpolo)]

http://forums.java.net/jive/thread.jspa?messageID=302327

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Long-running rendering ...was Re: Drawing to an off screen buffer

2008-09-27T23:31:12Z

java2d@... wrote:
> I'm starting think my problem is knowing what solution applies to my situation. There are plenty of solutions for handling long-running tasks in Swing. (SwingWorker, etc.) There are solutions for double buffering for animations (BufferStrategy). But, I don't think either of those apply to long-running rendering tasks.
>
> Maybe a solution to that would be to drip-feed little subtasks onto the event queue such that there is only one rendering task on the queue at a time and user events will be interleaved in the queue between rendering tasks.
>
> Any other ideas or examples for maintaining a responsive UI in the presence of long-running rendering tasks?
>
> Thanks,
>
> -chris

For complex paragraph layout tasks, the problem I had was to redo the
layout in response to changes in the size of the display panel: to
layout with wider of narrower line widths. Layout takes some time, so I
am currently trying the following.

In the panel (and in the EDT) capture the resize information, storing
the latest size, and trying to start a worker. If a worker is already
active, do nothing.

Otherwise, start a size monitoring worker.

The size monitoring worker in turn invokes another worker, whose job is
to perform the layout. It creates the layout worker, triggers it with
execute(), then blocks on a get() from the same worker.

The doInBackground method returns an object representing the laid out
paragraph. The done() method calls repaint, which collects the layout
data and paints it, according to the size of the panel when the task
started.

Meanwhile, the size monitoring worker has returned from the get(), and
can now check to see whether another size change has occurred.

If so, it repeats the cycle of creating a layout worker.

If not, it terminates, and the system waits on another size change event.

It may seem that the size monitoring worker is redundant, but I found
that it neatly separated the phases. One of the problems, I think, was
that the actual repaint() takes some time itself. Performing the repaint
in the done() method of layout worker seems to work, but ideally, I
would like the size monitoring worker to wait until the repaint was
finished before starting another layout worker, but I can't see an easy
way to do that, while preserving the nice blocking characteristics of
the get() method.

It's a messy explanation, I know, and it was developed by trial and
error. If you need anything clarified, let me know.

--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Optimizing concentric arcs

2008-09-26T03:04:34Z

Like I said, "...oh well..."

Might just be my old machine that is giving
me inaccurate results from StrictMath. It's
an old PIII. But I can't get back 0 or 1
from the sin() method when I need them to be 0 or 1.

Also, what should be a straight integer multiply
using real numbers for the integer value frequently
returns a non integer result. I'll get back a number
like (and this is a fabricated example for clarity not
an actual calculation) 9.9999 when I should get 10.0.

Stuff like that and the trig() methods are really slow.
I use a 7'th degree Legrange polynomial multiplication for an
approximation of atan2() because it's faster than atan2().
That's not right...

java2d@... wrote:

>>Er... is StrictMath already FPU accelerated? If it
>>is then, oh well...
>
> Its as far accalerated as the FPU produces acceptable results.
> For example on x86 the sin-command is used only in a special range where its known to be correct.
>
>
>>The current Math package is really not very good.
>> Especially
>>or low level graphics stuff where 5 significant
>>digits is
>>the minimum accuracy that is useful.
>
> Almost can't believe that its so inaccurat, they do a great amount of work to ensure that as far as I know.
> After all, using straight FPU commands, accuracy won't be any better, at least on x86.
>
> lg Clemens
> [Message sent by forum member 'linuxhippy' (linuxhippy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=301778
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@... and include in the body of the message "help".
>

Re: Optimizing concentric arcs

2008-09-26T02:40:02Z

> Er... is StrictMath already FPU accelerated? If it
> is then, oh well...
Its as far accalerated as the FPU produces acceptable results.
For example on x86 the sin-command is used only in a special range where its known to be correct.

> The current Math package is really not very good.
> Especially
> or low level graphics stuff where 5 significant
> digits is
> the minimum accuracy that is useful.
Almost can't believe that its so inaccurat, they do a great amount of work to ensure that as far as I know.
After all, using straight FPU commands, accuracy won't be any better, at least on x86.

lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=301778

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Long-running rendering ...was Re: Drawing to an off screen buffer

2008-09-26T02:11:26Z

If I understand well, what takes time here is the computation of the plot.

Now, have you considered building some kind of representation of the plot (say, in terms of shapes) ? In this case, you would have :

* A thread building an abstract representation of the data
* the graphical thread whose work would only be to draw the said representation in a JPanel or JComponent.

If your plot is really a bitmap, you could consider a thread which would render small parts of it in small bitmap areas which would then be available to the event loop to render ?
[Message sent by forum member 'rosmord' (rosmord)]

http://forums.java.net/jive/thread.jspa?messageID=301777

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Long-running rendering ...was Re: Drawing to an off screen buffer

2008-09-26T01:59:15Z

Hi Chris,

You might want to take a look at the Task class from Swing Application
Framework. It is a great abstraction for long-running operations in
general. It's basically a fancy SwingWorker, with support for a nice
publish/process-protocol, which I think you could use for your "drip-
feed" mechanism.

Not really sure it fits your needs, but I think it's worth looking into.

Best regards,

--
Harald K

On 25. sep.. 2008, at 22.34, java2d@... wrote:

> I'm starting think my problem is knowing what solution applies to my
> situation. There are plenty of solutions for handling long-running
> tasks in Swing. (SwingWorker, etc.) There are solutions for double
> buffering for animations (BufferStrategy). But, I don't think either
> of those apply to long-running rendering tasks.
>
> Maybe a solution to that would be to drip-feed little subtasks onto
> the event queue such that there is only one rendering task on the
> queue at a time and user events will be interleaved in the queue
> between rendering tasks.
>
> Any other ideas or examples for maintaining a responsive UI in the
> presence of long-running rendering tasks?
>
> Thanks,
>
> -chris
> [Message sent by forum member 'cbare' (cbare)]
>
> http://forums.java.net/jive/thread.jspa?messageID=301678
>
> =
> =
> =
> =
> =
> ======================================================================
> To unsubscribe, send email to listserv@... and include in
> the body
> of the message "signoff JAVA2D-INTEREST". For general help, send
> email to
> listserv@... and include in the body of the message "help".

Re: Optimizing concentric arcs

2008-09-25T15:58:12Z

YES! Why not FPU acceleration? That's what it's there for.

Er... is StrictMath already FPU accelerated? If it is then, oh well...

The current Math package is really not very good. Especially
for low level graphics stuff where 5 significant digits is
the minimum accuracy that is useful.

java2d@... wrote:

>>I've wanted to gripe about the slowness and
>>inaccuracy of
>>the Math package but who do I talk to?
>
>
> I totally agree. It would be great if the programmer could choose between the StrictMath implementation which is hard-wired now and maybe something like, call ist FastMath.
> FastMath could be implemented without any guarantees, and really 1:1 instrified in hotspot to a corresponding CPU instruction if there is any, that would be really cool :)
>
> lg Clemens
> [Message sent by forum member 'linuxhippy' (linuxhippy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=301657
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@... and include in the body of the message "help".
>

Re: Drawing to an off screen buffer

2008-09-25T14:16:03Z

Well, lets clarify/assume a few things.

You have some data source, constantly producing data, right? While that data source happily produces data the user is also looking at a representation of that data, right? And the user can interactively select (scrolling, zooming) which portion of the data he/she gets a representation of?

Ok, first, I am not a big fan of rendering and rasterizing (drawing to an image) the data in the backgrond in such a case. For at least two reasons: Zooming on already rasterized data doesn't work well, so for zooming it is required to freshly rasterize that data. Second, if the plot is indeed very large you can not fully predict to which area the user might scroll next. So you can't reasonably well guess which area should be preferentially rendered in the background. Because of this two issues, a lot of CPU power used for background rendering is just wasted, since you render something you can't use.

So, instead of rendering in the background, organize/store the incomming data in a way that it is easy to render in the background (in a thread). This, for example, might include to already decompose the data into primitive graphic elements like lines. You don't actually draw such lines, you just store easy to process information that you would draw a line. And provide a locking mechanism on the data, so that the maintenance of the data and the rendering (see below) are properly synchronized.

Further, if the plot is really so large, spatially organize that graphic element data in the background in a way that you can quickly find all data within a particular rectangular 2D region (quadtree). If you have many overlapping graphic elements you might even want to organize the data in three dimensions (octree), so that you can easily cull details when the user has zoomed out very fare (because in this case many details would anyhow be lost when rendering the data).

Now to the user interaction and actual rendering. You create an own Swing component based on a JComponent or JPanel. Creating an own Swing component has often been document, I won't go into this. Just make sure you get the basics and the nastier details right :-) Also implement the Scrollable interface. I assume you put that component in a JScrollPane.

The paintComponent() method of your component will be called when Swing thinks your component or a part of your component needs to be redrawn. The key here is "part of your component". Swing indicates what part needs to be redrawn with the clipping region (don't forget to take the Graphics2D origin into account, it might not always be 0,0). So in your paintComponent() you use that information (and the current zoom factor) to identify the part of your graphic element data that needs rendering. That part should be much less then your whole data. Then, right in paintComponent() you render it to the provided Graphics2D.

I assume you have some extra buttons for zooming in or out (or some mouse events). Anyhow, whenever the zoom factor changes you remember the new zoom factor, then call repaint(). At some point in time repaint() will result in a call to paintComponent(). And since your paintComponent() takes the zoom factor into account (well, it should), it will render the plot with the new zoom factor.

Also, whenever the incomming data has changed significantly, you call repaint, too. Don't do it to often, and don't do it for every tiny change. Accumulate a bunch of changes, then call repaint(). However, if you really think you need 15fps and every tiny change in the data needs to be immediately visible, than forget everything I wrote and change to active rendering.

That's the basic architecture. If that is still not responsive enough, consider caching the renderings you did in paintComponent() in BufferedImages. And before you render some area you check your cache if you have already all or parts of that area in your cache. If you have, you just copy that part from the cache to the screen. You need proper cache management, like remembering which zoom factor was used for a particular rendering, or if the incoming data would invalidate a cached rendering.

Careful planning, a well designed data structure, knowing Swing's paint mechanism (with all its barely documented idiosyncrasies), a clear understanding of world, component and screen coordinate systems, and probably a thousand odds and ends are needed to make this fly. Or you drop that Java2D junk, where you are never sure if you get hardware acceleration or not, and use some commercial data visualization system or write directly for a particular OS and native graphics system, so you are not at the mercy of a VM with rubbish documentation.
[Message sent by forum member 'ewin' (ewin)]

http://forums.java.net/jive/thread.jspa?messageID=301687

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Long-running rendering ...was Re: Drawing to an off screen buffer

2008-09-25T13:34:19Z

I'm starting think my problem is knowing what solution applies to my situation. There are plenty of solutions for handling long-running tasks in Swing. (SwingWorker, etc.) There are solutions for double buffering for animations (BufferStrategy). But, I don't think either of those apply to long-running rendering tasks.

Maybe a solution to that would be to drip-feed little subtasks onto the event queue such that there is only one rendering task on the queue at a time and user events will be interleaved in the queue between rendering tasks.

Any other ideas or examples for maintaining a responsive UI in the presence of long-running rendering tasks?

Thanks,

-chris
[Message sent by forum member 'cbare' (cbare)]

http://forums.java.net/jive/thread.jspa?messageID=301678

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Drawing to an off screen buffer

2008-09-25T12:35:54Z

I recommend using something similar to the Foxtrot API. It is not recommended to perform time intensive processes in the event queue.
[Message sent by forum member 'bcorbett8769' (bcorbett8769)]

http://forums.java.net/jive/thread.jspa?messageID=301665

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Optimizing concentric arcs

2008-09-25T12:02:37Z

> I've wanted to gripe about the slowness and
> inaccuracy of
> the Math package but who do I talk to?

I totally agree. It would be great if the programmer could choose between the StrictMath implementation which is hard-wired now and maybe something like, call ist FastMath.
FastMath could be implemented without any guarantees, and really 1:1 instrified in hotspot to a corresponding CPU instruction if there is any, that would be really cool :)

lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=301657

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Drawing to an off screen buffer

2008-09-25T11:13:34Z

You can render in a different thread. I do in my viewers
and they remain responsive.

http://pancyl.com/LakeMary_1.htm

java2d@... wrote:

> Thanks for all the hints. The frame rate I'm getting using invokeLater is very slow (~5 seconds per frame). And, the event dispatch thread gets clogged with lots of rendering tasks and becomes unresponsive. So, that's no good.
>
> My rendering is happening in response to user actions - scrolling, zooming, and mouse selections. My goal for the UI to remain responsive even if rendering takes several seconds.
> [Message sent by forum member 'cbare' (cbare)]
>
> http://forums.java.net/jive/thread.jspa?messageID=301639
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@... and include in the body of the message "help".
>