Re: [JAVA2D] drawRoundRect & setStroke bug?
Supply the cap and join properties as follows: [code] g2.setStroke(new BasicStroke((float) borderSize, BasicStroke.CAP_ROUND, BasicStroke.JOIN_ROUND)); [/code] Piet [Message sent by forum member 'pietblok' (pietblok)] http://forums.java.net/jive/thread.jspa?messageID=342198 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Can ADD and MULTIPLY be expressed using Porter/Duff equations as per the existing rules? I seem to recall that they require clipping the result which none of the other modes require. The P/D chapter in Foley and vanDam mentiones PLUS, but it doesn't describe it in the same terms as the existing table of rules. It is more described as "another useful binary image operation". Keep in mind that the existing P/D rules for AC are all implemented using a single loop at the bottom end that has a tiny variation in it that handles all 12 or so rules in the same piece of code with little structural change. Note that when I say "a single loop" I don't mean a single piece of code that is factored with macros into 12 loops, but a single actual compiled object function that handles all 12 rules. It doesn't even have any decisions in the inner loop for the 12 rules - instead it relies on mathematical similarities of the 12 rules to handle them all with a single computation. So, if you want to add new rules to this matrix, they might not fit into this technique and induce an explosion of the code that handles the AC rules. The technique only really deals well with rules that can be expressed with the 4 standard Fa and Fb functions that are guaranteed not to overflow in the math. If you add rules that are incompatible with that technique then it is more likely that you'll have to special case them and vector them into new inner loops that do whatever clipping/clamping is required for ADD/MUL that isn't required for the regular AC rules. That isn't a huge issue, but it might almost be cleaner to have a new class so we vector into different code paths at a higher level than to have to vector off at a lower level. (Try it and see how it goes). ...jim jav...@javadesktop.org wrote: Hi everyone, quick question more or less related to this topic on hardware accelerated drawing: I was desperately waiting for what was supposed to be called the PhotoComposite API that would allow new blending modes (ADD, MULTIPLY, OVERLAY, ...) to be used as Composite for the Graphics2D API. Unfortunately, it seems that the original plan is no longer in scope as stated in the RFE 6541868 (RFE: hardware acceleration for advanced blending modes (aka PhotoComposite) ): [i]"Therefore, my current inclination is to scale back the changes originally proposed for JDK 7 and instead make small additions to the existing AlphaComposite API with at least an ADD mode since a) that is the most commonly requested blend mode that isn't already provided in AlphaComposite, b) it fits in fairly well with the existing AlphaComposite rules, and c) it can be accelerated easily in both the software and hardware pipelines (without the use of shaders or reading back from the framebuffer in the hardware case). We might also be able to add a simple MULTIPLY mode, but that will require some more investigation. I think this approach (small enhancements to AlphaComposite) would serve the needs of Java2D developers quite well, while keeping the implementation burden low. Developers who want access to extended blend modes can use the Blend class from JavaFX, which offers the right amount of functionality in a form that can be easily accelerated on the GPU."[/i] Having ADD and MULTIPLY as Composite for Graphics2D is much better than nothing as they are usually the most useful "advanced" blending modes. My problem is that I am working with the BufferStrategy to perform fast frame rate in fullscreen mode. And when using the BufferStrategy, I cannot access to the actual offscreen backbuffer to use it with the JavaFX Blend implementation that will give access to the other hardware accelerated blending modes. As stated by Dmitri, using a VI and then drawing it with the BufferStrategy is not really satifying... This is why having the Graphics2D API able to use all the wonderful hardware accelerated drawing features of the JavaFX package would be very nice... If you see some kind of workaround for me to use JavaFX API with the BufferStrategy without using an additional backbuffer, I would be very interested ! Thanks. Vincent. [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=340922 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help". === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] drawRoundRect & setStroke bug?
Hi Piet,
I found another problem.
With this exemple (keep the window small), you would expect to see something
like an oval. There is some extra, which shouldn't be there.
[code]
public class TestBorder extends JPanel{
private int borderSize = 50;
private int round = 90;
public TestBorder(){
}
public void paintComponent(Graphics g){
Graphics2D g2 = (Graphics2D) g.create();
g2.setColor(Color.black);
g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
g2.setStroke(new BasicStroke((float) borderSize));
g2.drawRoundRect(borderSize / 2, borderSize / 2, getWidth() -
borderSize - 5, getHeight() - borderSize - 5, round, round);
//g2.drawOval(borderSize / 2, borderSize / 2, getWidth() - borderSize,
getHeight() - borderSize);
g2.dispose();
}
public static void main(String args[]){
SwingUtilities.invokeLater(new Runnable() {
public void run() {
TestBorder tst = new TestBorder();
JFrame jf = new JFrame();
jf.setSize(150, 150);
jf.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
jf.add(tst);
jf.setVisible(true);
}
});
}
}
[/code]
Thanks,
Olivier
[Message sent by forum member 'odoremieux' (odoremieux)]
http://forums.java.net/jive/thread.jspa?messageID=341953
===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
lists...@java.sun.com and include in the body of the message "help".
[JAVA2D] Operation/Transformation on BufferedImage: colour to transparent?
Hi,
I've written a piece of code that uses Java 2D to (jdk 1.5, Windows (XP)) to
"split" an image into two other images. The code works, but is slow and it
feels clumsy. I'm writing in the hope one of you clever people is willing to
help me speed up this code.
The original image is a .png image that I read from disk (~100K) into a
BufferedImage. The image is mostly transparent, with some (black) outlines. The
image also contains pixels with one particular (defined) colour. This colour
can be different from image to image, but is limited and defined within one
image.
What the code does is process this original image into two new images:
1. a BufferedImage (bodyImage) that is the same as the original image, but
where all pixels with that defined colour (paintRGB) are turned transparent (by
setting it to rgb '0'),
2. a BufferedImage (colourImage) that is transparent expect for the pixels with
that defined colour (paintRGB).
At the moment reading the original image into a BufferedImage takes about 3.5
seconds. Processing the image into the two others takes another 4 seconds.
I read up and played with BufferedImageOps, but haven't managed to find one (or
use one) that does that what I want:
ImageFilter doesn't work on BufferedImage.
LookupOp doesn't allow me to make one single colour transparent (as far as I
can tell).
There is the code snippet:
[code]
public void read(File imageFile, int paintRGB) throws IOException {
BufferedImage imageOnDisk = ImageIO.read(imageFile);
Graphics2D g = imageOnDisk.createGraphics();
g.setComposite(AlphaComposite.Src);
g.drawImage(imageOnDisk, 0, 0, null);
g.dispose();
int width = imageOnDisk.getWidth();
int height = imageOnDisk.getHeight();
BufferedImage bodyImage = new BufferedImage(width, height,
BufferedImage.TYPE_INT_ARGB);
BufferedImage colourImage = new BufferedImage(width, height,
BufferedImage.TYPE_INT_ARGB);
for (int x = 0; x < width; x++) {
for (int y = 0; y < height; y++) {
int rgb = imageOnDisk.getRGB(x, y);
if (rgb == paintRGB) {
bodyImage.setRGB(x, y, 0);
colourImage.setRGB(x, y, rgb);
} else {
bodyImage.setRGB(x, y, rgb);
colourImage.setRGB(x, y, 0);
}
}
}
}
[/code]
Thanks, Birgit Arkesteijn
[Message sent by forum member 'birgita' (birgita)]
http://forums.java.net/jive/thread.jspa?messageID=341950
===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] drawRoundRect & setStroke bug?
Hi Olivier,
It is because arcWidth and arcHeight are too small to honor the stroke width on
the inside.
Please run example below to see what I mean:
[code]
import java.awt.BasicStroke;
import java.awt.Graphics;
import java.awt.Graphics2D;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;
public class ThickStroke {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
new ThickStroke().createGUI();
}
});
}
public void createGUI() {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.add(new JPanel() {
private static final long serialVersionUID = 1L;
@Override
protected void paintComponent(Graphics g) {
Graphics2D g2 = (Graphics2D) g;
g2.setStroke(new BasicStroke(50f));
g2.drawRoundRect(30, 30, 200, 200, 90, 90);
g2.drawRoundRect(330, 30, 200, 200, 10, 10);
}
});
frame.setSize(600, 400);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
}
[/code]
Piet
[Message sent by forum member 'pietblok' (pietblok)]
http://forums.java.net/jive/thread.jspa?messageID=341949
===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
lists...@java.sun.com and include in the body of the message "help".
[JAVA2D] drawRoundRect & setStroke bug?
Hello, If I do a drawRoundRect and before a setStroke with a tick border, for example g2.setStroke(new BasicStroke(50.0f)); The outerborder is round, no problem, but the inner border is square. With small value we don't see the problem. If instead I do a drawOval, I have no problem. Is it a bug? What should I do to have a round inner border? Thanks in advance, Olivier Doremieux [Message sent by forum member 'odoremieux' (odoremieux)] http://forums.java.net/jive/thread.jspa?messageID=341943 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
