compatible images

I’ve uploaded svn4360 which contains the following things:

  • Fixed Bug 2107274: GeneralFilter gets images with wrong data type.
  • ImageOps all use BufferedImages now.
  • Most BufferedImages are compatible images, for optimal display speed.
  • New BufferedImages are created with alpha only when necessary.
  • Removed almost all casts from Image to BufferedImage.
  • Created special RGB case for GeneralFilter which is 12% faster than ARGB.
  • Extended MappedBufferedImage to support all image types.

“Compatible” images are images which have the same storage layout as the
underlying video memory, which means that they can be blitted to the screen
without any conversion. In most cases, the underlying video memory is going
to be arranged as 24-bit RGB packed into 32 bits with the high byte empty.
Converting 32-bit ARBG, which was what we were using most places, is pretty
efficient, so you might not notice much difference from this change on your
system. However, if you’re on a system where the underlying video memory is
arranged differently, this will be a huge performance win for you.

There are methods now for dealing with compatible images in ImageUtils.

Additionally, zooming is now 12% faster for maps which contain no
translucent pixels (which should be virtually all maps) because in that
case the alpha channel, which normally accounts for 1/4 of all bytes
handled during zooming, can be ignored.

I doubt many of us users would even know where to look to see how our video memory is arranged - so heres asking :slight_smile:

Thus spake “Tim M”:

Well, this isn’t a setting I added. It happens automatically , so the user
doesn’t need to know about it.

If you’re curious, you could write a little program which allocates a
compatible BufferedImage and then checks what kind it is.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)