> That is what I thought. Unfortunately it is not the case. I have tried the > strategy of rendering to a 'dummy' VolatileImage. Using the opengl pipeline > it takes 2 drawImage calls before isAccelerated returns true. Using the d3d > pipeline I can not get isAccelerated to return true by rendering to a > VolatileImage. In both cases if I render my image to a Graphics2D in a JPanel > it only takes one call to its drawImage method for the image to return true > to isAccelerated.
Something isn't right here...The Graphics object given to the paintComponent() method isn't the screen Graphics: its a reference to Swing's offscreen back buffer which is an instanceof...VolatileImage. There should be no difference between that one and one created with GraphicsConfiguration.createVolatileImage() especially if they are on the same GC, which I expect they are. Both pipelines must act the same since both the back buffer Graphics and the Vol.Image Graphics will be of the same type. Though it is worth noting that any use of a VolatileImage must be validated before use and checked for validity after rendering to it as well. Again, see Chet Haase's blog on VolatileImages for examples and use cases. > Except for using -Dsun.java2d.accthreshold=0 the best performance I can get > is by getting into the Sun classes using: Again, you REALLY shouldn't be tapping into Sun private code here, its just too likely to go wrong without notice. > I think what might be going on is that the GraphicsConfiguration that > validate needs to use to make an image accelerated when drawing to a Graphics > object that paintComponent gives you is different to the one that > getDefaultConfiguration() returns. NO! that is not it. I just tested it. So > what is going on? In a typical one monitor/one desktop scenario, the default GraphicsConfiguration will be the one that is used for everything. The best advice I can give is to create a dummy V.image and then render images to it a few times upon image loading (as you said this is on a different thread, be VERY careful about thread safety/ data visibility here, esp with regards to rendering to swings back buffer, which should only be done on the EDT). Validate the VolatileImage before rendering to it, and also remember that only a certain amount of images can be accelerated at once due to available graphics memory. The ImageCapabilities class or something similar can report available graphics memory, but remember but this doesn't mean Java has access to all of it, and also some images such as certain translucent ones may not be managable on all pipelines/hardware. [Message sent by forum member 'fred34' (fred34)] http://forums.java.net/jive/thread.jspa?messageID=218100 =========================================================================== 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".
