-Dsun.java2d.trace=log

Java 2D
#1

-Dsun.java2d.trace=log generates allot of sun.java2d.loops.Blit::Blit’s and a few sun.awt.windows.Win32BlitLoops::Blit (about 1 to 5). Does this mean that only about 1 out of 5 of my blits are accelerated :-[.

I am also using Dsun.java2d.ddscale=true
which is working fine except the entire image is Antialiased… Runs fast but does not look right. Anyone have any idea how to force a scale without doing Antialiasing.

#2
  • looks like that’s the case. The Blit::Blit is a software loop, while Win32BlitLoops::Blit is hw-accelerated.
    I’d suggest to find out which which images are not accelerated - like, run your app step by step (with sleeps or debugger) and see which primitives are being used. Also, remember, if you use images with hidden acceleration, and render to those images more often than you copy from them, they won’t be accelerated.

If you post your typical trace=log output, I might be able to tell you what’s wrong.

  • ddscale basically enables use of hardware for scaling blits. What you’re seeing is not anitialiasing, strictly speaking, but filtering. The way a particular hardware does filtering is often beyong our control. This is exactly the reason ddscale is turned off by default.
#3

Thanks,

I will not be able to provide a trace=log output till later this afternoon… but I have a few more questions…

  1. Can the copying of “part” of a VolatileImage to another VolatileImage be accelerated? using drawimage to only copy a part of a VolatileImage to another?

  2. Will java ever be able to do an accelerated alpha blending blit? This is very important to my application.

  3. Will java ever be able to do a hardware scale that is not filtered? Similar to the unaccelerated scale that java does currently.

  4. What is hidden acceleration?

At this point I am have been able to get some great frame rates 120+ at 800x600 with user interaction 6 layers, sprites, effects, sounds, collisions detection… etc… Unfortunately the limited control over ddraw that java gives is causing rather large inconsistencies across different machines. The current problem with ddscale=true filtering my blits is just about the last headache I need before I go back to a different headache … C++ and directx :o.

#4
  1. Yes, it will be accelerated
  2. Yes, we’re working on this for our next major release, and we might even be able to give some relief (like accelerated blending of translucent images) before that in one of the update releases.
  3. we’ll look into this. But it mostly depends on the hardware capabilities.
  4. we accelerate some types of the images under the hood, i.e. transparently for the application. Under ‘accelerate’ I mean that if we detect that the image is copied from more than it’s rendered to, we create a copy of this image in vram, so the following copies of this image happen in hardware - vram to vram. Currently (as of 1.4.1_01) we accelerate images created with
  • Component.createImage(w, h)
  • GraphicsConfiguration.createCompatibleImage(w, h)
  • GraphicsConfiguration.createCompatibleImage(w, h, Translucency.BITMASK)
  • GraphicsConfiguration.createCompatibleImage(w, h, Translucency.OPAQUE
  • images loaded with Toolkit.getImage
    There used to be an article by Jeff on this stuff on the old java-gaming.org, so hopefully it’ll be back soon, so you’d be able to get more details on hidden acceleration. Until then, there’s some info in this article:
    http://java.sun.com/products/java-media/2D/perf_graphics.html
#5

And there was much rejoicing :D.

Thanks Trembovetski