Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10

I'm using the latest one which is b22, as for the test case, I wrote a small program that update every pixels as fast as possible using VolatileImage and measure the performance by frames per second result (VolatileImage): Java 6u5 1300+ fps Java 6u10b22 450+ fps result (BufferStrategy):

[JAVA2D] How to draw continuious bezier cubic curves?

Hello How to draw a moving, continious bezier cubic curve??? It should twist and move up and down in a snake-like way. Much like the old snake game. Any suggestions? Thank you very much for your help [Message sent by forum member 'autaron' (autaron)]

Re: [JAVA2D] Performance regression in 6u10 b22

Then it is likely caused by this fix, although I don't quote see how http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308 We did a bit of testing and one necessary correctness change in this bug fix was made in SrcOver software blit and fill loops. ie I know exactly which line

Re: [JAVA2D] Performance regression in 6u10 b22

Another observation we have made is that it appears that Substance Look and Feel does lots of unaccelerated rendering - meaning, rendering to un-accelerated destinations. Unfortunately this affects performance negatively when the D3D pipeline is enabled: first, we do most of the

Re: [JAVA2D] Performance regression in 6u10 b22

I would suggest to reduce the number of operations you do to BufferedImages. If you use some temp. buffered images for rendering, consider changing them to translucent volatile images (assuming you don't need access to pixels). This will not affect performance when these are not

Re: [JAVA2D] Performance regression in 6u10 b22

Hi Kirill, [EMAIL PROTECTED] wrote: Dmitri, I did not see any change (on unaccelerated pipeline) between these two ways to create an offscreen image: [code] BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB); Graphics2D graphics = (Graphics2D)

Re: [JAVA2D] Performance regression in 6u10 b22

Hi, Dmitri In both cases above you create a BufferedImage, not a Volatile one. To create VolatileImage, you'd need to use GC.createCompatibleVolatileImage(). (you'd need to add some extra code to validate them before you use them though, but for testing purposes, just validate them once

Re: [JAVA2D] Performance regression in 6u10 b22

[EMAIL PROTECTED] wrote: Hi, Dmitri In both cases above you create a BufferedImage, not a Volatile one. To create VolatileImage, you'd need to use GC.createCompatibleVolatileImage(). (you'd need to add some extra code to validate them before you use them though, but for testing purposes,

Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10

Thanks for the test and the data. I'll file a bug (if there isn't already - I vaguely recall having filed something like this). There may be a way to speed up BufferedImage - accelerated surface copies. Thanks, Dmitri [EMAIL PROTECTED] wrote: I'm using the latest one which is

Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10

[quote] Thanks for the test and the data. I'll file a bug (if there isn't already - I vaguely recall having filed something like this). [/quote] And indeed I have: 6652116: D3D: SW-Accelerated surface blits are slower with the new pipeline I think I still have a couple of things to try

Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10

A colleague pointed out that you're rendering directly to the screen (frame.getGraphcis()...), which is a no-no in a swing application. The performance issue is not related to this, but just FYI, you don't want to do that. Dmitri Dmitri Trembovetski wrote: Thanks for the test

Re: [JAVA2D] Performance regression in 6u10 b22

Then in theory it should be fast once the cache is filled since images can be cached in textures- but according to the primitives log there's lots of unaccelerated rendering going on - may be the benchmark basically only catches the cache fill phase? Dmitri, The benchmark should catch