Token rendering

[trevor]

it's not so much an issue of rendering speed so much as an issue of managed images.

In java, if you have an image and render it a few times without writing to it, it will be put into your video card memory behind the scenes, which makes it wicked fast to render. With the patch you are essentially redrawing the image every frame. This prevents java from accelerating it.

With a couple of tokens, that's probably fine, but I imagine when rendering the entire map with tokens it'll start to take a toll.

We could use intermediate images, which will give us the speed, but will take up a lot of memory, so that's not optimal.

The correct solution is what I have planned for 1.4 where the rendering pipeline is completely rewritten. It needs to only redraw parts of the screen that change. So an image is only rendered once until it (or something it overlaps) changes.

That will let us spend more time making the rendering look pretty because the per-frame rendering cost is reduced quite a bit.

[Mathemagician]

Speaking of 1.4....is the little one an expert coder yet? When will she get her hands on a section of Maptool code?

[StelardActek]

Ahh, I see what you mean, yes.
I did also have an idea of storing the pre-rendered images, dropping and rescaling them whenever the zoom level changed, but... yeah, it hardly seemed ideal. Only rendering portions that change seems like a far better ideal. I'll wait until then before looking at this again.