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 rendering
into BufferedImages, then they are blitted into the
accelerated destination (Swing back buffer). This last
operation is known not to perform well on most boards
(see another thread in this forum).
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
accelerated but will help when they are.
Thanks,
Dmitri
Phil Race wrote:
> 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 of code makes the performance
change come and go in your app, but its not something we can undo.
The strange part of it is that the change is just a compile time
macro so that for opaque destinations, there should be no runtime cost.
ie logically if anything it should lead to less work, not more.
And for non-opaque destinations, it should be exactly as it was before.
Not sure why it affects your app - we couldn't make it show up
any of the tests in J2DBench2. Either the Microsoft compiler
is doing something that adversely affects the generated code,
or perhaps the different results in the opaque dest case cause
more work to be needed, but it seemed likely you were hitting
the first case.
-phil.
Dmitri Trembovetski wrote:
[EMAIL PROTECTED] wrote:
Hi, Dmitri
The output of trace_level:
[I] OS Version = OS_VISTA or newer
[E] D3DPPLM::CheckForBadHardware: found matching hardware:
VendorId=0x8086 DeviceId=0xffffffff
[E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled
[E] D3DPPLM::GDICheckForBadHardware: no suitable devices found
OK, you have an Intel chip. The d3d pipeline is
disabled for all Intel boards so the regression
is probably not related to the d3d changes in this
build.
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
Does your code render to translucent images much?
===========================================================================
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".
