Ok i will get straight to the point, the program I'm writing is an 8-bit
console emulator
The performance wouldn't be noticeable at all if I sync the speed to refresh
rate on modern pc (any PC that is made in the past 8 years should be able to
run it) but for comparison sake, an equivalent C++
[EMAIL PROTECTED] wrote:
Ok i will get straight to the point, the program I'm writing is an 8-bit
console emulator
The performance wouldn't be noticeable at all if I sync the speed to refresh
rate on modern pc (any PC that is made in the past 8 years should be able to
run it) but for
Geforce ti 4 4200 , pentium 3 500 slot1 agp motherboard and pentium3 800 with
onboard SiS 630. all running Windows XP :)
With 6u5 and -Dsun.java2d.noddraw=true I get similar performance to 6u10b22
(-Dsun.java2d.d3d=false) The drop is much bigger than going from accelerated
pipeline to
Forget what I said about P3 800 performance, it seems the cause of performance
degradation was due to my own rendering routine, I tested my app once again on
j6u10b22 the performance was similar to j6u5(a little slower) after I removed
the problematic part.
(It seems the pipeline is off by
[EMAIL PROTECTED] wrote:
Forget what I said about P3 800 performance, it seems the cause of performance
degradation was due to my own rendering routine, I tested my app once again on
j6u10b22 the performance was similar to j6u5(a little slower) after I removed
the problematic part.
(It
[EMAIL PROTECTED] wrote:
I saw the bug report, and it seems the solution has yet to be found , but i
believe a solution is still being worked on judging by the log messages.
Correct.
So I assume that there is no workaround , and probaly I'm better off with j6u5
for the time being and
I saw the bug report, and it seems the solution has yet to be found , but i
believe a solution is still being worked on judging by the log messages.
So I assume that there is no workaround , and probaly I'm better off with j6u5
for the time being and perhaps I will test b23 with my app when it
Thanks for the advice, Do you know of any temporary workaround for this issue?
and you did mention b23, is b23 going to resolve this problem? If not, it seems
direct pixel manipulation is a performance killer on the new pipeline so is
some kind of a fix being planned for future releases ? Is it
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):
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
[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
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
Hi, there I'm writing a program that draws to a volatile Image by setting every
pixels manually every frame.
When I tested my program with java 6u5 I got 460-500 fps on average, however
with java 6u10 the performance drops by almost 50%, from 450 to 240. I have
done several test runs with both
Hi,
which 6u10 build are you running? We have made some
optimizations in I believe b23 (which isn't out yet)
which may help this case.
Also, what's your video board? Could you
please set J2D_TRACE_LEVEL=4 env. variable,
then run your app and post the output.
Could you post a
14 matches
Mail list logo
