(using Linux Ubuntu 8.10 and Java 1.6.0_06, but I think it's a cross-platform issue)
In order to reproduce this, you'll need a fairly big tileset.
Just pick a tile and keep placing it in the room at different locations. You should notice that it takes considerably long to place it.
Possible reason:
For every single tile(even if you keep using the same), it keeps cropping before drawing.
Possible solution:
Try to create some sort of "tile cache". If the room keeps requesting the same tile, keep giving it the same one, rather than generating a new one.
useradd
more /root/Bugs/Room editor - Use of tiles too slow.thread
We do cache individual tiles, and originally we also cached tiles that were the same when they appeared sequentially, but Quadduc requested that we utilize swing children for tiles and objects, and this made it relatively impossible to fine-tune caching like I had.
If you can reproduce this problem at 1:1 scale (zoomed in all the way), then it is not a scaling problem.
The room editor is well known to be quite slow. Clam has said he wanted to give it a face lift. I've expressed interest in utilizing external room editors at a time when ours was quite lacking in functionality, but have since implemented the needed features.
We'll discuss this, but I suspect that any real changes will take time. In the meantime, I'll see what can be done about a better cache.
If you can reproduce this problem at 1:1 scale (zoomed in all the way), then it is not a scaling problem.
The room editor is well known to be quite slow. Clam has said he wanted to give it a face lift. I've expressed interest in utilizing external room editors at a time when ours was quite lacking in functionality, but have since implemented the needed features.
We'll discuss this, but I suspect that any real changes will take time. In the meantime, I'll see what can be done about a better cache.
I did not use zooming.
What are the advantages of having each tile as a Swing child?
What are the advantages of having each tile as a Swing child?
Ah, misread cropping for scaling. No, we cache the cropped image for each tile, but tiles with the same image do not share their image, which is one optimization we could look into.
I'm not sure what advantages there are to having each tile as a Swing child aside from that they are stored in one central list that already exists, rather than having to create our own list. You'd have to ask Quadduc, since he was pushing for it, and eventually coded it.
I'm not sure what advantages there are to having each tile as a Swing child aside from that they are stored in one central list that already exists, rather than having to create our own list. You'd have to ask Quadduc, since he was pushing for it, and eventually coded it.
I've tested this with and without image-caches across 8x8, 16x16, and 32x32 tiles, and on my machine, after about 370 tiles (regardless of size and cache), it begins to experience hiccups. Deleting tiles does not reverse the hiccup trend but actually seems to make it worse.
I was actually making an experiment with only a few(like 10-20) tiles. A delay(around 1 second) was already noticeable - not when redrawing but when placing a new tile.
In that case, the slowdown seems to be the preview used for ResourceMenu. Once I remove that, 16x16 tile placement for a 1600x1200 tileset is instant.
This is resolved in r329. Please re-download the beta.
I downloaded it again. It is much better(I also disabled splash screen so no crashing on drag&drop).
However, after some(about 50) tiles, it starts to have a very small, almost undetectable slowdown. As more tiles are placed, LGM tile placing keeps getting slower and slower. Eventually, it even froze.
However, after some(about 50) tiles, it starts to have a very small, almost undetectable slowdown. As more tiles are placed, LGM tile placing keeps getting slower and slower. Eventually, it even froze.
That is a separate bug. Start up a new thread for it.