Re: [JAVA2D] Bizarre exception (Win32ShellFolder2)
Hi Olivier, Thanks for the problem report - this looks like an issue with how we process COM commands (apparently incorrectly when we're in the middle of shutting down). We changed our COM code, to fix other unrelated problems, in this update release. Anyway, the issue has been identified and filed as bug #6612928 (may not be visible on the bugs.sun.com site immediately, but in case you want to track it in the future that bug ID should help). Thanks, Chet. Olivier Lefevre wrote: Hi Dmitri, The Java version is: java version 1.6.0_02 Java(TM) SE Runtime Environment (build 1.6.0_02-b06) Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing) running on Windows XP Pro SP2 with all the latest patches. Regards, -- O.L. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] translate method
Re-send: the list bounced it a few days ago... Chet. Chet Haase wrote: Eyal, translate() adds the given translation to the one that exists in the Graphics object already. So the new x,y are relative to the current translated origin, not the top left corner. This doesn't affect objects you have already drawn, since it only impacts things that you will draw after you set this new state. Chet. [EMAIL PROTECTED] wrote: Hi All, When I use the Graphics2D.translate(int x, int y) several times in one program, does the new x and y are relative to the old origin or to the top left corner? and what happens if I already have several shapes? does Java2D re locate them according to the new origin? Thank u in advance Eyal [Message sent by forum member 'eyal757' (eyal757)] http://forums.java.net/jive/thread.jspa?messageID=217485 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Questions about image type and jpegs
Re-send: the list server bounced it a few days ago... Chet. Chet Haase wrote: Hi Rick, A good general approach is to copy any image into the image type you'd actually like to use. For example, if you are going to be using an image as a source for copies to the Swing window or to other images, create a compatible image: gc.createCompatibleImage(w, h) where (w,h) come from the dimensions of your loaded image and gc is a suitable GraphicsConfiguration. Once you have an image in the type you desire, just get the Graphics for it and copy the original image into it: Graphics g = newImage.getGraphics(); g.drawImage(originalImage, 0, 0, null); Then just use newImage instead of your original image... Chet. Rick Root wrote: I'm trying to do some image manipulation of some jpegs using java code running on jre 1.4.2_11 When I call the getType() method on the BufferedImage objects after loading the jpeg images.. they will sometimes return a value of 0 (TYPE_CUSTOM). I have a hard time manipulating these images. I did a little testing with an image using Photoshop 7 and a picture from my digital camera. I saved 3 copies of it... all the standard settings for a jpeg... but with different Format settings.. Baseline Standard, Baseline Optimized, and Progressive. The first two end up with an image type of 0, while the progress jpeg seems to be the only one I can work with. It returns an image type of 5. So, my question is... since I can't manipulate images with custom image types.. how do I deal with this using standard java2d apis included with Java 1.4.2? Rick === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Value to use for RenderingHints.KEY_TEXT_ANTIALIASING in a library
... which reminds me, I wrote a short blog on this, Font Hints for Custom Components, to show how to use Desktop Properties for this. In case it helps: http://weblogs.java.net/blog/chet/archive/2007/01/font_hints_for.html Chet. Phil Race wrote: AA text used to be very slow once upon a time but I think I sped it up mostly in 1.5 not 6 There could be other reasons why its 'faster' now. ie better detection that rendering involves readback from the surface (not specifically for text) which can be slow on AGP buses .. As for the best default to use, there is a public mechanism built into JDK6 to let you get the hints that correspond to the system default. Swing already uses this See http://java.sun.com/javase/6/docs/api/java/awt/Toolkit.html#getDesktopProperty(java.lang.String) which directs you to the following detailed explanation http://java.sun.com/javase/6/docs/api/java/awt/doc-files/DesktopProperties.html -Phil [EMAIL PROTECTED] wrote: Hi I'm looking at how we support AA for text in the Flying Saucer library. Before Java 6 (we support back to 1.4 for the library), we found AA to be pretty slow, hence we had it turned off by default. I just turned it back on and found performance, at least with JDK 6, to be great--now my question is which of the many possible values for RenderingHints.KEY_TEXT_ANTIALIASING we should use by default when our users ask for AA text to be enabled. We set the value before performing text operations (drawString()). I'll probably give them the option via our configuration file, but am wondering what we should use as a default recommended value--in our case, we don't know what systems the library will be used on. Any reasonable approaches you can recommend? Thanks Patrick [Message sent by forum member 'pdoubleya' (pdoubleya)] http://forums.java.net/jive/thread.jspa?messageID=212445 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Java 2D Enhancements in JDK 6 and JDK 7
However, when I read JDK 6's document, I can't find any information with New Java 2D features in JDK 6.0. I can't believe there are no Java 2D enhancements in JDK 6.0 :) When, where, and how our work gets documented can vary from release to release. We actually wrote more about what we were doing in SE 6 as we did it than we did in probably any other release. But I guess a lot of that information didn't make it into the specific document you mention. The article Desktop Java Features in Java SE 6 has fairly current info, even though it was written some time ago: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/ One caveat is that, although we did substantial work on our hardware acceleration platform for Windows, we did not get far enough to enable it by default. We hope that this will change with our work in SE 7 (Dmitri's hard at work on the D3D stuff right now). Because I know there are some: o Java 2D interoperation with OpenGL through GLJPanel o The OpenGL rendering pipeline with more hardware-accelerated operations Indeed, these features are great. I would add Single Threaded Rendering, which helped for both performance and robustness for GL, and will do the same for the future D3D pipeline. The GL pipeline is doing some very cool things. We don't talk about it too widely in general because it's not enabled by default (typical driver/hw issues), but for the folks that can use our GL pipeline, it's pretty awesome. We hope to see this functionality shared between the GL and D3D pipelines in the work that Dmitri is doing on D3D currently. And, from Chris Campbell's blog, I know some will be in JDK 7: o Rewrite GDI/DirectX pipeline by Direct3D for the Vista sake o More robust OpenGL pipeline with more hardware-accelerated operations like pixel shaders and vertex shaders for the more advanced GPUs. Both of these are important parts of the performance/acceleration story in general. These should be huge. Does Java 2D has some plans for the JDK 7? Indeed we do - we just haven't really talked about them publicly yet (note that we have not yet nailed down the feature set for the platform overall for SE 7). We'll be discussing some of them at JavaOne next month. I'd also like to get some blogs/articles going on the things we have in mind... just haven't had time to do it yet. Java 2D members' blog like Chris Campbell''s is a great learning resource, but it seems that other Java 2D members like Jim Graham and Dmitri Trembovetski don't have blogs. I wish Jim and Dmitri will do some blogs in the future. We've been saying the same thing internally... And I have a question to Jim: I remember that you have demonstrated some cool effects which can be achieved by Java 2D in JavaOne 2003. May you interpret how to make these effects? I'll let Jim field this one. Note that some cool 2D stuff shows up in the SwingLabs project on java.net. For example, Jim has a very cool utility for morphing between Shape objects there. Chet. [Message sent by forum member 'ylzhao' (ylzhao)] http://forums.java.net/jive/thread.jspa?messageID=211799 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Problems with VolatileImage
Hi, Since you called me out by name, I feel compelled to respond... I'm not sure which version of the JDK you're using, but the original 1.4 VolatileImage was opaque-only. The original use-case for these images was as back buffers or other inherently opaque images. We introduced VolatileImage with transparency in a later release (1.5?), although these images are not typically accelerated in the same way as opaque VolatileImages (with the exception of the OpenGL pipeline; VolatileImages get pretty good acceleration there in general). I'm assuming you're using the latter release that actually allows creation of transparent or translucent VolatileImages. In this case, the trick is to erase that VolatileImage with a transparent background color first. Or, you can copy your transparent-background image onto the VolatileImage with Src; the SrcOver operation will ignore the transparent background in your source image and leave the pixel values in the destination image. So if you didn't erase the VolatileImage to transparent first, then you may get stuck with some opaque pixels there instead. For sample code on this, check out the Intermediate Images article here: http://java.sun.com/developer/technicalArticles/Media/intimages/ (go to the code snippet that renders the transparent-background smiley correctly, about half-way through the article). The article not using a VolatileImage, but the approach is similar insofar as the need for a transparent background on the destination image. Note, with respect to my diatribe above on performance, that there may not be a compelling reason to use VolatileImage here (you could just use a managed image, as shown in the Intermediate Images article). Any reason you're trying to use VolatileImage here instead? Chet. [EMAIL PROTECTED] wrote: I'm having some problems with my VolatileImages: First, I load PNG files with transparent regions into BufferedImages using ImageIO and then draw them into VolatileImages. When these VolatileImages are drawn to the screen, they have white where they're supposed to be transparent. I've tried specifying both BITMASK and TRANSLUCENT transparencies when creating the VolatileImage and neither way worked. I also tried with the translaccel option set to true. The other problem I have is that when I try to validate my images, they go completely white. The validation returns IMAGE_OK and contentsLost() returns false, so I'm rather confused about this. It seems that Chet and Chris, a couple of Java2D experts, frequent this forum so I'm hoping that one of them finds this message and is able to help me out. Thanks. [Message sent by forum member 'dialup' (dialup)] http://forums.java.net/jive/thread.jspa?messageID=147826 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Problems with VolatileImage
Glad that worked for you... Yes, validation is important; if you never validate it, it may never be in a usable state. You basically want to do this when you first set it up: - validate - erase to transparent bg - do whatever other graphics ops you want (like copying the source image to it) - check for contentsLost() Chet. [EMAIL PROTECTED] wrote: Ah-ha, Chet, you hit it right on the nail! I didn't realize you had to clear it to a transparent colour first. I knew I was right to ask you. :D Anyway, I still have the issue of validate() making my image white for no apparent reason. Is validating the images all that important? As I understand it, the images are only lost when the display mode changes. [Message sent by forum member 'dialup' (dialup)] http://forums.java.net/jive/thread.jspa?messageID=147853 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Problems with VolatileImage
I was just talking about the first time. You should validate every time you use it (even to copy from it). An image that has not been lost should not be written to, so the transparent bg that you rendered to it the first time will still be there, and validation will not erase it to white. Is this what you're finding? validation should basically be a noop if the image has not been lost, so I can't see where this would cause an erasure to an opaque color. On the other hand, when an image is first created, or first restored, that first validation will put it into some basic state, which may include erasing it (thus the need to set your own transparent bg color after the initial validation). Chet. [EMAIL PROTECTED] wrote: So, I don't validate it every time I copy from it? [Message sent by forum member 'dialup' (dialup)] http://forums.java.net/jive/thread.jspa?messageID=147873 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage of a type like those from BufferedImage
Currently, there is no way to do this. You may get a different image type internally based on whether the VolatileImage is transparent or translucent (we added a method to create such an image in Mustang), but otherwise there is no way to tell us what image representation you want. One of the reasons for this is that some mechanisms for creating and storing VolatileImages internally require that the image be stored in the same resolution as the GraphicsConfiguration for which the VolatileImage is being created. Another way to think of this is that a video card has a certain color configuration (like 32-bit, RGB) and offscreen images in that same video memory may be required to be in that same format. For example, on Windows our default acceleration mechanism is DirectDraw, which has the requirement that all offscreen accelerated surfaces be in the onscreen format. There is no way to have an offscreen image of a different color depth or configuration. Other platforms and rendering pipelines may vary (for example, Direct3D and OpenGL are able to create textures of various types regardless of onscreen color configuration). Hope that helps... Chet. [EMAIL PROTECTED] wrote: I am curious if there is possible to create a VolatileImage with a specific type ? And when I say type I reffer to those types from the BufferedImage class: TYPE_INT_ARGB, TYPE_BYTE_GRAY, etc. Sarmis [Message sent by forum member 'jsarmis' (jsarmis)] http://forums.java.net/jive/thread.jspa?messageID=140383 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage of a type like those from BufferedImage
Managed Images are typically only accelerated for operations
that copy-from the image to an accelerated destination. This is
because we must retain the original bits of a managed image in
memory that cannot be lost, as VRAM images on Windows may be.
For scenarios where an image is rendered to once, or infrequently,
managed images are probably a better approach because then you
don't have to worry about handling the acceleration/loss issues.
For scenarios where you are rendering to the image frequently
(as Swing does for its back buffer), a VolatileImage can be more
useful because:
- we accelerate some operations to that image
- the image will actually be accelerated (which may not be
the case for a managed image rendered to frequently)
So for your example below, you're effectively eliminating the
possibility of using an accelerated back buffer. Whether this
affects the overall performance of your application depends on
what your app is trying to do and the type and frequency of
rendering operations that you are performing.
Chet.
[EMAIL PROTECTED] wrote:
Googling for this I have found this:
http://swingwt.sourceforge.net/javadoc/swingwt/awt/image/VolatileImage.html
but that is in another Swing implementation.
As of JDK 1.5, all the buffered images created using the constructors of the
BufferedImage class are managed images. Given that, using VolatileImage as a
back buffer in RepaintManager does still offer a significant performance
improvment ?
I am asking this because I've done a nice thing with RepaintManager:
[code]
package myjavaextension.swing;
import java.awt.*;
import java.awt.image.BufferedImage;
import javax.swing.RepaintManager;
public class BlackAndWhiteRepaintManager extends RepaintManager {
private BufferedImage offscreenBuffer;
public BlackAndWhiteRepaintManager() {
super();
init();
}
private void init() {
Dimension maximumSize = super.getDoubleBufferMaximumSize();
offscreenBuffer = new BufferedImage(
maximumSize.width, maximumSize.height, BufferedImage.TYPE_BYTE_GRAY );
}
@Override
public Image getOffscreenBuffer( Component c, int proposedWidth, int
proposedHeight ) {
return offscreenBuffer.getSubimage( 0, 0, proposedWidth, proposedHeight );
}
@Override
public Image getVolatileOffscreenBuffer( Component c, int proposedWidth, int
proposedHeight ) {
return null;
}
}
[/code]
Installing this repaint manager will render a gray UI.
But I am affraid that the performance of using VolatileImage as a back buffer
is lost.
[Message sent by forum member 'jsarmis' (jsarmis)]
http://forums.java.net/jive/thread.jspa?messageID=140430
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Making a JTextArea appear in a BufferedImage O.o
You need to override paintComponent(), not paint(). If you override paint(), you need to draw the children of the current component yourself (paint draws borders, children, etc.). But if you override paintComponent(), then your responsible only for the component's contents, and Swing will handle the children. Chet. [ Fenrir Northern Wolf ] wrote: Hey ppl. I'm getting problems to show a JTextArea in an applet that I'm working on, and I hope someone can help me. Well, my application is like windows Paint. You can draw some shapes in it, and can move, reshape it, cause I save every shape reference. And to draw it I overrided the repaint() method and there I do all the drawing needed to all the shapes appear in a Graphics2D area, but I'm having problem to make JTextAreas appear. I don't know if I'm making myself clear, my engilish doesn't help too much, but I want to know what I have to do to draw the JTextAreas. They don't appear, even if I position them in a absolute pos with setLocation method inherited from Componet class. Someone can help me? Ah.. it's a JPanel that I'm drawing into. If it's not to clear what I said, plz reply explaining what you didn't understand, I will try to explain better then. Well, thx anyway o/ -- What said Odin to the Gods and to the Champions who surrounded him? We will give our lives and let our world be destroyed, but we will battle so that these evil powers will not live after us. Out of Hel's ship sprang Fenrir the Wolf. His mouth gaped; his lower jaw hung against the earth, and his upper jaw scraped the sky. Against the Wolf Odin All-Father fought... ...By Fenrir the Wolf Odin was slain. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] JavaOne 2006
I just realized that the Early Bird discount for JavaOne ends today. It seemed like I should at least send out a reminder to the alias for folks that were interested in possibly attending, but just hadn't gotten around to registering. Great desktop track sessions this year, both from inside and outside Sun. For 2D fanatics, we'll have a couple of sessions on Swing+2D effects plus a 2D performance session from Maplesoft. For general Desktop developers, there's lots of great sessions to go around. Anyway, check out the conference site at http://java.sun.com/javaone and be sure to register today (April 14th) to get the nifty discount. Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] getting pixel color information from a rectangle inside a Panel
Seems like you want some buffer that holds the contents
of the graph without your red node on it. Then prior to
drawing the new location of the red node, you can simply
copy in the contents from the buffer in the area affected by
the last rendering of the red node. This will effectively
erase the red node from its previous location. (It may also
be faster than drawing a new oval in that location, as a
side benefit)
Chet.
Thanasis (Hotmail) wrote:
Hi to everyone,
i have built a graphics application using only AWT.
Inside a Panel i illustrate a graph which has a number of nodes and arcs
(i have drawn THE GRAPH using g.fillOval and g.drawLine methods).
What i want to achieve is to move a red node (circle) from one point P1
inside the
Panel to another Point P2.
I have done it as follows:
...
while (P1!=P2){
draw the node in red color(fillOval)
delay(100ms)
draw the node in white color(fillOval)
move P1
}
The problem is that as the node is moving it ERASES any previous pixels
lying below it.
Is there any way to get the color of these pixels that lie below the
moving node
and DRAW IT ONLY if those pixels are white?
Thanks in advance
Thanasis
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body of the message signoff JAVA2D-INTEREST. For general help, send
email to [EMAIL PROTECTED] and include in the body of the message
help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] pleaseignore and delete this: testing cross-posting functionality
We're trying to link up the java2d-interest list with the Java2D forum http://forums.java.net/jive/forum.jspa?forumID=69 to make sure people can cross-post. Just checking to see whether everything's connected up correctly. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Note that you may be able to get away with vsync'ing without
JAWT; vsync is done on a per-device basis and does not need a
handle to the window. The main reason you'd need to know the
window would be to determine the correct device (display) to
use. If you can determine that some other way, then you
can skip JAWT altogether and just call the appropriate
vsync operation on the correct device.
(I just tried this experiment on an unrelated project and
it seemed to work - I init a separate ddraw object at startup
time and then call into JNI to call ddraw's WaitForVerticalBlank
function in my paint method. Works like a charm).
Chet.
Dmitri Trembovetski wrote:
Hi Michele,
I didn't work much with JAWT, so I'm not sure what's going wrong
with it, unfortunately.
But some of the things you'll need to make sure:
- the awt and 2d is initialized
- you'll need a realized canvas in order to work with jawt
So your library should accept a realized (that is, added to a
realized/visible hierarchy) Canvas so that you can
get access to the ddraw surface.
So, in your case you'd have something like
public class VideoUtils {
static {
System.loadLibrary(videoutils);
}
public static native void waitForVSync(Canvas c);
}
You might want to make sure that the Canvas is realized/visible in
this method before going to native.
Then on the native level:
JNIEXPORT void JNICALL Java_VideoUtils_waitForVSync
(JNIEnv* env, jclass utils, jobject canvas)
{
JAWT awt;
awt.version = JAWT_VERSION_1_4;
if (JAWT_GetAWT(env, awt) == JNI_FALSE) {
printf(AWT Not found\n);
return;
}
JAWT_DrawingSurface* ds = awt.GetDrawingSurface(env, canvas);
// wait for the vertical retrace
}
I don't see why this won't work.
You might want to check out www.javagaming.org, I believe someone
there was doing something similar.
Also, the good news is that we're considering adding vsync
functionality for mustang:
6378181: 2D needs a way to synchronize onscreen rendering with vertical
retrace
We'll provide the necessary API in the BufferStrategy class.
Your library will still be useful for pre-6.0 jdks, though.
Thanks,
Dmitri
On Fri, Jan 27, 2006 at 10:09:29AM +0100, Michele Puccini wrote:
Thanks Dmitri,
taking a look of some other jawt-dependent implementations (JOGL,LWJGL) I've
discovered that JAWT must be pre-loaded before any other JAWT-dependent DLL
(at least on Win32).
Infact the pre-loding solved all the unsatisfied link error: jawt.ll not
found... problems I had in all my jawt-dependent dlls.
About JAWT initialization I think I'm doing quite well with a little useful
class I've found somewhere. Find it attached. Usage is strightforward:
/*
* Class: it_classx_video_VideoUtils
* Method: createDDraw
* Signature: (Ljava/awt/Component;)I
*/
JNIEXPORT jint JNICALL Java_it_classx_video_VideoUtils_createDDraw(JNIEnv *
env , jobject obj, jobject canvas)
{
__int64 ddraw = 0;
JAWT_Info info(env, canvas);
HWND hWnd = (HWND)info.getHWND();
if (hWnd != NULL)
{
...
}
}
But some problems still remain:
- If the VideoUtils class extends Canvas
- JAWT is not loaded. - CRASH
- JAWT is loaded in the static{} initializer. - WORKS
- JAWT is loaded in the class constructor. - WORKS
- If the VideoUtils class does not extend Canvas
- JAWT is not loaded. - CRASH
- JAWT is loaded in the static{} initializer. - JAWT.DLL not loaded
- JAWT is loaded in the class constructor. - WORKS
Of course VideoUtils must not extend a Canvas as it's not a Canvas in my
design.
Thanks,
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it
From: Dmitri Trembovetski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 26, 2006 10:17 PM
Subject: Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Hi Michele,
sorry for late response.
On Mon, Jan 23, 2006 at 01:04:47PM +0100, Michele Puccini wrote:
Dmitri,
I've managed to create a simple class (VideoUtils) that implements
Vertical
Blanking synchronization with multimonitor support through directdraw
calls
in a separate jni dll. Note: the jawt.dll is delayloaded from my jni
implementation.
Wow, nice.
Anyway I have a strange runtime problem with JAWT:
- if the class extends java.awt.Canvas then it can load and initialize
JAWT
and everything works.
- if it doesn't, JAWT will not be loaded I get an error
java.lang.UnsatisfiedLinkError:
C:\Programmi\Java\jdk1.5.0_06\jre\bin\jawt.dll: Can't find dependent
libraries at
Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Aha...
My simple hack ignored multimon and assumed the code
wanted to vsync on the primary display (wouldn't life
be easier without multimon?); in your case, my simple
approach would not work.
However, if you want to avoid JAWT, I would think you could
get teh information you need somehow at the Java level and
pass it down to your native code to help determine the
correct device. That is, given the bounds of the screen
(GraphicsDevice, GraphicsConfiguration), you should be able to
do various native calls to figure out which ddraw device
that mapped to. On the other hand, it's probably easier to
do this through JAWT, so maybe you're better off with
your current approach...
Chet.
Michele Puccini wrote:
Chet,
as you guessed I need the handle to the window in order to determine the
device (monitor) I'm using. Different devices may have different refresh
rates. In my case I have the main monitor at 75Hz and the PAL second
monitor
at 50Hz.
Here I construct a ddraw object using the native window handle of the java
canvas (using jawt).
// init
DDrawPtr = DirectDrawCreateFromWindow(hWnd);
hMonitor = OneMonitorFromWindow(hWnd);
if (hMonitor != NULL)
{
MonitorInfo.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(hMonitor,MonitorInfo);
}
// then I call
videoutils.waitvbl() from the java side. I don't have any native paint
code.
Working without JAWT can make life simpler. Can you post some code ?
Maybe you may want to take a look at my code. Just ask for it.
Mik
--
- Original Message -
From: Chet Haase [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 30, 2006 3:37 PM
Subject: Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Note that you may be able to get away with vsync'ing without
JAWT; vsync is done on a per-device basis and does not need a
handle to the window. The main reason you'd need to know the
window would be to determine the correct device (display) to
use. If you can determine that some other way, then you
can skip JAWT altogether and just call the appropriate
vsync operation on the correct device.
(I just tried this experiment on an unrelated project and
it seemed to work - I init a separate ddraw object at startup
time and then call into JNI to call ddraw's WaitForVerticalBlank
function in my paint method. Works like a charm).
Chet.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] OT - Swing mailing list?
I'm not sure of the best alias or forum (but I'm pretty sure that they listen in on at least [EMAIL PROTECTED] and that some of the forums end up in their email). But if you're having a machine-specific issue, it could also be a 2D issue, related to graphics drivers. Can you send us the info on the problem and machine specifics? Thanks, Chet. Rosenstrauch, David wrote: Apologies for the off topic post, but I figured someone here might be able to point me in the right direction. Anyone know if there's a swing-specific mailing list? Preferably one hosted by Sun and/or frequented by members of the Swing team. Or are the forums over at javadesktop.org generally the favored place for such questions and discussions. We're having a really bizarre issue occurring in our app on one particular desktop machine, at one particular client site, and I have a feeling I'm going to need some expert Swing help to address this. TIA, DR == This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any transmission errors. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to intercept and monitor all e-mail communications through its networks if legally allowed. Message transmission is not guaranteed to be secure. == === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Layers like Photoshop.
Hi,
There's a lot of questions (implicit or explicit) here
and it'd be tough to answer all of them. I'd suggest
that you pick up a book on Java2D to begin with; that
should help put you on the path for much of this.
In fact, Vincent Hardy's book (hopefully still in print,
but I don't know) actually implements a layers approach
(his GLF framework) that you could use to do some
of what you're talking about.
A couple of other things to keep in mind:
- you generally want to override paintComponent() for
Swing components as your rendering mechanism
- Java2D is an immediate mode API; we don't remember
drawing objects that you've already rendered, we just draw
what you tell us to and then forget about it. However, this
does not stop you from implementing your own retained mode
approach on top of Java2D. There are a couple of ways I can
think of off the top of my head that you could do this:
- create objects that remember how to paint themselves.
When you need to re-render them, just tell the object
to paint itself and it will call the 2D commands
to do the right thing.
- intermediate images: you can draw complex
renderings into an image that you cache for later
re-rendering. This might be helpful in both remembering
rendering operations and saving performance for
complex rendering.
Good luck!
Chet.
[ Fenrir Northern Wolf ] wrote:
Hi there to everyone. I'm starting to learn and work with java about one
month ago and I have some questions that I wonder if someone could help
me, making a sugestions or guide me a lil'.
Someone already implemented some kind of layer thing like Photoshop? I
need something like layers that you can create news, or delete the ones
that you have and what you draw in each layer work independently from
the other layers. I'm doing an application to web that works now like a
simple paintbrush, I did it using BufferedImage and a JPanel to draw in.
I would thank a lot if someone could help me with this, I'm pretty much
lost and don't imagine how to do this layer thing (well, I imagine that
using JLayeredPane maybe O_o).
Other thing, the most important. I did this lil paintbrush like
application, but my problem is that I can not set for each shape that I
draw a style like a different stroke or color, because I use to draw
every shape a single Graphics2D, and I dont know how to recover the
shapes that I already draw if I would like to move them to another place
for example.
I'm a newbie and apologize to disturb everyone with my questions, but I
would that a lot if someone could help me.
(sorry, I don't write very well in english, but I understand everything
that you write.)
here I'm placing the part of my code that I draw the shapes :
public void update(Graphics g){
Graphics2D g2 = (Graphics2D)g;
Dimension dim = getSize();
int w = dim.width;
int h = dim.height;
if(firstTime){
bi = (BufferedImage)createImage(w, h);
big = bi.createGraphics();
big.setColor(Color.black);
big.setStroke (new
BasicStroke(1.0f,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));
big.setRenderingHint(RenderingHints.KEY_ANTIALIASING ,
RenderingHints.VALUE_ANTIALIAS_ON);
area = new Rectangle(dim);
firstTime = false;
}
// Clear the JPanel.
big.setColor(Color.white);
big.clearRect(0, 0, area.width, area.height);
big.setPaint(Color.black);
for (int i=0; i vetorDeFiguras.size(); i++){
/** vetorDeFiguras is a Vector that contains all the Shapes
that I draw in the JPanel and
Figura is a class that have all the java.awt.geom Shapes and
by a flag that is sended to
it manipulate the cordnates sended and draw the shape
according to its type */
big.draw (((Figura) vetorDeFiguras.get(i)).getShape());
}
// desenha BufferedImage na tela
g2. drawImage(bi, 0, 0, this);
}
--
What said Odin to the Gods and to the Champions who surrounded him? We
will give our lives and let our world be destroyed, but we will battle
so that these evil powers will not live after us. Out of Hel's ship
sprang Fenrir the Wolf. His mouth gaped; his lower jaw hung against the
earth, and his upper jaw scraped the sky. Against the Wolf Odin
All-Father fought...
...By Fenrir the Wolf Odin was slain.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body of the message signoff JAVA2D-INTEREST. For general help, send
email to [EMAIL PROTECTED] and include in the body of the message
help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Problem with non-stopping calls to update()
Olof,
I'm not sure of where the mad update is coming from, but you
don't want to call update() from paint; that's actually backwards
from what the system expects.
From the Component javadocs:
The update method of Component calls this component's paint
method to redraw this component.
and:
Subclasses of Component that override this method should
either call super.update(g), or call paint(g) directly
from their update method.
Update calls paint() internally, which means that it calls
your paint, which calls update, which ...
Of course, you've overridden update(), so this changes the
behavior, but it's a bit confusing at the least. But there could
be more wrong here: it could be that by changing the nature of
update/paint interaction, you're getting in the way of the
regular system of issuing and consuming repaint() events, which
could cause the paint calls to keep being issued.
The solution here is to simply override paint() and do your
painting there. Or if you're using Swing, override paintComponent()
instead. Don't override update, or at least not in the manner you
are doing currently.
To improve performance in general:
- use a timer to schedule regular repaints so you don't get
swamped with constant repaint events (similar to what you're
doing, but I don't follow the complexity of using key actions
for this. Why not simply issue a repaint call?)
- only draw the area that's changed. So if only one rectangle
of the playing area has changed, draw that updated region
into the back buffer, and copy that region of the back buffer
into the window.
Chet.
Olof Bjarnason wrote:
Hi there!
I am new to the list, I hope I found the right list to ask this
question, otherwise i appologize and ask for directions of which list
is more appropriate.
I am developing an Applet based 2d game ( a minimalistic SimCity clone
). In an attempt to decrease flickering I skip the
erase-to-background-color default behaviour of paint() by overriding
it and putting my drawing code there instead. paint(Graphics g) simply
calls update(g), as per recommendation in Java API docs:
public void update(Graphics g) {
// Background: map field
g.drawImage(backbuffer, 0, 0, this);
// Foreground: headsup display
headsup.draw(g);
}
public void paint(Graphics g) {
update(g);
}
The headsup-display draws some lines ontop of the background map
image, for example the cursor.
Now the problem is that even though the window (Firefox or
AppletViewer) is left unresized and nothing obscures it, the
update-method gets called repeatedly without-end, giving
less-than-optimal performance, and a lot of flickering.
Even more strangely, when starting the Applet, it works fine (update()
gets called once a second..) for a some 5-10 seconds, then the mad
update()-calling begins. I'm under WinXP, JRE1.4.2. The continuous
update:ing really hogs the CPU (gets up to 90%) which is not good for
a game supposed to be run on a web page while the user listens to
music for example.
Technical details:
In order to drive the simulation, I have a background thread which
approximately once a second fires an ActionEvent on a phony Button
which is a member field of the Applet:
private Button triggerStepButton;
public void run() {
Thread.currentThread().setPriority(1);
while (running) {
ActionEvent ae = new ActionEvent(this.triggerStepButton,
ActionEvent.ACTION_PERFORMED, );
Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(ae);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
run() is a method of my Applet, aswell as triggerStepButton.
triggerStepButton has one listener: the Applet. In the init() method
of the Applet:
triggerStepButton = new Button();
triggerStepButton.addActionListener(this);
So, the Applet has the following signature:
public class TerraformerApplet extends Applet implements Runnable,
ActionListener { ...
The actionPerformed method of the Applet looks like this:
public void actionPerformed(ActionEvent e) {
model.step();
updateBackbuffer();
repaint();
}
... where model contains the SimCity model and it's specific rules.
updateBackbuffer updates the parts of the background image (called
backbuffer) which have changed since last call. The actionPerformed
method is called once a second, even after the mad update:ing has
begun.
Why not call model.step() and updateBackbuffer() in run()? Well I want
to avoid the synchronization hassle needed to make only one thread
Re: [JAVA2D] OT: Getting started with JAI
Hi John, First thing I'd do would be to join the jai-interest email group; they might have better answers to JAI-specific questions like this. (There is overlap between these user groups, but there are many developers that use primarily 2D or primarily JAI...) http://java.sun.com/products/java-media/jai/interestgroup.html Chet. John Wells wrote: Guys, As I mentioned in a past email, I'm pretty new to JAI and imaging in general and am sort of hacking my way through currently. If you were in the same boat, what books or resources would you make sure to read first, aside from the javadocs? There doesn't seem to be any books completely dedicated to JAI, but some mention it. Are there any must reads, either books or websites, that you can recommend? Thanks, as always, for your help. John === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] animating Swing components
David and Ted: You might also check out the Timing Framework project on java.net (http://timingframework.dev.java.net); I wrote this as an example of using timers (see the associated article as well), but also as a utility layer on top of the existing Timer facilities. I hope to add more functionality to it as I get time, but in the meantime I find it a bit easier to use that the Swing timer for the kinds of stuff I do. (for example: it calls your callback function with a float fraction that represents the amount of the duration that's expired, and it lets you set a total duration after which it automatically stops). Rob: I'm talking about this very subject (animating Swing components) in the Advanced 2D session at JavaOne, so c'mon by if you're at the show. Also, come by the Ask the Experts forum on Monday evening (630-800) and the 2D and Swing BOFs on Tuesday nights; other good places to pick our brains on this and other subjects... Chet. David Kavanagh wrote: I agree that the swing timer seems like the better approach. I never really looked at that before. I just had a look at the documentation and source code and it seems like it ends up doing the same thing I was which is submitting user code to run on the event thread at predefined intervals. Whlie I'm not sure it will help my code run better, I'm sure it will make my code look nicer because it handles things that I coded explicitly. I'll give it a try when I get time to play with this again. Thanks David Thus Spoke Ted Hill: Instead of using invokeAndWait from a background thread, I think using a Swing Timer would be a better choice. See: http://java.sun.com/docs/books/tutorial/uiswing/misc/timer.html -Original Message- From: Discussion list for Java 2D API === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] New Ask the Sun Experts forum at JavaOne
For anyone going to the JavaOne conference at the end of this month, we're trying a new thing this year that I have high hopes for: Ask the Sun Experts It's on Monday evening, from 630-800 in an area close to the Pavilion. This is an open forum where most of the Sun engineering teams (2D, Swing, VM, GC, etc.) have tables set up in the same general area. You can wander around, sit down at any table, and chat to the folks on the teams. Think of it as a one-on-one BOF, where it's just general QA, driven by you. Anyway, the conference site does not make this event obvious, so I thought I'd plug it on this alias for those interested. Hope to see you there! Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] flag documentation
Hi Ted, Our documented flags (including the two you listed) are described in more detail here: http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html (although I just noticed a typo in that doc; ddscale was not introduced in 1.2; we didn't even have the capability to do enable it until 1.4...) The OpenGL flag in particular is described more in depth in Chris' article here: http://today.java.net/pub/a/today/2004/11/12/graphics2d.html Also, the folks on the javagaming.org tend to use and discuss the flags (and other performance tweaks) quite a bit. Note: ddscale is probably one of the less quality-driven flags on the market. That is, it is very hard to predict the quality of the results without some serious testing on your target platform and app. We implemented the functionality to use ddraw for scaling operations and then discovered (to my continuing frustration) that there is no way to tell the hardware what filtering algorithm to use when scaling (nearest neighbor, bilinear, etc.). This means that on one video card you may get scaling that looks jaggy, while on another you may get smoothed-out scaling. Even worse; if you are also running through our software scaling algorithms for some operations in your app (for example, suppose you are scaling inside a complex clip shape; that probably won't be done through our ddraw pipeline), then you could end up with scaling operations side-by-side that use different filtering approaches; not a pretty result. This is why ddscale is a flag that you have to enable, and not something we turn on by default. (Side note: Direct3D _does_ allow finer control of scaling filters, so in Mustang with our new D3D support (also enabled by a flag) you will actually get what you want during a hardware scaling operation). More information than you wanted, I guess... Chet. Ted Hill wrote: Hello, Where are flags like the following documented/discussed? -Dsun.java2d.ddscale=true -Dsun.java2d.opengl=true Thank you, Ted Hill === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] JTable handling
Leonid, This is a 2D forum - you would be better off posting this to a Swing forum or alias instead (check out the forums on javadesktop.org for starters). Chet. Leonid Pavlov wrote: Hi all, I have a jTable with columns date_from, date_to, description. I would like to protect the editing(getting the focus) of date_to and description when the date_from is null. Have you any idea how to provide this? When possible with example please... Regards Leonid Pavlov === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Wanted: apps to be tuned....
We're looking for entries for a couple of JavaOne talks on tuning apps to look better and run faster. Do you have or know of an app that we can use for this case study? Check out this blog for more detail on this. There's an email address for submissions on the blog site. http://weblogs.java.net/blog/chet/archive/2005/03/jdg_seeks_bad_c.html Thanks, Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] drawString() on Graphics2D question
Another alternative (preferable to creating a Shape, I think) is to render the string into an Image, and then rotate the image. Or better yet: render the rorate string into the image, and then just copy the image (no transform involved). This approach is not worth the hassle if you are constantly changing the string orientation, or if you are only rendering it once. Butif you are constantly rendering the same string at the same orientation, then it might be worth the hassle/ memory-footprint tradeoff to get a performance boost from doing a simple image copy instead of a transformed text operation. Worth mentioning as an option, anyway. Chet. Alexey Ushakov wrote: I think that first approach is more preferable. Shape of the string is just outline of the string. It does not contain all necessary information (like hinting for example) for drawing string. This could affect quality especially in case of strings of small sizes. Though, such approach could be used with strings of large sizes for performance reason. Alexey On Tue, Mar 22, 2005 at 10:32:27AM -0500, Nidel, Mike wrote: The answer to your first question is relatively simple: Before you draw the string, you can do a transform() on the Graphics2D. You pass in an AffineTransform that you create with AffineTransform.getRotateInstance(theta). Alternatively you can convert the string to a Shape and perform a rotation on the Shape itself. As for your second question, I don't think I can help you there. This information will change depending on whether you're using anti-aliasing or not. You may be able to convert your string into a Shape and do some kind of operation to iterate over all of the pixels in the shape... but I'm not sure. Mike -Original Message- From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED] Behalf Of Sven Mielordt Sent: Tuesday, March 22, 2005 10:21 AM To: [EMAIL PROTECTED] Subject: [JAVA2D] drawString() on Graphics2D question Hi fellows, I have a short question concerning drawString() on Graphics2D. When using it, the string is printed horizontally. But how can I print text vertically or at arbitrary angles??? A refining question concerns the number of pixels needed for the string. Is there any method to find out how many pixels in all directions will be occupied? Thank you, Sven __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] drawString() on Graphics2D question
Clarification: Another alternative (preferable to creating a Shape, I think) is to render the string into an Image, and then rotate the image. As well as the string itself an image will carry the background with it so this is probably not the best way to go for most people. You can create an image with a transparent background and render the text to it. When you copy the image, only the text pixels will be copied. There's sample code for doing just this in the Intermediate Images article on java.sun.com. And except for quadrant rotations I would not expect great results. Not sure what this means - rendering the string to an image and then copying the image to the screen (or back buffer) should give you exactly the same results as rendering the string directly to the screen/back-buffer. Rotating the image may give you different results than rotating the string, but if you take the better yet suggestion for pre-rotating the string into the image, then the results should be exactly the same. But I agree that this is really only a workaround for current lack of acceleration for this operation; we hope to handle all of this implicitly in future releases. Chet. Rotate the graphics and draw the text along the lines of a previous poster is the most straightforward solution and that will get accelerated too in the future and is fairly snappy even in software. As for measuring the text, there are many APIs for this - too many! But the only one that is trying to be pixel perfect is java.awt.font.GlyphVector.getPixelBounds() which is however consequently expensive and won't work for complex text. Try to use something like java.awt.font.TextLayout.getBounds() for that - its not going to be as pixel perfect but will work for complex text. You may even be able to get away with java.awt.font.GlyphVector.getVisualBounds() if you don't use complex text. Did I mention there are a lot of APIS for this? In fact I probably still missed one .. -phil. Chet Haase wrote: Another alternative (preferable to creating a Shape, I think) is to render the string into an Image, and then rotate the image. Or better yet: render the rorate string into the image, and then just copy the image (no transform involved). This approach is not worth the hassle if you are constantly changing the string orientation, or if you are only rendering it once. Butif you are constantly rendering the same string at the same orientation, then it might be worth the hassle/ memory-footprint tradeoff to get a performance boost from doing a simple image copy instead of a transformed text operation. Worth mentioning as an option, anyway. Chet. Alexey Ushakov wrote: I think that first approach is more preferable. Shape of the string is just outline of the string. It does not contain all necessary information (like hinting for example) for drawing string. This could affect quality especially in case of strings of small sizes. Though, such approach could be used with strings of large sizes for performance reason. Alexey On Tue, Mar 22, 2005 at 10:32:27AM -0500, Nidel, Mike wrote: The answer to your first question is relatively simple: Before you draw the string, you can do a transform() on the Graphics2D. You pass in an AffineTransform that you create with AffineTransform.getRotateInstance(theta). Alternatively you can convert the string to a Shape and perform a rotation on the Shape itself. As for your second question, I don't think I can help you there. This information will change depending on whether you're using anti-aliasing or not. You may be able to convert your string into a Shape and do some kind of operation to iterate over all of the pixels in the shape... but I'm not sure. Mike -Original Message- From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED] Behalf Of Sven Mielordt Sent: Tuesday, March 22, 2005 10:21 AM To: [EMAIL PROTECTED] Subject: [JAVA2D] drawString() on Graphics2D question Hi fellows, I have a short question concerning drawString() on Graphics2D. When using it, the string is printed horizontally. But how can I print text vertically or at arbitrary angles??? A refining question concerns the number of pixels needed for the string. Is there any method to find out how many pixels in all directions will be occupied? Thank you, Sven __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED
Re: [JAVA2D] Upcoming SDN chat
Good idea; we can try to do that in the future. We actually don't have that many chats directly related to 2D, so I don't think anyone's missed that many. The chat next week should be interesting, as we'll cover both the graphics (me) and toolkit (Scott Violet) worlds. Chet. Nidel, Mike wrote: I discovered that there is an upcoming chat on the subject Getting high performance from your desktop client on February 15. http://java.sun.com/developer/community/chat/index.html I have attended one or two of these before, and read transcripts of others. But I have also missed a few that I would have liked to attend. Do you think it would be possible and useful to send an announcement to this list when a chat related to Java2D is coming up? Regards, Mike Nidel === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Must all drawing be performed on the EventQueue thread?
Hi Dan, This should work fine. In fact, some server apps take advantage of this by using Java2D to render images on separate threads that take advantage of multiple processors. The only trick here is making sure your different threads (rendering thread(s) and EventQueue thread) are doing the right things at the right time. For example, make sure your rendering thread is finished drawing by the time you add the image to your component on the EventQueue thread. Chet. Dan Blanks wrote: I know that when I draw to the graphics context of a component, it's important to draw everything on the EventQueue. But does that rule also apply to an internally created image? For example, if I code: BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); Graphics2D gc = (Graphics2D) image.getGraphics(); gc.drawRectangle(100, 100, 300, 400); gc.dispose(); Since the image is not displayed yet, I would think it is kosher to call this code from a non-EventQueue thread. Adding the image to a component, of course, would have to occur on the EventQueue thread. Am I correct in this assumption, or off-base? Thanks, Dan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] lot of time in blitSurfaceData
Ah, that's better. From this configuration, it seems like: - Swing _would_ have an accelerated back buffer (they started using VolatileImage in 1.4.0, and that should be (very) accelerated on your system. - Some other image types would also be accelerated (VolatileImage, and managed images created through specific APIs like Component.createImage(w, h) and GraphicsConfiguration.createCompatibleImage(w, h)). The only causes of huge amounts of time in Swing buffer copying that occur to me right off are: - Maybe the Swing buffer is getting punted: if you are doing lots of read or read-modify-write operations to the back buffer, then we may choose to punt it into system memory. Note that this will also happen if you are simply doing translucent operations (like translucent image copies) to the buffer, or _lots_ of anti-aliased text ops. For kicks, try running with -Dsun.java2d.ddforcevram=true to see if forcing the back buffer to stay in VRAM changes the characteristics at all. (Note that there's a good reason for us to punt; if you _are_ doing lots of read-modify-write ops to that buffer, those will probably kill your performance way before copying that buffer from system memory to the screen will). - Maybe the bottlenecks you are seeing are actually coming from some other operation in your app (not the Swing back buffer copies). Without knowing anyting about your app, it's pretty tough to tell... - Maybe you're forcing repainting so often that no matter how accelerated these copies are you're still spending most of the time updating the screen. Hope that helps... Chet. [EMAIL PROTECTED] wrote: Sorry for the sparse description. Here's the info: JDK 1.4.2_03 Windows XP (SP 1) nVidia Quadro FX 500/600 128 MB, AGP, Aug/Sep 2004 driver dual monitor Calls GraphicsDevice.getAvailableAcceleratedMemory() tell me there's 100MB left when application is running. -Original Message- From: Chet Haase [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 7:18 PM To: Peterson, Brian Cc: [EMAIL PROTECTED] Subject: Re: [JAVA2D] lot of time in blitSurfaceData Hi Brian, it's pretty impossible to tell what's going on from your description. What release of Java are you using? What platform are you running on? if you're on Windows, what graphics card are you using? All of these items (and more) contribute toward our ability to accelerate images in general and Swing's back buffer in particular. Thanks, Chet. Brian Peterson wrote: I have an application that is spending 25% of its time in sun.java2d.pipe.DrawImage.blitSurfaceData 19% of which comes from paintImmediately calls from the RepaintManager (call trace at end of message). Are the offscreen buffer images for my windows or subcomponent JPanels not getting accelerated? Or is this normal behavior? Brian javax.swing.RepaintManager.paintDirtyRegions() javax.swing.JComponent.paintImmediately() javax.swing.JComponent._paintImmediately() javax.swing.JComponent.paintDoubleBuffered() javax.swing.JComponent.paintWithOffscreenBuffer() sun.java2d.SunGraphics2D.drawImage() sun.java2d.SunGraphics2D.drawImage() sun.java2d.SunGraphics2D.copyImage() sun.java2d.pipe.ValidatePipe.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.RenderSurfaceData() sun.java2d.pipe.DrawImage.blitSurfaceData() = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] lot of time in blitSurfaceData
The BufferedImage objects definitely won't be accelerated due to your use of DataBuffer. You might think about using BufferedImage or WritableRaster API calls to set the pixel values, but depending on how much pixel-setting you're doing the pixel-sets may end up being more important to accelerate than the managed image copies. Copying the images to the back buffer won't cause the back buffer to punt unless the images are translucent (RGBA or whatever); that would cause us to lock the back buffer for read-modify-write, even if the source pixels actually don't have any translucency. So use opaque images if you can. You may also be hitting the bottleneck of simply copying these images down to the back buffer. That is, maybe your bottleneck isn't in getting Swing to update the screen, but in getting your unaccelerated images to copy to the back buffer. 10 times a seonc isn't a lot for one image, but how many images are they? How large are the images? it could be a lot of pixels we're pushing down the bus every second... I don't know if the lines would be causing a problem or not. I have seen situations where context-switching between the different rendering libraries we use (direct3d, ddraw, GDI) can affect performance. But I don't know if that would be the case here (especially with the modern video card/driver you have). You could try disabling d3d to see if that affects things: -Dsun.java2d.d3d=false Chet. Brian Peterson wrote: Good info -- thanks. A repaint is called on these dominate subpanels about 10 times a second. The application uses drawImage a lot. Most of the windows are panels that simply drawImage from an intermediate BufferedImage in its paintComponent. I doubt that these intermediate images are accelerated because I end up getting the DataBuffer to directly draw individual pixels. There's another subpanel that ends up drawing about 500 lines every repaint (10/sec). Would either of these trigger the punting you describe? I don't do any anti-aliased text. Or at least I don't think I do -- I always use the graphics hint to not anti-alias text. I'll try the parameter and see what happens. Thanks, Brian -Original Message- From: Chet Haase [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 21, 2004 7:34 PM To: Peterson, Brian Cc: [EMAIL PROTECTED] Subject: Re: [JAVA2D] lot of time in blitSurfaceData Ah, that's better. From this configuration, it seems like: - Swing _would_ have an accelerated back buffer (they started using VolatileImage in 1.4.0, and that should be (very) accelerated on your system. - Some other image types would also be accelerated (VolatileImage, and managed images created through specific APIs like Component.createImage(w, h) and GraphicsConfiguration.createCompatibleImage(w, h)). The only causes of huge amounts of time in Swing buffer copying that occur to me right off are: - Maybe the Swing buffer is getting punted: if you are doing lots of read or read-modify-write operations to the back buffer, then we may choose to punt it into system memory. Note that this will also happen if you are simply doing translucent operations (like translucent image copies) to the buffer, or _lots_ of anti-aliased text ops. For kicks, try running with -Dsun.java2d.ddforcevram=true to see if forcing the back buffer to stay in VRAM changes the characteristics at all. (Note that there's a good reason for us to punt; if you _are_ doing lots of read-modify-write ops to that buffer, those will probably kill your performance way before copying that buffer from system memory to the screen will). - Maybe the bottlenecks you are seeing are actually coming from some other operation in your app (not the Swing back buffer copies). Without knowing anyting about your app, it's pretty tough to tell... - Maybe you're forcing repainting so often that no matter how accelerated these copies are you're still spending most of the time updating the screen. Hope that helps... Chet. [EMAIL PROTECTED] wrote: Sorry for the sparse description. Here's the info: JDK 1.4.2_03 Windows XP (SP 1) nVidia Quadro FX 500/600 128 MB, AGP, Aug/Sep 2004 driver dual monitor Calls GraphicsDevice.getAvailableAcceleratedMemory() tell me there's 100MB left when application is running. -Original Message- From: Chet Haase [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 21, 2004 7:18 PM To: Peterson, Brian Cc: [EMAIL PROTECTED] Subject: Re: [JAVA2D] lot of time in blitSurfaceData Hi Brian, it's pretty impossible to tell what's going on from your description. What release of Java are you using? What platform are you running on? if you're on Windows, what graphics card are you using? All of these items (and more) contribute toward our ability to accelerate images in general and Swing's back buffer in particular. Thanks, Chet. Brian Peterson wrote: I have
Re: [JAVA2D] Help with image!
Seems like the most straightforward way to do this would be to use the drawImage() variant that takes source and dest rectangles, that is: public boolean drawImage(Image, dx1, dy1, dx2, dy2, sx1, sy1, sx2, sy2, ImageObserver) Using this method, you can specify the source rect as the area you want to copy from and the dest rect as the matching area at whatever (xy) location you want. I confused by your desire to start from y=600 and grab an area of height=600 from an image that's only 768 pixels high; I assume that's a typo (or if not you must want the area clipped at that height?) Chet. Rafael wrote: Hey people! =) I want to know how can I draw a specificarea of an image in any point X, Y ofmy frame. Example: I have an image of 1024x768 pixels and I just want to draw thearea X=1, Y=600, Width=500 and Height=600 in the points 0, 0 ofmy frame. Plz, Could someone help me? Thanks! === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Using a slower sun.java2d.pipe.DrawImage.renderSurfaceData() ?
Brian, My quick take on this is that you've run out of VRAM eventually and this latest window is creating a back buffer (or any other offscreen images) in system memory. When that's the case (as it was on jdk 1.3.1 and previous versions), we spend a lot of time just pumping pixels down from the CPU to the framebuffer. Make sense? Chet. Brian Peterson wrote: I have a window that is taking up a lot of CPU from the EDT to draw, whereas several other windows doing similar operations do not. When I profile (using OptimizeIt) showing just this problematic window, I get that the AWT-EventQueue-0 thread spends 34% of its time in sun.java2d.pipe.DrawImage.blitSurfaceData(): 34.20% - 3330 ms - sun.java2d.pipe.DrawImage.renderSurfaceData() getting there from java.awt.EventQueue.dispatchEvent(). When I profile showing just a non-problematic window, this thread spends only 3% if its time in renderSurfaceData. In fact, they have very different sets of calls for under RepaintManager.paintDirtyRegions(). (I've attached the two profiles -- data.html is for the problematic window.) [I tried attaching in a previous post, but I think my mail tool had a problem with them. I've listed the callstacks following this text. Sorry if this ends up being a duplicate post. Having many problems with mailtool.] I even commented out the majority of what is displayed so that the window is pretty much blank, but is still using about half of the CPU. What would cause one window to use a slower renderSurfaceData? Brian Slower window callstack from profile: java.awt.EventDispatchThread.run() java.awt.EventDispatchThread.pumpEvents() java.awt.EventDispatchThread.pumpEvents() java.awt.EventDispatchThread.pumpEventsForHierarchy() java.awt.EventDispatchThread.pumpOneEventForHierarchy() java.awt.EventQueue.dispatchEvent() java.awt.event.InvocationEvent.dispatch() javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run() javax.swing.RepaintManager.paintDirtyRegions() javax.swing.JComponent.paintImmediately() javax.swing.JComponent._paintImmediately() javax.swing.JComponent.paintDoubleBuffered() javax.swing.JComponent.paintWithOffscreenBuffer() sun.java2d.SunGraphics2D.drawImage() sun.java2d.SunGraphics2D.drawImage() sun.java2d.pipe.ValidatePipe.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.renderSurfaceData() sun.java2d.pipe.DrawImage.blitSurfaceData() Faster window callstack from profile: java.awt.EventDispatchThread.run() java.awt.EventDispatchThread.pumpEvents() java.awt.EventDispatchThread.pumpEvents() java.awt.EventDispatchThread.pumpEventsForHierarchy() java.awt.EventDispatchThread.pumpOneEventForHierarchy() java.awt.EventQueue.dispatchEvent() java.awt.event.InvocationEvent.dispatch() javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run() javax.swing.RepaintManager.paintDirtyRegions() javax.swing.JComponent.paintImmediately() javax.swing.JComponent._paintImmediately() javax.swing.JComponent.paintDoubleBuffered() javax.swing.JComponent.paintWithOffscreenBuffer() javax.swing.JComponent.paint() javax.swing.JComponent.paintChildren() javax.swing.JComponent.paint() javax.swing.JComponent.paintChildren() javax.swing.JComponent.paint() javax.swing.JComponent.paintChildren() javax.swing.JComponent.paint() javax.swing.JComponent.paintChildren() javax.swing.JComponent.paint() javax.swing.JComponent.paintChildren() javax.swing.JComponent.paint() javax.swing.JComponent.paintChildren() javax.swing.JComponent.paint() javax.swing.JComponent.paintComponent() javax.swing.plaf.ComponentUI.update() === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Non-heap memory usage?
Brian, There are a lot of mysteries in memory usage, both what is using what, and how it is reported in TaskManager. It is possible that we are using memory in other parts of the system; for example, we use shared OS libraries that might allocate their memory in another process entirely (and that thus would not show up as attached to your process' heap). But 1G is a lot of memory... As for VRAM, I'm not sure that would hit the radar of TaskManager. We use DirectX to allocate memory on your video card, but I don't think that memory is tracked in either your process or any other; it's just an extra lump of memory attached to an external device (the GPU). I really doubt that TaskManager would report that memory as attached to anything on the system (TM only deals with the system heap, as far as I know). It might be possible that when we try to allocate more memory than you have VRAM that the system starts allocating memory in Non-Local Video Memory, which is system memory accessible by the AGP bus. It could also be possible (just guessing here; haven't ever run tests on this) that that memory is reported against the DirectX process, or some other system process. Still, 1G is a _lot_ of memory. If you have a screen resolution of 1280x1024 and are allocating images of that size in 32bit color, it would take about 200 images to suck up that kind of footprint. Here's a couple of tests to run: - When you create an image, note it's size (w x h x depth) and keep a running total (maybe print it to the command line). (Be sure to subtract that number when an image goes out of scope...) - When the app quits, is the current memory usage by images reflective of the memory numbers you are seeing in TaskManager? - Is there any other process in TaskManager that reports having that kind of memory usage? That is, when you see your system get back 1G of memory after the app quits, where did it come from? And here's a tip if you are using a lot of memory: - don't hold onto images longer than you need to. if the system can GC them, you'll get back all of that memory in short order. And look into using Image.flush() to flush any accelerated-memory cache associated with a managed image or VolatileImage (if you aren't using that image currently). Chet. Brian Peterson wrote: I have a graphics-intensive application that uses Java2D and BufferedImage extensively on a Windows XP platform. The Windows Task Manager tells me that the java process is using about 300MB of memory, but when I exit out of the application, the overall memory usage of the system drops by almost 1G. I have no experience with non-heap memory usage. Could Java2D be using memory that is not accounted for in the process list of the Task Manager? Could my graphics card be grabbing lots of memory? Any insights or suggestions would be greatly appreciated. Brian === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why isn't there a method for drawing Point2Ds, pixels, and the like
Right - there's no API for drawing points explicitly. We could add something like this as a convenience in some future release, but in the meantime it should be a pretty easy constraint to work around. You don't need to create rects or anything else; you just need to draw a one-pixel rect or line to do what you want. if you have a point (x, y), drawing a pixel at that point should be as easy as: Graphics.drawLine(x, y, x, y); or Graphics.drawRect(x, y, 0, 0); or Graphics.fillRect(x, y, 1, 1); Chet. Gregory Pierce wrote: While running some tests on a program that generates a dataset of (x,y) pairs I decided that I would render them so I could see how the data was distributed visually. Almost immediately I ran across an interesting limitation: Except for Point2D and Dimension2D, each of the geometry classes (geometries) implements the Shape interface, which provides a common set of methods for describing and inspecting two-dimensional geometric objects. No biggie, I thought, I guess they aren't really 'shapes' so I'll just draw them using Graphics2D. Hmmm... wait there is no method in Graphics2D to draw them either. Ugh, that means I have to create one pixel sized rectangles to draw points? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why isn't there a method for drawing Point2Ds, pixels, and the like
An RFE never hurts. We're aware of this issue, but filing an RFE ensures that it will stay on our minds (it doesn't ensure a fix; we have to weigh the pros of utility methods against the cons of API bloat, but it will at least keep the issue alive). By the way, my previous suggestions on how to draw a pixel were ignoring important performance implications (silly me): Graphics.fillRect() is really the best and only way you should accomplish a simple pixel drawing command. drawLine() tends to have more overhead because lines can have attributes associated with them that we need to check. drawRect() is essentially four drawLine() commands (or at least extra logic to eliminate redundant lines), so that's not the way to go either. fillRect() is your friend. Just think of a single point as a very small rect. Chet. Gregory Pierce wrote: Do I have to fill out an RFE or similar for something like this? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] java2d.opengl=true
Hi Ted, I'm not sure what level of acceleration you are looking for, but there is already hardware acceleration by default on the Windows platform on nearly any driver/card combination. However, this acceleration is only for the most rudimentary operations (rectangular fills and copies); this results in much better performance for simple GUI apps (everything but text tends to get hw-accelerated), but doesn't do much for apps that really drive the 2D features. The new OpenGL pipelin in Java2D enables much more acceleration capabilities (for things like translucency, transforms, and anti-aliased text) in addition to the basics. The catch is that our use of OpenGL requires certain features which are not enabled on some hardware (especially older hardware) or which some drivers do not accelerate. Also, since we tend to use the hardware and drivers in different ways than typical GL apps (we are not Quake...), we have seen problems with both robustness and performance on some platforms. For example, the latest Windows ATI drivers seem to have a problem not crashing when we are using GL. Thus, our decision to only enable GL acceleration with a runtime flag: sun.java2d.opengl=true. It's there for people that really want to try it out, to see if it works on their specific runtime platform. It's not advisable to enable it for an app that ships on unknown platforms due to the issues I mentioned above. There is more info about our OpenGL support here: http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html (I got to this by drilling down on a few links from the 5.0 release page). Good luck! Chet. Ted Hill wrote: Hello, I recently read that JDK 1.5 will get native hardware acceleration from Java2D if they have the latest OpenGL drivers and select graphic cards. Where can I get more information about this. We will be running on Windows XP. Thank you, Ted Hill === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] java2d.opengl=true
I was thinking more in line of having a checkbox in a config that the user could check once they wanted to check OpenGL acceleration. So I wanted to allow the app to start unaccelerated, then have the user go into the application preferences and click Enable OpenGL Acceleration. The only way this could work is if you spawned a new Java process based on a change to this setting; we read the opengl parameter (whether in main() or on the command-line) at process startup time (when AWT/2D is first initalizing). We have no facility for switching gl support once we've started up. Now one quick question comes to mind with respect to my other application. If translucency isn't currently hardware accelerated - is Java actually doing pixel tests for overlapping translucent objects? If so, that would explain my performance woes. I would only want to draw translucent stuff if I knew it was hardware accelerated. There's a couple of answers here: - You could also try out d3d translucency acceleration. This is also disabled by default (also due to robustness issues, but driver support seems much better for this capability and we were actually on the verge of enabling this by default in 5.0). You can enable this with -Dsun.java2d.translaccel=true. This forces us to use Direct3D for translucent image operations (such as drawImage() where the source image has alpha). Note that this does not speed up other translucent operations (lines with alpha colors, etc.). But when it works (which it should on most modern graphics accelerators), it give sa huge boost in translucent image performance. Note that we also init d3d support at process startup time, so you also cannot switch this capability on the fly. - By default, we're not accelerating translucent operations of any kind. This means that we're doing read-modify-write on the destination pixels. This is a hideously expensive operation when the destination lives in video memory; reading from VRAM is one of the slowest operations known to man, measurable more in geologic ages than clock cycles. One workaround we have internally is that when we detect a large number of reads from VRAM compared to the number of accelerated copies from that surface (for example, if you read or read-modify-write over an eighth of the buffer on any given frame) we will punt this destination buffer to system memory, where reading is much faster. This means that the translucent operations go faster, although it defeats acceleration for opaque operations to/from that buffer. So yes, this could be the source of your performance woes. Try out opengl. Try out d3d (translaccel)). See if they help address your problems. Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Transparent internal frames
Hi, It's pretty difficult to know from your quick description where the problem would lie. There is no inherent problem with using transparent internal frames in Swing, but you need to make sure to set and use the opacity property of the component(s) appropriately and to do the right thing during paintComponent(). Other than that very high-level suggestion, it's hard to know what else to say. There could be a bug lurking here in how we implement scrolling (devCopyArea) on translucent components, but a test case would sure help... Chet. Clifford Lyon wrote: Hello list, I have a Java 2D application where I show an image, and then display a transparent internal frame over the image that exposes controls to the user for adjusting parameters. Everything works fine, except when moving the knob on my JSlider, the internal frame background fills with random stuff. Any way around that? Custom painting? tia === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] calling repaint()
Hi Rob,
repaint() does the right thing - it queues up a request to call paint on the
component on the right thread at some later time. This means, of
course, that
repaint() is an asynchronous request; it will return to the caller as
soon as the
request has been posted, and not necessarily after the paint has
actually occurred.
In any case, feel free to use repaint() from whatever thread you want;
that's what
it's there for...
Chet.
Rob Ross wrote:
This is semi-swing related, but since there's not a swing-interest list and since it's
also semi 2D related, I thought I'd try here.
I learned this past JavaOne that every swing app I have ever written has been broken,
as I often do
public static void main(String[] args)
{
JFrame f = new JFrame();
f.setVisible(true);
}
when in fact I should be calling this from the event handling thread via a
SwingUtilities.invokeLater() call.
My question is, can I call repaint() on a component from another thread, or does that
also have to be called from within the event thread? Doesn't repaint just queue a
request for later processing anyway? If so, why would I need to spawn a separate
thread just to call the repaint?
Rob
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Pixel collision in games with 2D api
Keith's right on the general ideas of Volatile vs. BufferedImage acceleration, but let me correct/clarify some of the details: - GraphicsConfiguration.createCompatibleImage() will create a VRAM-cached accelerated copy of the BufferedImage and you will benefit from hardware acceleration as available on 1.4. This was not something new in 1.5, but has been there since 1.5. Other managed image APIs that create this acceleratable cached version of the image include Component.createImage(w,h) and (I think) Toolkit.loadImage()/(new ImageIcon()).getImage(). - New in 1.5 is the ability to get a managed image from _any_ image creation method, including new BufferedImage(w, h, type). Same acceleration functionality as described above, but now you don't have to call particular APIs to get that capability. - The main reason for dealing with VolatileImages is if you need/want rendering _to_ the image to be accelerated, or if you will be modifying the image frequently but still want copies from the image to be accelerated. A common case for this is back buffers; the Swing back buffer is a VolatileImage. Otherwise, managed images (as described above) are way less hassle but have the same benefits of fast copies (Blts). For more nitty gritty details on BufferedImage and VolatileImage objects and random acceleration tips, check out the BufferedImage and VolatileImage blogs on javadesktop.org. Chet. Keith Lea wrote: If you're targeting JDK 1.5, you can use an accelerated BufferedImage instantiated from a GraphicsConfiguration (with the createCompatibleImage method), which is stored in memory but also cached in your video card's VRAM. I'm not sure what blting is, but BufferedImage probably provides the fastest and easiest way to copy image data to other BufferedImages and to the screen. If you need JDK 1.4 compatibility, you should use VolatileImage, probably backed by a BufferedImage (which is not, in 1.4, stored in VRAM). VolatileImages are stored in VRAM like 1.5's accelerated BufferedImage. (You could also use VolatileImage in 1.5, but for most applications it's not worth the extra code required when BufferedImage is mostly just as fast.) -Keith Lincoln Quirk wrote: So if someone could help me out -- how do I create a region that I can do some low-level, fast blt'ing to? Or, if you have a better idea on how I should implement my physics that takes better advantage of Java, some ideas about that would be good too. Thank you, Lincoln Quirk === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] transparent windows yet?
Rob and Mark,
The solution below will work for lightweight components, but not for
toplevel windows (which is what I assume Rob asking about).
We do not yet (as of 1.5) have the capability of transparent/translucent
toplevel Windows. Yes, the capability exists on some platforms. One of
the tricks in making this work in the library is handling it in a
cross-platform-friendly way.
Anyway, it's one of the things we are hoping to implement
in the next release.
(There are always hack workarounds like using an undecorated frame,
capturing the background of the desktop with Robot, and then
painting the background on top of the frame, but you're probably looking
for something a bit more standard and dependable...)
Chet.
- Original Message -
From: Mark McKay [EMAIL PROTECTED]
Date: Saturday, May 29, 2004 7:30 am
Subject: [JAVA2D] transparent windows yet?
Call setOpaque(false); on your window. Then, when you repaint it, do
something like:
public void paintComponent(Graphics g)
{
Composite oldComposite = g.setComposite(AlphaComposite.Clear);
g.fill(getBounds());
g.setComposite(oldComposite);
//Rendering code
}
Mark McKay
Rob Ross wrote:
I'm in the middle of a project where being able to make a window's
background
translucent/semi-transparent would be a very very cool thing
to have.
Is this possible yet with 1.4? If not, how about 1.5?
Is this feature really that hard to implement?
I'm asking honestly, I don't know what's required in the JVM to
make this happen. But since both OS X and WindowsXP seem to do
this all the
time now, I have to assume most of the hard code already has been
written in those platform's native libraries.
Rob Ross
Senior Software Engineer
E! Networks
[EMAIL PROTECTED]
===
To unsubscribe, send email to [EMAIL PROTECTED] and include
in the
body
of the message signoff JAVA2D-INTEREST. For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message signoff JAVA2D-INTEREST. For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] getting the vertical retrace
Hi Tom, We do not have an API to sync to the retrace or count the number of retraces, but: - A fullscreen/exclusive app on Windows will perform flipping (using BufferStrategy) sync'd to the retrace interval - The DisplayMode API can be used to query the current refresh interval. (Note that some OSs (NT4?) will return a most helpful 0 for the refresh rate, but otherwise this may give you the info you need). Note that you can get the current DisplayMode for a give GraphicsConfiguration, so this should work even in the multimon case. Chet. Tom Busey wrote: I'm developing some applications where we need to precisely control how long an image is on the screen. We typically do this in C by drawing an image to the screen and then counting screen refreshes before erasing it. Java double buffering must do something similar to avoid flicker. Are there any routines to get access to the vertical refresh interval? I realize that this is somewhat complicated, give than multiple monitors might be in use and a window might span more than one monitor, but any starting points would help us out. Thanks, Tom Busey [EMAIL PROTECTED] === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] transparent gif
Flavius, I belief GIF only supports transparent (not translucent) images. However, you can always set the AlphaComposite on the destination Graphics object to be translucent before you call drawImage() with your sprite. Chet. Flavius Alecu wrote: how can I use sprites in gif format and have them partially transparent? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] bug-id 5008045 (OpenGL for Win ?)
Mik, Last question: Are you (SUN) going to make an official announcement of the upcoming new hardware accelerated Java2D technology in close time ? Answering these questions on the interest list and posting whitepapers on performance and features is about as official as we get. I doubt there's going to be a speech by Scott McNealy on Java2D acceleration anytime soon, if that's what you were interested in... We're not making a huge deal out of the OpenGL support currently because it is disabled by default due to the driver and hardware issues that have already been mentioned. With flag-enabled acceleration, it's more important to get the message out to the right community; developers who would like to experiment and see how well it works for them in their situations. Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] TransAccel
Hi Mik, A simple question about a relatively complicated subject... You have tripped upon the internal rasterStolen variable that we use to detect when someone has accessed the Raster/DataBuffer of a managed image. We can accelerate managed images only when we know exactly what is going on with the main copy of that image. That is, if we can detect when that main copy changes, then we know when to update our accelerated cache of that image. But the API you are using to access the pixels (getDataBuffer()) defeats this approach because we can no longer detect when the main copy has changed. That is, when you have array access into the pixel data, we cannot easily detect when you change values in the array, thus we cannot know when the original copy has changed and our cached version nees to be updated. So we punt. There may be better ways for us to manage this internally in the future, but for now we simply detect the case where someone has gotten direct access to the pixel data and turn off acceleration for that image. The best ways to access the data in a managed image without causing this punt are any methods that render to the image without returning the data buffer. This includes the setPixel methods in Raster and the setRGB methods in BufferedImage; both of these change the data without giving you arbitrary access to the data, so we can detect that the data has changed and update the cached/accelerated image appropriately. Another approach is to render to a different image (perhaps a translucent or transparent one) and then use drawImage() to copy the data in. Finally, you can always use the standard rendering primitives to tweak the data (drawLine(), fillRect, etc.). None of these may be the fastest in the world for setting pixel data, but at least they will allow you to set the data without defeating acceleration. The current state of hw accelerated images is that they work well for static data, but are suboptimal for dynamic data. This is just a result of the kinds of things we needed to accelerated first in our long road toward full-on hw acceleration of everything. The approach you use in your app depends on the performance tradeoff between changing the pixel data in the image versus copying those images to some accelerated surface (e.g., the back buffer). For some applications, it might work out better to have dynamic sprites/images in software because our read/write access to that data is much faster than when those images are stored in VRAM. But if you are not changing those sprites/images too frequently, then you will probably do better by leaving them in VRAM so that they benefit from the hw accelerated copy operations. As always, benchmark if you need to know the Right Answer for your situation. Chet. Michele Puccini wrote: Hello, a simple question: I tried to access the pixels directly through Raster-DataBufferInt but as soon as I call: DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer()); the image becomes non accelerated and there's apparently no way to re-accelerate it. I also noticed that setting the raster pixels with: raster.setPixel(x,y,a,r,g,b); works, but I suppose this solution gives very low performance. so the question is: which is the bset way to change the pixels of an accelerated (managed) image on the fly ? Cheers, Mik of ClassX ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Flickering Animation
Mark, I'm not sure about some of the issues you raise (such as the shake effect you are seeing), but the simple Blt's of images to the screen can trigger tearing artifacts due to not being sync'd the the vertical retrace of the screen. The best way to get smooth (non-tearing) animation is to use a fullscreen flipping buffer instead of doing drawImage() from a buffering image. This is the way that games get smooth animation. Flipping is automatically sync'd to the vertical refresh of the monitor (and is thus pegged to the refresh rate of the monitor, or even subdivisions of that number). The buffering operation is faster because it only involves a pointer switch (back - front) instead of a copy of all the pixels. Anyway, take a look at the BufferStrategy APIs. You will need to be in fullscreen mode on Windows in order to take advantage of buffer flipping. Take a look at the fullscreen tutorial (a bit dated, but still essentially correct) for more information on this: http://java.sun.com/docs/books/tutorial/extra/fullscreen/ Chet. Mark McKay wrote: I've written a program that generates images in real time, which if viewed in sequence would form an animation. These images are built one at a time in a 800x600 offscreen VolatileImage buffer (I'm doing my own double buffereing). I then call repaint() and blit this buffer to a JComponent that I've subclassed to display my animation. Painting code is in the paintComponent() method. I'm repainting anywhere from 10 to 30 frames per second. This is handled in a second thread that sleeps for the appropriate number of milliseconds, then wakes up, causes the next image to be generated, and calls repaint() on my component's JFrame ancestor. Even though my machine is fast enough to generate and blit in the time provided, the animation still apprears jagged. There is occasional horizontal shearing, presumably from the blitted image being only partially rendered when the screen refresh occurs. The image also appears to shake, giving me the impression that Swing is somehow caching previous copies of frames rendered and mixing them into the curent frames rendered. The whole thing reminds me of the old days when you had to override update() to stop AWT from clearing the screen. I've tried this both single buffered and double buffered JRootPanes (since I'm doing my own double buffereing, I figure I don't need to use Swing's). Any ideas what's going wrong? Is my second thread causing the trouble? What's the recommend way to get smooth animation? Mark McKay -- http://www.kitfox.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] JDK 1.5 and Java2D pipeline
Hi Mark, I'm glad to see that you're interested in Java2D and the upcoming 1.5 release. I'll see if I can answer most of your questions Will the OpenGL pipeline be enabled by default in the release version of 1.5? Will my older 1.4 programs take advantage of it right away? The current plan is for the OpenGL pipeline to be disabled by default, but enabled via a command-line flag. This is due to concerns over robustness (especially with the somewhat chaotic state of GL driver support on both Linux and Windows) and performance for some operations (OpenGL tends to get incredible performance for advanced rendering features but performance for some simple operations can be less amazing due to pbuffer support and acceleration on many drivers/hardware. We're working on both of these issues, but that's why this otherwise pretty awesome hw acceleration feature will not be enabled by default... Will images with transparency which are initialized once and then used intensively for bilting from be invisibly promoted to system managed VolitileImages, the way images without transparency currently are? Will the JDK still handle Images and BufferedImages differently in this respect? (Only Images are promoted; BufferedImages are not) More (most, even) images will become managed images (our term for the hidden acceleration feature that you're talking about). So, for instance, when you do: new BufferedImage(...) and start copying from that image to an accelerated destination (such as the back buffer or the screen) then we will try to create a cached, accelerated version of that image. Note that this is mainly beneficial on Windows (opaque and transparent images only - not translucent by default yet) and on Unix with OpenGL enabled. Are there any tips and tricks that will allow savvy developers gain maximum performance from the J2D engine? Tons. But that's a bit beyond the scope of this email. Check out some of the postings/blogs at javadesktop.org and javagaming.org. Also, check out JavaOne; we tend to have a tips tricks talk every year. When will Java 1.5 be officially released? I've been getting really excited aobut this realease, but don't want to upgrade until it's official. I don't know the official date, and one never knows with software in any case. We should be releasing our Beta2 sometime soon, after which the next release should be the final one. As to how that equates into specific dates... Chet. Mark McKay -- http://www.kitfox.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] fastest operation to get string size and draw string
Michael,
On the speed question, some things to consider are:
- anti-aliasing tends to slow things down quite a bit (so avoid
it if performance is key, at least in the current releases).
- if your string is static (you're going to render the same
string at the same size many times), consider creating a BITMASK image,
drawing the string into it, and doing a drawImage(...) of that
string image every time you need it. It's a much simpler operation
internally (copying one image around versus rasterizing several
characters).
Chet.
Michael Seele wrote:
hi,
what is the fastest operation to get the size of a string! also i want
to know how i can draw a string as fast as possible! have anybody some
profiling resluts? THANKS
--
Mit freundlichen Gruessen
Michael Seele([EMAIL PROTECTED])
G H Softwareentwicklung GmbH Tel.: {+49|0} 7451 - 53 706 0
Robert-Bosch-Str. 23 Fax: {+49|0} 7451 - 53 706 90
D-72160 Horb a.N. http://www.guh-software.de
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Best Practices
Michael,
The easiest way to get double-buffering in your app is to
use Swing. If you subclass JComponent and override the
paint(Graphics) method, then the Graphics object which
is passed in during a normal paint operation is the Graphics
for the back buffer. When youa re done painting, that buffer
will be copied to the screen for you.
So one simple approach is:
- create a JFrame f
- f.getContentPane().add(new MyJComponent());
(where MyJComponent subclasses JComponent)
- implement MyJComponent.paint(Graphics), in which
you will set whatever properties you want to on
the Graphics (including the transform, if that's what
you want) and render.
Remember, also: if you are going to be at a particular zoom
for some period of time (several frames), it may be worth
pre-scaling the image to that size and avoiding the scale
on every rendering. This could be helpful for performance
(although you'd have to see whether it mattered in your
particular application)
Chet.
Michael Seele wrote:
do you use doubleBuffering in you toolkit? how can i use doubleBuffering
AND zooming with AffineTransform?
thanks!
Mit freundlichen Gruessen
Michael Seele([EMAIL PROTECTED])
G H Softwareentwicklung GmbH Tel.: {+49|0} 7451 - 53 706 0
Robert-Bosch-Str. 23 Fax: {+49|0} 7451 - 53 706 90
D-72160 Horb a.N. http://www.guh-software.de
Emmanuel Pietriga schrieb am 17.10.2003 08:28:
You should take a look at java.awt.geom.AffineTransform set on a
Graphics2D by methods transform or setTransform.
These work pretty well and are easy to use. I use them extensively in my
Java 2.5D (ZUI) toolkit [1], especially for bitmap images, and
performance is very good.
[1] http://zvtm.sourceforge.net
Emmanuel
--
Emmanuel Pietriga ([EMAIL PROTECTED])
tel (mobile): +33 6 88 51 94 98
http://claribole.net
Knight, Jon wrote:
What's the best way to scale/zoom/pan an image or drawing? I've tried
changing the attributes directly in the Graphics2D context, which
seems to
work pretty well. But when I zoom in, there's the need to pan to see
the
big picture. So I tried putting the whole panel in a JScrollPane and
changing the size of the JPanel to zoom. That let's me pan with the
scrollbars, but performance isn't too good.
Thanks,
Jon
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST. For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST. For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] deleting Layers
Calvin, There is no concept of layers in Java2D; our library is an immediate mode API. It seems like one way to address your needs (of not redrawing all of these costly objects when only one changes) is to draw each one into its own BufferedImage (probably a BITMASK transparent one). Then composite them all in the window during drawing. When one changes, you only need to re-render that one object; the rest can simply be copied from their BufferedImage objects when repainting the window. Chet. kaiwen wrote: Hi, I just started reading on java2d and glf (Graphics Layered Framework). I am very keen on learning glf, I hope to achieve layered graphics like those in Photoshop drawing. What I wanted is to draw each Shape in seperate Layer, and modify a particular Layer and redraw that modified Layer WITHOUT redrawing the whole canvas. Can I do this with glf? I tried a few example from sun.com, I cannot find a method Layer.remove(Layer). Or there is another way doing this? I used to keep all Shape drawn in a Vector and later search for the Shape I want to modify, modify it and draw the whole Vector on Canvas again. Yes, it is very slow. What is a better way of doing this? Please advice. Best ragards, Calvin Kuan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Rendering DDS sample code
DeSoca, There is no DDS (DirectDraw Surface) in Java2D (or anywhere in core java). We use DirectDraw as one of our (many) rendering pipelines, but we do not propagate those platform-specific types through the API. I'm not sure what you're looking for, but please check out the Java2D API pages on java.sun.com for more information about how to use the library. Chet. DeSoca wrote: Hi folks, I am a newbie a Java2D (not Java) and I am just looking for some sample code on reading and rendering of DDS (DirectDraw Surface) file type to get me started in the write direction. Links doc or any info will be helpful. Thanks in advance. DeSoca. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] crash when closing the main (and last) window of an application
Michel, This sounds like the infamous ATI bug that is described in gory detail in bug report #4713003 (and other related bug reports). There is a bug in the ATI drivers that is triggered by the way Java2D uses Direct3D, starting with release 1.4.1. Fortunately, the problem is solved in 1.4.1_02 and 1.4.2 (and future releases, of course). Grab the latest 1.4.1 or 1.4.2 from the web site and it should do the trick. Let us know if it doesn't in case there's something else going on, but chances are this is your problem. (Note: some people had a problem with java web start continuing to use an older/crashing release even after installing the new fixed release. make sure you completely uninstall the previous release before installing the new one to work around this problem). Chet. Michel Raoux - KEAL wrote: Hello, Has anyone heard something about such a thing ? See the application error traces below (content of a file named 'hs_err_pid788.log'). It seems there is a bug in a java2d native function. If yes, is it solved in java 1.4.2 ? My plateform is windows XP version 2002 SP1, 2 GHz, All-in-Wonder Radeon graphics card, 512 Mo RAM. javaw.exe is used. My application opens a window, then the user opens a sub-window. In the sub-window he makes some scroll through the graphic presented. Then he closes the sub-window by clicking on the cross in the upper right corner. Then he quits the application by clicking on the cross in the upper right corner of the main window. Then this blocks completly the man-machine interface, the mouse can't be moved anymore : the only way is to reboot the machine. Thanks in advance for any help/answer. Michel Raoux KEAL --- content of 'hs_err_pid788.log' -- An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6D00FB15 Function=Java_sun_java2d_loops_MaskFill_MaskFill+0xB6E5 Library=C:\Install\sioie\java\jre\jre\bin\awt.dll Current Java thread: at sun.java2d.loops.Blit.Blit(Native Method) at sun.java2d.pipe.DrawImage.blitSurfaceData(Unknown Source) at sun.java2d.pipe.DrawImage.renderSurfaceData(Unknown Source) at sun.java2d.pipe.DrawImage.clipAndRenderSurfaceData(Unknown Source) at sun.java2d.pipe.DrawImage.copyImage(Unknown Source) at sun.java2d.pipe.DrawImage.copyImage(Unknown Source) at sun.java2d.pipe.DrawImage.copyImage(Unknown Source) at sun.java2d.SunGraphics2D.drawImage(Unknown Source) at sun.java2d.SunGraphics2D.drawImage(Unknown Source) at javax.swing.JComponent.paintWithOffscreenBuffer(Unknown Source) at javax.swing.JComponent.paintDoubleBuffered(Unknown Source) at javax.swing.JComponent.paint(Unknown Source) at java.awt.GraphicsCallback$PaintCallback.run(Unknown Source) at sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source) at sun.awt.SunGraphicsCallback.runComponents(Unknown Source) at java.awt.Container.paint(Unknown Source) at sun.awt.RepaintArea.paint(Unknown Source) at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Dynamic libraries: 0x0040 - 0x00406000 c:\install\sioie\java\jre\jre\bin\javaw.exe 0x77F4 - 0x77FEE000 C:\WINDOWS\System32\ntdll.dll 0x77E4 - 0x77F36000 C:\WINDOWS\system32\kernel32.dll 0x77DA - 0x77E3E000 C:\WINDOWS\system32\ADVAPI32.dll 0x7800 - 0x7807F000 C:\WINDOWS\system32\RPCRT4.dll 0x77D1 - 0x77D96000 C:\WINDOWS\system32\USER32.dll 0x77C4 - 0x77C8 C:\WINDOWS\system32\GDI32.dll 0x77BE - 0x77C33000 C:\WINDOWS\system32\MSVCRT.dll 0x6D33 - 0x6D45C000 c:\install\sioie\java\jre\jre\bin\client\jvm.dll 0x76AE - 0x76B0E000 C:\WINDOWS\System32\WINMM.dll 0x6D1D - 0x6D1D7000 c:\install\sioie\java\jre\jre\bin\hpi.dll 0x6D30 - 0x6D30D000 c:\install\sioie\java\jre\jre\bin\verify.dll 0x6D21 - 0x6D229000 c:\install\sioie\java\jre\jre\bin\java.dll 0x6D32 - 0x6D32D000 c:\install\sioie\java\jre\jre\bin\zip.dll 0x6D00 - 0x6D0FA000 C:\Install\sioie\java\jre\jre\bin\awt.dll 0x72F5 - 0x72F73000 C:\WINDOWS\System32\WINSPOOL.DRV 0x7632 - 0x7633C000
Re: [JAVA2D] tiling problem with swing components
Praveen,
I'm not completley sure what's going on in your app, but you
might be seeing the effect of Swing's use of a back buffer.
That is, in an AWT app, you see the graphics on the screen
at the same time that you draw them. But in Swing, all
graphics are rendered to the back buffer and you only
see them on the screen when the back buffer is copied to
the screen.
If you want to present the data as it becomes available, only do
the rendering itself in the paintComponent() method. You could
use a separate thread to prepare the data and then, whenever
you are ready to display new data, call repaint() on the
component, which will eventually call your paintComponent()
method, which will quickly display only the data that you
have specified is ready.
Hope that helps.
Chet.
Java2D
Praveen Kysetti wrote:
Hi,
I am trying to render a tiled OffScreen image onto a JPanel one tile at
a time. It works fine if I use the AWT Canvas or it even works if its a
JPanel added into a AWT ScrollPane but doesn't work if its pure swing.
In a swing component it waits for all the tiles to be loaded before it
draws it onto the JPanel. Is it possibly because the computing thread
hanging. I have attached my paint method for the JPanel below. It might
give you some idea of what I want to do. I can't figure out what's
wrong. Hope you can give some suggestions. Any help is appreciated.
Thanks,
Regards,
Praveen
**
public synchronized void paintComponent(Graphics g) {
Graphics2D g2D = (Graphics2D)g;
Rectangle clipBounds = g.getClipBounds();
txmin = XtoTileX(clipBounds.x);
txmax = XtoTileX(clipBounds.x + clipBounds.width - 1);
tymin = YtoTileY(clipBounds.y);
tymax = YtoTileY(clipBounds.y + clipBounds.height - 1);
AffineTransform transform = AffineTransform.getTranslateInstance(0 , 0 );
offScrGraphics.drawRenderedImage(im.getSubImage(txmin, tymin,
clipBounds.width, clipBounds.height), transform);
shape i;
int num_annotations = list.size();
for(int i1 = 0; i1 num_annotations; i1++) {
i = (shape)list.get(i1);
i.paint(offScrGraphics);
}
for (tj = tymin; tj = tymax; tj++) {
for (ti = txmin; ti = txmax; ti++) {
AffineTransform transform1 =
AffineTransform.getTranslateInstance(0 , 0 );
g2D.drawRenderedImage(offScrTile.getSubImage(ti*tileWidth ,
tj*tileHeight, tileWidth , tileHeight), transform1);
}
}
}
Do you Yahoo!?
Yahoo! SiteBuilder
http://us.rd.yahoo.com/evt=10469/*http://sitebuilder.yahoo.com - Free,
easy-to-use web site design software
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Swing mailing list (slightly off-topic)
Michael, I'll forward your request along to the Swing folks, but a better answer might be the forums on the new java client site: http://javadesktop.org The site is a lot like the 2d interest list; the Sun people are listening in and occasionally commenting, but it's also for and by the community overall. I know the Swing and AWT forums have had quite a bit of activity since the site opened in June; check it out and see if it addresses your needs. Chet. Nidel, Michael wrote: Sorry for continuing an off-topic thread (and for cross-posting to JAI-INTEREST), but maybe someone can establish a mailing list for swing topics? The various java lists can be incredibly helpful and it has long puzzled me that there isn't a Swing list. I have been a bit disappointed with the Swing Connection because of its out-of-date feel, though this has improved a bit recently. Ideally a swing list would be hosted by sun through the Swing Connection - it would probably require limited additional work for them as far as setup given the existing listserv systems. If no Sun staff are actually available to post responses on the list, that would be fine, it could be user-supported. This is not all that different from some of the other official lists. I know I would join such a list, and I'm sure I'd be able to contribute some answers in addition to asking questions. If this idea doesn't fly with Sun but there is interest in a swing list, I would recommend that interested people sign up for the list mentioned below (or some alternative). It would also be useful if Sun advertised the existence of the list somewhere on the java.sun.com site if possible, so that people with questions know where to go. In any case, I think there is enough user demand for a list resource that it justifies some kind of action. regards, Mike Nidel Lockheed Martin MDS Gaithersburg, MD USA -Original Message- From: Andrei Kouznetsov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 3:58 AM To: [EMAIL PROTECTED] Subject: Re: [JAVA2D] there is Swing mailing list this list however is not really good (and not advanced). On Thu, 24 Jul 2003 10:00:35 +0900, Tadashi Ohmura [EMAIL PROTECTED] wrote: Advanced-swing mailing list [EMAIL PROTECTED] http://eos.dk/mailman/listinfo/advanced-swing == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Is there an AWT or Swing mailing list?
Rob, For Swing, you can send your input/questions to: [EMAIL PROTECTED] (you can find this and other info on theswingconnection.com) I don't know about AWT off-hand, but I'll forward your question. Chet. Java2D Rob Ross wrote: I couldn't find one in the archives here: http://archives.java.sun.com/archives/ nor could I find one anywhere on the various sun sites. Rob === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Java 2D / JAI for image diffs
Michael, Depending on how sophisticated you want to be here, it is pretty easy to get the pixel values from a BufferedImage and just compare those values to those you get from another image. Then you can create a third image with those diffs. Check out getRGB() methods in the BufferedImage API for more info. Chet. Michael Saunders wrote: I don't have any experience processing images in Java 2D / JAI so I hope that someone can point me in the right direction. Problems: 1. I would like to create a simple utility program that will take two images and put them in a card layout and then continuously cycle through them so the user can perform a visual diff between the two images to spot any changes. 2. I would also like to be able to create a third image that is a diff of the other two so the differences can be easily identified. Questions: The displaying of the images in a card layout doesn't seem too hard but I am not certain how to go about creating the diff image. Can I do this with Java 2D as-is or do I need JAI or JMF? What API's should I be looking for? Do I read the pixels myself and perform a diff or is there some high level filter API that I can pass the images through? As you can probably tell from the questions I really am not sure where I should start. If you can point me in the right direction I would really appreciate it. Any books or on-line articles would be handy also. Michael === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] complex shape as one object
Eric,
You could draw it all in an image and then copy that image (drawImage())
when it is time to render that object. But you don't have to use
an image. The important thing is to render all of the pieces
(the title and the rectangle) at the appropriate location whenever
it is time to paint. So when your component is painting all of the
subobjects, tell each object to paint itself and each objects
paint method could be something like:
public void paint(Graphics g) {
g.setColor(textColor);
g.drawString(titleText, titleLoc.x, titleLoc.y);
g.setColor(rectColor);
g.fillRect(rect.x, rect.y, rect.w, rect.h);
}
Note that the dragging of objects is distinct from the
rendering (or it can be, depending on your implementation).
You could just track the mouse interaction manually and update
the appropriate object locations based on those events. Then
the ensuing paint events would use the updated locations.
There are a lot of ways to go about this, but hopefully this
gives you some ideas.
Chet.
Java2D
Eric Delacroix wrote:
Hi,
I'm fairly new in using Java draw. I'm trying to make an interface that
permits to handle some graphical objects and link them between each other,
with simple lines. The graphical object consists in a rectangle with a
title
at the top, a line to separate it from the rest of the rectangle, and
that's
all. But I'd like to be able to make some drag and drop of those objects,
and so, I'd like to have this shape as one and only one object. Do I
have to
draw it in an Image object, or something else. I'm a little bit lost in
this case, any help is welcome.
Thank you
Eric Delacroix
_
MSN Messenger : discutez en direct avec vos amis !
http://messenger.fr.msn.be
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Your JavaOne sessions
I should have mentioned this in my earlier mail: Besides the presentations that WE are planning to do at JavaOne, we (and the other Java developers) would like to hear from YOU. Do you have something you would like to present? A session about your application, development tools and processes you think are worth sharing, ways of using our APIs that make your apps better, feature comparisons, whatever; share them with the world! (or at least that portion of the world that will be at JavaOne...) Time is running out; proposals are due by Friday. All you need is an abstract of your presentation right now: http://servlet.java.sun.com/javaone/apps/cfp/sf2003/ Thanks, Chet. Original Message Subject: [JAVA2D] JavaOne session ideas? Date: Wed, 30 Oct 2002 06:41:57 -0800 From: Chet Haase [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] It's session proposal time for the 2003 JavaOne conference. The client teams (2D, Swing, AWT, and Internationalization) have various ideas of sessions that we think developers would benefit from. But it would be great to hear from our developers in case there are things that we are missing. If you have any ideas for session topics or particular graphics-related technologies that you would like to have us present, please send them in either to this interest list or directly to the java2d team at: [EMAIL PROTECTED] We're wrapping up our abstracts now and the deadline is November 8th, so send in those ideas soon... Thanks, Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] JavaOne session ideas?
It's session proposal time for the 2003 JavaOne conference. The client teams (2D, Swing, AWT, and Internationalization) have various ideas of sessions that we think developers would benefit from. But it would be great to hear from our developers in case there are things that we are missing. If you have any ideas for session topics or particular graphics-related technologies that you would like to have us present, please send them in either to this interest list or directly to the java2d team at: [EMAIL PROTECTED] We're wrapping up our abstracts now and the deadline is November 8th, so send in those ideas soon... Thanks, Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] alt-tab in full screen mode
Jesse, Funny you mention that - I've been spending the last few days of my life on that exact problem. This is a bug in 1.4 (and 1.4.1) in our multithreaded approach to fullscreen and display mode functionality. I am working on a fix for it that seems to be mostly functional. Given the timeframe of 1.4.1 (shipping RC any day now), this is a fix that would not be integrated until the next release (1.4.2). Chet. Grosjean, Jesse wrote: I'm trying to figure out how to alt-tab (using windows) out of, and then back into a java application this is running in fullscreen mode. When i try to do this with either of the examples that come with the fullscreen mode tutorial: http://java.sun.com/docs/books/tutorial/extra/fullscreen/example.html they become unresponsive when it try to tab back into them. Is their a way to make alt-tabing back and forth work? thanks, Jesse === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] How to get rid of Volatile Image in Swing components
I'm not quite sure what problem you are having managing the VolatileImage since Swing should be managing that for you, but in any case you can force the back buffer to be a BufferedImage instead by using the flag: -Dswing.volatileImageBufferEnabled=false (Note that this flag works for jdk1.4 and jdk1.4.1 but that it may change with future releases as our internal use of VolatileImage changes) Chet. Emmanuel Deviller wrote: Hi everybody, With JDK 1.4, is there a easy way without using a runtime flag, like swing.volatileImageBufferEnabled=false, to get an offscreen image of type BufferedImage (not VolatileImage) for Swing jcomponents ? ie. : I have a JPanel enclosed in a JScrollPane, I need a BufferedImage backuffer for performance reason, and I had rather to avoid the burden to manage by myself this offscreen backbuffer. Thanks, Emmanuel === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Component.createImage(int,int)
Jesse,
Your approach sounds correct and should result in accelerated
images in general. Some things that could affect this are:
- the platform you are running on (I know we support
bitmask transparent accelerated images on Windows
currently, I'd have to check on the other platforms)
- the operations you are doing with those images
(rendering to the images will go through software
routines and will be no faster than similar
operations on BufferedImages; rendering from the images
to other accelerated images like the back buffer or
screen should go at hw-accelerated speeds). Note
that animated images will not benefit from acceleration
because we cannot use the hardware accelerated version
of the image if the primary version is being constantly
updated. Note also that if you do any operation that gets
access to the raster or data buffer of the image that we
may give up on acceleration.
- the bit depth you are running in (I do not believe we
currently support transparent images in 8 bits per pixel mode).
This is the approach we use in our demos (such as the DukeRoids
demo if you've seen that): create a bitmask transparent image,
render to it once, and copy it to the back buffer after that.
As of the second copy, we run at hardware speeds on these
type of images.
If all of this makes sense and you think your images still should
be accelerated, perhaps you could send me a small test case
that shows the problem I can see what's going wrong.
Thanks,
Chet Haase.
(Java2D)
Grosjean, Jesse wrote:
I'm using Component.createImage(int, int) to create accelerated images, and this
is working well for creating opaque images, but it does not work for transparent
images. I don't believe that fully transparent images can be accelerated with
Java yet (let me know if i'm wrong) but i have read that 1-bit transparency
images can be accelerated. Is this the case, and if so how is it done? Right now
I have the following createAcceleratedImage that i'm trying to use:
public static Image createAcceleratedImage(Image image) {
if (image instanceof AcceleratedOffScreenImage)
return image;
// this works but the accelerate images are always opaque, so comment it out.
// Image result = myComponent.createImage(image.getWidth(null),
image.getHeight(null));
// This makes images will transparency, but they seem the same speed as normal
buffered images with transparent regions.
GraphicsConfiguration graphicsConfiguration =
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDe
faultConfiguration();
BufferedImage result =
(BufferedImage)graphicsConfiguration.createCompatibleImage(image.getWidth(null),
image.getHeight(null), Transparency.BITMASK);
Graphics2D g2 = (Graphics2D) result.getGraphics();
g2.setColor(new Color(0, 0, 0, 0));
g2.setPaintMode();
g2.fillRect(0, 0, image.getWidth(null), image.getWidth(null));
g2 = (Graphics2D) result.getGraphics();
g2.drawImage(image, 0, 0, null);
return result;
}
But the images (when using the Transparency.BITMASK) code do not seem
accelerated.
So is it possible to get accelerated images with a BITMASK?
Thanks,
Jesse
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] color keying
Since you are only after transparency for the background (vs. translucency), you can also use a similar approach but with bitmask transparency instead of a full alpha channel. The advantage to this is that these types of images might get hardware-accelerated under the hood (as of jdk1.4). Chet. David Kavanagh wrote: Matias, If you use a buffered image with alpha channel for the oval image, you can do it. Just use TYPE_INT_ARGB for the buffered image, fill it with a color that sets alpha to 0, then draw your oval in whatever color you like. Then, you can simply draw it into your main image. David Matias Rodriguez wrote: Hello, I have an application which draws a lot of Shapes, circles being one of the most common. I believe that circles are expensive to draw (compared with rectangles). Because most of the circles have the same size, I think it will be fast to draw only one (draw/fillOval) and blit it in the propper places. So the question is: How can I make the background transparent? Am I right? is this faster than draw/fillOval? Thanks. Matías Rodriguez. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] color keying
By the way, to take advantage of any existing hw acceleration for these types of images in 1.4.x, you want to use GraphicsConfiguration.createCompatibleImage(w, h, Transparency.BITMASK); instead of creating an image of type BufferedImage directly. This is just an implementation detail of Java2D; we currently do nothing to accelerate images that are created as BufferedImage objects directly. This may change in future releases, but for the time being it is to your advantage to let Java2D create the image for you... Chet. Chet Haase wrote: Since you are only after transparency for the background (vs. translucency), you can also use a similar approach but with bitmask transparency instead of a full alpha channel. The advantage to this is that these types of images might get hardware-accelerated under the hood (as of jdk1.4). Chet. David Kavanagh wrote: Matias, If you use a buffered image with alpha channel for the oval image, you can do it. Just use TYPE_INT_ARGB for the buffered image, fill it with a color that sets alpha to 0, then draw your oval in whatever color you like. Then, you can simply draw it into your main image. David Matias Rodriguez wrote: Hello, I have an application which draws a lot of Shapes, circles being one of the most common. I believe that circles are expensive to draw (compared with rectangles). Because most of the circles have the same size, I think it will be fast to draw only one (draw/fillOval) and blit it in the propper places. So the question is: How can I make the background transparent? Am I right? is this faster than draw/fillOval? Thanks. Matías Rodriguez. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance of translucent line drawing
Jan, Translucent lines are somewhat slower on 1.4 (Windows version) than previous version for the same reason that other translucency operations are somewhat slower; we can and usually do put the Swing back buffer in video memory to improve the speed of various simple GUI operations (such as opaque fills and buffer copies). While this makes most simple operations significantly faster (because they tend to be hardware accelerated), it makes some software-only operations slower (because those operations now operate remotely on video memory instead of locally on system memory). There are always tradeoffs... Translucencly in particular is much slower because reading from video memory is a horribly expensive operation. You might try a workaround in the short term to see if you get better overall performance: -Dsun.java2d.ddoffscreen=false This flag tells us not to store any images in video memory. If your application is being so bogged down by the performance of yoru translucent lines that it's a net loss with the stuff that actually can be accelerated, then perhaps this flag would help your performance. Or it can at least provide you a tool to test with that can help narrow down your bottlenecks. Another similar flag which is not so universal is: -Dswing.volatileImageBuffereEnabled=false This does not disable all ddraw offscreen image, but does tell Swing to store its buffer in system memory instead of VRAM. Another possible workaround, depending on your app, is to create and use a temporary buffer into which you draw your translucent primitives. So, for example, you could do all of your opaque rendering into the normal back buffer. Then you could do a drawImage() from that buffer into a temporary buffer, do your translucent operations, and drawImage() back into the back buffer (or directly onto the screen). See below for specific answers to your questions: We are currently working on improving performance of our nice little product that hopefully will give Java on the client some additional momentum. While testing we have noticed that drawLine(x1, y1, x2, y2) in JRE 1.4 is significant slower with translucent colors than with opaque colors (and also slower than in JRE 1.3), and this is the main performance bottleneck of our product (although not dramatic). We understand that the main reason for this is that currently no hardware acceleration is used when painting translucent colors. Question 1: Will there be hardware acceleration for translucent colors in future? And is there already a rough idea when this might happen? If this won't happen or if it will take some more time we will try to reduce usage of translucency. We do expect this to happen, probably in the jdk1.5 timeframe (I have no details on when to expect this release, though). We know how to fix the problem (use APIs that allow translucency operations instead of DirectDraw, which only understands opaque and transparent operations), it's just a matter of doing the (significant amount of) work to use those APIs. We have started work on this already, it's just going to be a while until it's ready... Question2: In many cases we are using drawLine(x1, y1, x2, y2) to paint one single pixel. Is there a faster way to paint one single pixel or is this already as fast as if there was a method paintPixel(x, y)? This _should_ be pretty fast. You could also try fillRect() to see if that provides any speedup (although I doubt that it would). If you are doing lots of individual pixels, and if the pixels are translucent, you could also try the temporary buffer solution outlined above and do your drawLine() or fillRect() calls on that buffer. Another approach is to get the DataBuffer for the temporary buffer (assuming you have a BufferedImage as your temp buffer) and set the pixels directly. Note that this tends to cause problems for the acceleratability of images; we try hard to accelerate things under the hood, but it's far easier for us to do that when you use the API instead of grabbing/setting pixels directly. But it's an approach to consider, depending on your particular situation. Hopefully there are some things here that you can play around with to get better performance overall, or at least to know where the problems are how to work around them for now. Chet Haase. Java2D Thanks === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Java2D and system color profile
Igor, I'm not sure if I'm completely answering your question, but here's how we deal with color palettes: On windows (all flavors) in 256-color mode, we create a palette which resembles palettes in popular browsers: a 6x6x6 color cube with additional grays and some other colors thrown in for fun. We do not attempt to change the system defaults (palette entries 0-7 and 248-255). Our color operations to the screen would use any and all colors installed in the palette to achieve the closest match. If that means that your profile changed colors in the system palette (entires 8, 9, 246, 247, I believe), then we would use those colors if they were the closest match. Hope that helps. Chet. Java2D Igor B wrote: Dear list members! Can anyone clarify the following question: does Java2D make use of the system default color profile in screen painting operations? And if yes, on which platforms? Thanks -- ___ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Travelocity.com is giving away two million travel miles. http://ad.doubleclick.net/clk;3969773;6991039;g?http://svc.travelocity.com/promos/millionmiles_main/0,,TRAVELOCITY,00.html === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] sun.java2d.ddscale
TnT2 should handle hardware scaling fine, so there must be something else going on here. Perhaps there is a problem scaling 1-bit transparent images... Chet. Damon Maria wrote: Hi all, an application I'm working on plans to make heavy use of drawing BufferedImages scaled. The DirectDraw acceleration of JDK 1.4b3 makes BufferedImages blindingly fast but on my system scaling them (even with sun.java2d.ddscale=true) is really slow. I presume from this that my video card (an Nivdia Riva TNT2) doesn't support hardware accelerated scaling (strange, I thought it was a good - if slightly old - card). Is this presumption correct? Can someone suggest video cards that do work with JDK 1.4b3 and the sun.java2d.ddscale flag? As you can see from these sun.java2d.trace=count outputs, scaled uses java2d to blit while unscaled uses DirectDraw... Scaled: 1 call to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb) 101 calls to sun.java2d.loops.Blit::Blit(IntArgbBm, SrcOverNoEa, IntRgb) 1 call to sun.awt.windows.Win32BlitLoops$DelegateBlitBgLoop::BlitBg(Any, SrcNoEa, Integer RGB DirectDraw with 1 bit transp) 11 calls to DXFillRect 1 call to sun.java2d.loops.FillSpans::FillSpans(OpaqueColor, SrcNoEa, AnyInt) 1 call to sun.java2d.loops.SetFillRectANY::FillRect(AnyColor, SrcNoEa, Any) 116 total calls to 6 different primitives Unscaled: 1 call to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb) 1 call to sun.java2d.loops.SetFillRectANY::FillRect(AnyColor, SrcNoEa, Any) 11 calls to DXFillRect 98 calls to sun.awt.windows.Win32BlitLoops::Blit(Integer RGB DirectDraw with 1 bit transp, SrcOverNoEa, Integer RGB DirectDraw) 1 call to sun.java2d.loops.FillSpans::FillSpans(OpaqueColor, SrcNoEa, AnyInt) 1 call to sun.awt.windows.Win32BlitLoops$DelegateBlitBgLoop::BlitBg(Any, SrcNoEa, Integer RGB DirectDraw with 1 bit transp) 3 calls to sun.java2d.loops.Blit::Blit(IntArgbBm, SrcOverNoEa, IntRgb) 116 total calls to 7 different primitives thanks in advance, Damon. -- Strobe lights and blown speakers Fireworks and hurricanes === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] High performance graphics on java.sun.com
Damon, One reason I'd prefer VolatileImages over BufferedImages is that it allows the application to manage the video card memory as a cache. As one example: Keep track of all the VI's we've created and when last used. If we try to create a new one and getCapabilities().isAccelerated() == false then we can flsuh() some old ones, and re-create the new one accelerated. If a flushed one is asked for again, re-create it. This control is not possible with BufferedImages. I know this is implementation detail but could someone describe how BufferedImages being loaded into and out of VRAM currently works? Is it something similar to what I described above. Unfortunately it is not that sophisticated. VRAM is currently managed as a pool for both Volatile and non-Volatile images and is allocated on a first-come, first-served basis. Volatile images can control their use of this resource (via the flush() call), but hidden-acceleration images (those that we try to cache and accelerate under-the-hood) will sipmly grab the memory if it's there and if it looks like acceleration is worthwhile. For example, a non-Vol buffer that is being modified every frame will probably never allocate VRAM because we never see the advantage from copying down the changes to the cached version. A static sprite, on the other hand, will grab some VRAM almost immediately and will continue to use it until the image is GC'd. What are the conditions that cause a BufferedImage to go into VRAM. Is there anyway to hint to a BufferedImages to be put into VRAM. Like graphics.dispose() or seomthing? See above explanation... The reason I'm asking is because the application I'm developing will rely heavily on caching of accelerated images. The best recommendation I have for you now is to pre-allocate the stuff that you really want in VRAM, keeping in mind the first-come, first- served principal. Also, you should be able to manage vram for your own Volatile images even if there are also non-Volatile images taking up the same resource. As an example, let's say someone just resized your window and you need to create a new back buffer. You obviously don't need the old back buffer any more and you want to use that VRAM for your new back buffer. The best thing to do (and this is what's done inside of Swing) is to first flush the old back buffer and then allocate the new one. Assuming there are no other threads in your app allocating image memory at the same time, this should guarantee that the VRAM from the old buffer is available for reuse immediately by the new buffer. In the next release, when we will hopefully be able to support even more functionality in hardware (such as alpha compositing and more advanced drawing primitives), we will hopefully have more ways to create different kinds of accelerated images (both explicitly and implicitly). Sounds like what I want. By next release are you talking 1.4 (release), 1.4.1 or 1.5? Certainly not 1.4 (we're freezing that in the next few days). Anything requiring API changes would have to be 1.5. Anything that could be done under-the-hood (such as VRAM management or acceleration for certain existing image types) could be done between 1.4 and 1.5, depending on the work required. Thanks for the help and detailed response, Sure thing. Thanks for the input. It's great to see people actually starting to use the stuff we've been working on for a while; input from actual users is key to getting the API and the implementation right. Chet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Feature requests for jdk1.5...
Now that development on jdk1.4 is winding down, the Java2D team is starting the plan for the jdk1.5 release. We thought that people on this interest list might have things in mind that you would like to see in our product. These can range from API requests to performance issues to quality issues; anything is fair game to propose at this point. Feel free respond to this list or to [EMAIL PROTECTED] (which only goes to the Java2D team) if you prefer. We may not respond directly if there are no questions about your Email. But all requests will be reviewed by the group to help determine our priorities for the next release. Thanks, Chet Haase. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What determines screen resolution given double buffering off?
Jason, You can always set the screen resolution using the Display control panel in win32, but there is no way to set the screen resolution from inside of Java in jdk 1.3.1. This is a capability that we have introduced in jdk1.4, however; check out the GraphicsDevice in the latest Beta release for more information. Chet. Delivered-To: [EMAIL PROTECTED] Content-Transfer-Encoding: 8bit X-Priority: 3 From: Jason T. S. Chow [EMAIL PROTECTED] Subject: [JAVA2D] What determines screen resolution given double buffering off? To: [EMAIL PROTECTED] Hi all, After I have set double buffering of a swing component off by setDoubleBuffered(false), I found that the screen resolution is 96, from getToolkit().getScreenResolution(). Why is 96? And is there any way to set screen resolution?I am using 800 x 600 screen size, using Window 98 and JDK 1.3.1. Thanks in advnace. Jason -- Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î Thank you for using hongkong.com Email system === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. ==To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Problem using page flipping
Jerome, 2 megs isn't a lot, so I wouldn't be totally surprised if you're bumping up against a VRAM limit, even though your front and back buffers alone should fit with almost 800K to spare.. Ideally, the only things in VRAM should be your front and back buffers. But there might be other things there as well, depending on your app, Windows98, the graphics card, and the graphics driver. Thee things include other images from your app (even if you don't create VolatileImage objects, we might try to create a hardware-cached version of some of your images), the primary display used by Windows, and resources used by the GDI and graphics drivers of your card. In any case, there is a new call in GraphicsDevice called: getAvailableAcceleratedMemory() It should be available in the jdk1.4 Beta2 release. This function should query the video hardware as to what resources are actually available. This would give us more information about why your app might be failing to get the flippable buffer. There are various things that could contribute to this problem, such as hardware/drivers that don't support page flipping, the time of buffer creation (if you're running in high-res mode at the time you try to create this stuff, there's not enough room to create everything given the size that the display takes up in VRAM). But finding out the answer to the above might help. Chet. Delivered-To: [EMAIL PROTECTED] From: Blouin, Jerome [EMAIL PROTECTED] Subject: [JAVA2D] Problem using page flipping To: [EMAIL PROTECTED] All, I'm developing a 2D demo that scrolls a wide image in a resolution of 640 x 480 of 16 bits. To do this I use a rendering loop that uses a BufferStrategy (JDK 1.4). My problem is that I would like to have a page flipping strategy to have the best results, but it seems that the program isn't able to use that strategy. It uses a blitting strategy instead witch causes tearing effects in the demo. To discover that the program doen't do page flipping, I request the BufferCapabilities class. The call to isPageFlipping() always returns false and the call to getFlipContents() always returns null because isPageFlipping() returns false, according to the API doc. I don't understand why page flipping can't be used because my video card has 2 megs of VRAM so this should be big enough to perform page flipping (2 pages of 640 x 480 x 16). Also I run the demo in Windows 98. Any help would be greatly appreciated. Thanks Jerome === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Fullscreen API
Jerome, Assuming you're running on win32 (where fullscreen is fully implemented through ddraw, and not emulated by awt) You might try calling sync() on the Toolkit: Toolkit.getDefaultToolkit().sync() This ensures that ddraw and gdi have flushed their commands prior to returning. Also, current jdk1.4 builds tend to go through contortions when going into and out of fullscreen mode (you may notice the display mode changing a couple of times during the process). This has been simplified in our internal builds (which should be available soon, or by Beta2 at the latest). That might be the source of your problem/solution... Chet. Blouin, Jerome wrote: Hi! When changing the display mode in fullscreen exclusive mode, is there a way to know when this operation has completed? I ask it because when I change the display mode it takes a few seconds or less to execute. This is important for me because I should wait that the display is in the expected mode before starting to perform animations otherwise many frames will not be shown. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage pixel access?
John, There isn't really a good way for you to get at the pixels of a VolatileImage. This is (somewhat) by design. First of all, getting at the pixel values of a ddraw surface (on win32) tends to slow down the graphics pipeline (it flushes all pending operations, thus serializing access to the graphics chip and losing the benefits of parallelism). But more importantly, the methods provided by Java2D for accessing pixels (getRaster(), etc.) simply hand over a pointer to the data to you somewhat permanently (meaning that you can continue to use that pointer for as long as you want). This is a serious drawback for us in implementing VolatileImage objects because it is impossible to have an outstanding pointer to ddraw (on win32) pixels while that surface is not locked. The only way to work around this mismatch between our API and ddraw is to punt on acceleration whenever anyone requests access to the pixels. However, there should be a way to do what you intend. Your approach of using a staging buffer is the recommended way to deal with this problem. But make sure to copy the data from the staging buffer in a way that does not get a pixel pointer (e.g., getRaster()) from the VolatileImage. So, for example, if vImg is your VolatileImage and stage is your staging buffer: Graphics2D g = (Graphics2D)vImg.getGraphics(); g.drawImage(stage, 0, 0, null); // this assumes you want // to copy the entire buffer; you could copy // a subrectangle instead This approach would allow us to copy the pixels in the staging buffer without violating the policy of pixel access. In general, the approach to getting the maximum acceleration out of VolatileImage is do it through the API. That is, anything you can do to avoid getting at the pixels will let things run as fast as possible. I hope this helps. Chet. John Owen wrote: What is the correct way to manipulate image data using the new VolatileImage class and backbuffering? I have a rendering loop where I am compositing multiple static images to a single back buffer image. I then want to make one or more passes manipulating the back buffer pixel data. What is the correct way to do this to maintain hardware acceleration? There does not seem to be any way for me to get a hold of the image data if the backbuffer is a VolatileImage. Should there be a way to do this using the new jni ByteBuffer class? I have tried to do this using createImage() to create a staging buffer, modify the staging buffers pixel, and then blitting this buffer to the backbuffer. However as soon as I call getRaster() on the staging buffer my frame rate plummets. I also really don't want to manipulate the data on the Java heap, but on the C heap intead. Any information would be appreciated. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage pixel access?
John, I think the drop in frame rate when you call getRaster() is because your staging buffer is also being hw accelerated (either because you've created it as a VolatileImage or because we're trying to do acceleration on a createImage() object for you). Before you call getRaster() on that buffer, we are able to do copies from that buffer to the VolatileImage at hardware speeds. As soon as you call getRaster(), we punt the staging buffer into software (due to the reasons I described before) and the copies to and from that buffer will now happen through software rendering instead (much slower in general). I don't have any particular suggestions for you other than: - try to use API calls to draw your pixels instead (can you use line commands to draw single pixels? Or create sprites and copy those around instead?) - make the area you are copying from your staging buffer as small as possible to minimize the overhead of the software copy into the VolatileImage. - it is possible that there is something inefficient about the way that we are handling the actual setPixels, but I would have to know more about your application. If you sent me a simple app that demonstrated your problem, I could take a look at it to see where the bottelnecks were. As far as locking and unlocking the VolatileImage from the application, this is a good suggestion and one that I could see proposing for the API (but not, unfortunately, in the 1.4 timeframe). Note that there is, in general, a trend away from direct pixel access. For example, DirectX 8 does not (at least to my knowledge) allow you to lock any of the surfaces cached in hardware. Instead, you are expected to make changes to software surfaces and then copy them down to hardware (much as you are doing with your staging buffer). This is to account for the increasing cost in performance of locking the framebuffer; as video cards get more capable and complex the cost of flushing the graphics pipe and getting the vram pixels in a modifiable state is more and more expensive. Chet. John Owen wrote: This is a serious drawback for us in implementing VolatileImage objects because it is impossible to have an outstanding pointer to ddraw (on win32) pixels while that surface is not locked. The only way to work around this mismatch between our API and ddraw is to punt on acceleration whenever anyone requests access to the pixels. If I was working with Direct Draw and C, I would lock my staging buffer, modify the pixels, unlock it, and then blit it to the back buffer. How come I can't do this with a VolatileImage? Can't you expose lock/unlock and a method to get the native data as a jni ByteBuffer? But make sure to copy the data from the staging buffer in a way that does not get a pixel pointer (e.g., getRaster()) from the VolatileImage. So, for example, if vImg is your VolatileImage and stage is your staging buffer: Graphics2D g = (Graphics2D)vImg.getGraphics(); g.drawImage(stage, 0, 0, null); // this assumes you want // to copy the entire buffer; you could copy // a subrectangle instead This approach would allow us to copy the pixels in the staging buffer without violating the policy of pixel access. This is exactly what I am doing right now. It works great, I get 100+ frames a second. However as soon as I call stage.getRaster() so that I can modify the staging buffer's pixels, my frame rate drops to 15 frames a second. I haven't even added the code to actually modify the pixels yet, the call to getRaster() itself is causing the dramatic drop in frame rate. So this doesn't seem like a viable solution, at least with the current implementation. Even if it does work in the future I would still much prefer the lock/unlock/ByteBuffer solution because I want to modify the data on the C heap, not the Java heap, because it is likely to be much faster. - John === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] How to avoid cursor flashing?
Bruce, Unfortunately, there's probably not a lot you can do at the application level about the flashing cursor. There are a couple of things that can make the cursor flash while using Swing/Java2D: - Buffer flipping: the new buffer flipping capability in jdk1.4 sometimes makes the cursor flash as we flip between the back buffer and the onscren buffer. - DirectX cursor hiding: Microsoft's DirectX runtime sometimes hides the cursor during certain operations (e.g., Blits) to avoid cursor garbage. - Windows 2000 cursor bugs: There are problems with alpha-blended (shadowed) cursors on Windows 2000 on some video cards (especially those that lack hardware color cursor support). This requires a workaround in Java2D to hide the cursor before performing some operations (screen-screen Blits). - Video card/driver cursor support: in general, software cursors are going to flash more as various software components (Java2D, DirectX, Windows) hide the cursor to avoid cursor garbage during onscreen graphics operations. I don't know if this helps you any, but perhaps understanding the limitations will help you find a solution in your application. In the meantime, if you could send me a sample app with your marching ants stuff in it, I could try it out here and see if there's anything that we could do (although it probably won't happen by jdk1.4 final release, but I could at least put it on the TODO list for future patches/releases). Also, tell me the details of the system you are running on (Windows version, video card, etc.). Thanks, Chet. Bruce Hodge wrote: Does anyone know how to avoid having the cursor flash or blink when the screen is updated under Windows? I have an implementation of marching ants for an active marquee, but it causes the cursor to blink at every refresh. Thanks, Bruce Hodge [EMAIL PROTECTED] === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage and Transparency?
This is definitely possible in jdk 1.4... but not yet. We just put back the code to do this into our source tree last Friday, which means it will be in official builds in the next week or so and will be in the official beta refresh (aka Beta2) build whenever that ships. Note that not all images with transparency are accelerated (for now). The best way to guarantee acceleration is to create a compatible image with bitmask transparency using the GraphicsConfiguration.createCompatibleImage() method. There is an example of how to do this in the internal DukeRoids demo; let me figure out the best way to externalize that code (maybe posting to this list or to the java2d or javagaming.org site...). Chet. Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] From: John Owen [EMAIL PROTECTED] Subject: [JAVA2D] VolatileImage and Transparency? To: [EMAIL PROTECTED] Hello: I am very impressed with the performance of the new VolatileImage and BufferStrategy classes. However I can not seem to get transparent blitting to work. I am trying to copy a volatile image to another volatile image using Graphics.drawImage(...) I want to specify a single transparency color and I do not want to use an alpha band. My desktop is in 32 bit true color and my images both have a DirectColorModel with 3 bands, rgb. The problem I am having is that there does not seem to be a way for me to specify a transparency color. The only public setTransparentColor() method i see is on IndexedColorModel, but I have a DirectColorModel. Is there any way to do this using the current JDK1.4 public APIs? I have been able to get it to work by casting my source VolatileImage to a sun.awt.windows.WVolatileImage and calling setTransparentColor(Color). This obviously isn't portable though. I have also had limited success by making my source image a BufferedImage and using an alpha band and a transparency mode of Transparency.BITMASK. However my frame rate drops to like 5 fps from 350fps, which makes sense to me since all the available GraphicsConfigurations under windows seem to only have 3 bands (no alpha band). Any ideas how I can do this while maintaining hardware accelerated blits? Thanks, - John === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] JDK 1.4 - Full-screen support.
Fullscreen mode on win2k has been somewhat disfunctional. Most of these problems have been fixed just recently; expect the Beta 2 release of the jdk to include these fixes... Chet. Mail-Followup-To: Onimusha [EMAIL PROTECTED], [EMAIL PROTECTED] User-Agent: Mutt/0.96.1i From: Dmitri Trembovetski [EMAIL PROTECTED] Subject: Re: [JAVA2D] JDK 1.4 - Full-screen support. Comments: To: Onimusha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi Onimusha, Thanks for the comments. On Thu, May 24, 2001 at 11:59:0p -0400, Onimusha wrote: I know full-screen support is more of an AWT topic, but it is related to Java2D (graphics). Well, from the log you've attached it seems that it crashes in 2D code.. Crashes on my Win2K+DX8+Voodoo3 as well with the same stack trace. Works fine on NT. Probably some OS-specific issue. We'll look into it. Thank you, Dmitri So I tried to implement the full-screen examples on the Java Tutorial; http://java.sun.com/docs/books/tutorial/extra/fullscreen/example.html Here's what I got ... Example 1: Runs, but I can't change any settings (grayed out). Example 2: Goes into a fullscreen mode at my current color/depth/resolution setting. But whenever I try to set the mode (even to the same thing it's running at) the VM crashes. The cool thing at least, is that it creates a log file, (log file at end of this post) Example 3: Screen actually seems to change display mode (like when you play a game) but then just stays black and doesn't do anything. Any ideas, maybe it's Win2K, Direct X 8.0, or even my video card (TNT). logfile ... An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6D066520 Function=Java_sun_print_Win32PrintJob_printRawData+0x4C7 Library=D:\jdk1.4\jre\bin\awt.dll Current Java thread: at sun.java2d.loops.Blit.Blit(Native Method) at sun.java2d.SunGraphics2D.blitSurfaceData(SunGraphics2D.java:2966) at sun.java2d.SunGraphics2D.renderSurfaceData(SunGraphics2D.java:2892) at sun.java2d.SunGraphics2D.clipAndRenderSurfaceData(SunGraphics2D.java:294 9) at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3258) at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3490) at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4604) at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4547) at javax.swing.JComponent._paintImmediately(JComponent.java:4497) at javax.swing.JComponent.paintImmediately(JComponent.java:4329) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:407) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEve ntQueueUtilities.java:120) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:167) at java.awt.EventQueue.dispatchEvent(EventQueue.java:437) at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:131) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) Dynamic libraries: 0x0040 - 0x00405000 D:\jdk1.4\bin\java.exe 0x77F8 - 0x77FFA000 C:\WINNT.0\System32\ntdll.dll 0x77DB - 0x77E0A000 C:\WINNT.0\system32\ADVAPI32.dll 0x77E8 - 0x77F35000 C:\WINNT.0\system32\KERNEL32.DLL 0x77D4 - 0x77DB C:\WINNT.0\system32\RPCRT4.DLL 0x7800 - 0x78046000 C:\WINNT.0\system32\MSVCRT.dll 0x6D40 - 0x6D503000 D:\jdk1.4\jre\bin\hotspot\jvm.dll 0x77E1 - 0x77E74000 C:\WINNT.0\system32\USER32.dll 0x77F4 - 0x77F7C000 C:\WINNT.0\system32\GDI32.DLL 0x7757 - 0x775A C:\WINNT.0\System32\WINMM.dll 0x1000 - 0x10019000 C:\WINNT.0\System32\NVDESK32.DLL 0x6D20 - 0x6D207000 D:\jdk1.4\jre\bin\hpi.dll 0x6D3D - 0x6D3DD000 D:\jdk1.4\jre\bin\verify.dll 0x6D24 - 0x6D255000 D:\jdk1.4\jre\bin\java.dll 0x6D3F - 0x6D3FD000 D:\jdk1.4\jre\bin\zip.dll 0x6D01 - 0x6D0FB000 D:\jdk1.4\jre\bin\awt.dll 0x7780 - 0x7781D000 C:\WINNT.0\System32\WINSPOOL.DRV 0x75E6 - 0x75E7A000 C:\WINNT.0\System32\IMM32.dll 0x77A5 - 0x77B45000 C:\WINNT.0\system32\ole32.dll 0x6D1B - 0x6D1FF000 D:\jdk1.4\jre\bin\fontmanager.dll 0x6D35 - 0x6D357000 D:\jdk1.4\jre\bin\nio.dll 0x7503 - 0x75044000 C:\WINNT.0\System32\WS2_32.dll 0x7502 - 0x75028000 C:\WINNT.0\System32\WS2HELP.DLL 0x6D34 - 0x6D34E000 D:\jdk1.4\jre\bin\net.dll 0x7505 - 0x75058000 C:\WINNT.0\System32\WSOCK32.dll 0x7828 - 0x7828C000 C:\WINNT.0\System32\rnr20.dll 0x7798 - 0x779A4000 C:\WINNT.0\System32\DNSAPI.DLL 0x777E - 0x777E8000 C:\WINNT.0\System32\winrnr.dll 0x7795 - 0x77979000 C:\WINNT.0\system32\WLDAP32.DLL 0x728A - 0x728A6000
Re: [JAVA2D] ImageProducers
Edward, The BufferedImage object in Java2D was created for easier access to the pixels of an image, so I think you might find it easier to use that API for what you are doing rather than the ImageProducer approach. To get the array of pixel data from a BufferedImage, you could do something like: // createImage(w,h) doesn't guarantee a BufferedImage // but it works that way for now. There are other // ways to create a BufferedImage directly, but this // will do for this example BufferedImage bImg = (BufferedImage)createImage(w, h); Raster raster = bImg.getRaster(); DataBuffer dBuff = raster.getDataBuffer(); (I'm glossing over some of the details here, but these are the main objects that you would play with to set pixel data). Having said this, if your interest is in gaming and fast graphics, you might try to find a way to avoid playing with the pixels directly; if you could use higher-level API to set your pixel data that would be easier for the API to accelerate. For example, if you need to draw a line, it would be better to call bImg.getGraphics().drawLine() than to draw that line yourself (no matter how fast your line-drawing algorithm is). This is somewhat true for the current jdk release, but will be even more the case going forward. As of the next release (jdk1.4), we are enabling the use of hardware acceleration for offscreen images. But if you request access to the pixel data directly, we have to punt and disable acceleration for that image. I hope this helps. Chet. X-Accept-Language: en Content-Transfer-Encoding: 7bit From: Edvard Fagerholm [EMAIL PROTECTED] Subject: [JAVA2D] ImageProducers To: [EMAIL PROTECTED] As I haven't got any reponse, in the gamedev.net forums, I'm going to paste my question here. --- This is maybe a stupid question, but I don't feel like using my whole day digging the Java2D API refernce. So what's the fastest and simplest way to turn an Image into an ImageProducer, so that I could manipulate myself. The problem is that some of the images are changing, and I have to turn Images into inta rrays or something very quickly. Is there any way to simply make your array point directly to the image object so that I could quickly write pixels into it, or do I have to make a copy of an Image pixel by pixel into an array. Doing this would produce extra I/O, and that would hurt performance seriously. I haven't really been doing any extensive graphics programming in java, I've been doing everything relating to graphics in C asm, so if someone could help me I'd appreciate it. Thanks in advance Edvard Fagerholm === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Java2D flickering
Allan, When I run Swing and Java2D applications on my Windows 95 machine I see a lot of ugly dithering and repaint problems. How do I fix it? A: In most cases, this problem can be fixed by obtaining the latest DirectDraw drivers and the latest video driver for your video card. If you don't need to use DirectDraw, you might consider turning it off to see if that helps: java -Dsun.java2d.noddraw=true Can anyone clarify how this problem is the fault of the DirectDraw driver? I think this QA was directed at more problematic rendering artifacts than screen flickering; sometimes DirectDraw problems (either in Java2D or DirectDraw drivers) result in garbage on the screen that make using an application difficult. What I think you are seeing is something that I've seen when running stress tests that involve a lot of animations. The process by which we use DirectDraw to copy the bits onto the screen (and the way that DirectDraw locks the screen to allow that copy to happen) sometimes causes this flickering. I've seen this on other versions of Windows and DirectX and with various video cards. By turning off DirectDraw, you force the copy to go through a slower (and less flicker-prone) path. Our method of painting to the screen from offscreen buffers improves in our next release (we are now able to use the copying capabilities of the underlying hardware and thus avoid the screen lock and flicker). In the meantime, if you could provide me with more information on the jdk release and application that you're working with, I can look into the problem... Chet Haase. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] [Q] Best configuration for Java2D?
DoHyug Kim, Prior to the release currently under development (jdk 1.4), the only Java2D operations that are affected by the type of video card in the system are those going directly to the screen that could be accelerated by current PC hardware (opaque lines, fills, etc.). Otherwise, the video card has little impact on the overall performance of Java2D. This is because any operations going to offscreen images (such as back buffers) are using software rendering techniques. As of jdk 1.4, there will be support for hardware acceleration for offscreen images. In particular, simple opaque operations (fills and copies) will be offloaded to the video card if appropriate. At that time, the type of video card in the system will have some impact on the overall performance you see. However, since the range of operations supported through hardware is not that extensive (yet), it would not take a top-of-the-line video card to see good performance numbers; most video cards on the market for the past 3-5 years support the kind of operations that we will be accelerating. Some cards do these operations faster than others, of course, but the biggest improvement will be in using the hardware offscreen images instead of software images. Chet. As far as I know, the performance of Java2D is quite dependent on the specific configuration of PC (Especially what videocard is in use). And it seems that there were some emails from Java2D team in this mailing list explaining the results of their testing of Java2D on various hardwares. What I wish to know is what's the best configuration for maximizing the performance of Java2D. Could anybody share his/her experience? Thanks. DoHyug Kim === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Questions on jdk1.4
Sergei, The current releases all have hardware acceleration on Win32 for onscreen operations. We are currently working on hardware acceleration for offscreen surfaces for our Merlin release (jdk1.4). Chet. Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 From: Sergei Rodionov [EMAIL PROTECTED] Subject: Re: [JAVA2D] Questions on jdk1.4 Comments: To: Jim Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi Jim, version java2d, which would have native core? What do you mean by a "native core" to 2D? The reference implementation of the 2D API has always been a blend of both native and Java code, each being used where it seems to work best... i mean 2D that will use some hardware functionality, like for example i'm really looking forward to have fast BitBlt for Windows32 platforms :) Cheers, Sergei === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Performance: Windows Image -vs- BufferedImage
Ted, There is no inherent native performance advantage of loaded images versus BufferedImages - they both currently run through the same native software loops when copying data back and forth. The only advantage you might see would be due to the type of BufferedImage you are creating. That is, if you create the same type of BufferedImage as the loaded image is using, the performanced should be the same. But if you create a BufferedImage that is less optimal than the image type created internally when loading an image, then performance will suffer in the BufferedImage case. One thing to keep in mind when creating images is the type of image that you will be copying data to and from. For example, if you are creating an image whose data will be copied to the screen (such as a back buffer or a sprite), then creating an image of the same depth/type as the screen will give you the best performance (i.e., our copy loops won't have to translate between your image representation and the screen's; they can just copy the data as is). The easiest way to achieve this similarity between your offscreen image and the screen representation is to simply use the createImage(w, h) method. This method is guranteed to return you an image that has the same depth as the screen. As a side note, we are currently working on enabling hardware acceleration for offscreen images. These acceleratable images would also be created through the createImage(w, h) API (or through similar methods) and not necessarily through manually-created BufferedImage objects. The more control you hand over to Java2D in creating and manipulating the images (e.g., letting us create the most appropriate image for you instead of creating your own), the more possibility there is for Java2D to accelerate operations on that image (because we can make more assumptions about the data and representation of that image). I hope this helps. Chet Haase. Content-Transfer-Encoding: 7bit From: Ted Eiles [EMAIL PROTECTED] Subject: [JAVA2D] Performance: Windows Image -vs- BufferedImage To: [EMAIL PROTECTED] Assumptions: When I load an image from a file I'm getting a platform/native optimized implementation. When I create a BufferedImage I get an all-Java implementation. Questions: What are the speed and memory tradeoffs between the two implementations? Would saving dynamically create images (using BufferedImage ) to disk and then reading them back as native images give me better memory/speed performance in the long run? Thanks --- Ted === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Windows palette, X11 visuals, etc
Currently, the awt library sets the palette (when running in 8-bit mode, of course). We are thinking about changing this, though, and just using the default color map that is in place when the app is launched. This would work better, for instance, in the case you mention (having another app set up the system palette) and in the case of an applet running inside a browser (which should really be using the brower's colormap instead of trying to set its own). Chet. X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 From: Fred Stevens [EMAIL PROTECTED] Subject: [JAVA2D] Windows palette, X11 visuals, etc To: [EMAIL PROTECTED] This isn't really a Java2D question, but since the Java community at large is not too interested in issues of color accuracy, I thought I'd post here. The question is, is the Windows palette (and the similar X11 stuff about which I'm rather vague - it's been a long time) set by the VM or by application which invokes the VM? If I create a "launcher" app and set up a palette, will the VM change the palette or will drawing code dither to the palette I set? I suppose the answer is "the VM sets the palette" since looking at the "launcher" apps provided in "src.jar" shows nothing platform specific like this ... Thanks, Fred --- J F Stevens [EMAIL PROTECTED] (sic) 610/407-4476 (voice) 425/871-0808 (FAX) === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
