> 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".
