Even though http://www.ismavatar.com/lgm/forum/index.php?t=34 seems to be fixed, the Room/Tileset system still seems to be suffering from slowdowns.
Just as I posted in the other thread, here is the issue:
«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, LGM even froze.»
However, my system usually grays windows that are not responding, but the LGM window didn't change, so although Java froze, the X system didn't recognize that.
useradd
more /root/Bugs/Room editor - Still slow.thread
Confirmed that after about 350 tiles (independent of tile size), the room editor starts hiccuping for extended times, usually around 5 seconds. Removing tiles does not seem to cure this problem. Caching the tile image does not appear to help either.
As mentioned in the other topic:
* Clam has expressed interest in rewriting the room editor to be much faster.
* I expressed interest in support for external room editors at a time when the room editor was not as functional as it is now. I'd still like to see this support, but so far no candidates have appeared or taken the initiative.
* Shortly after my initial room editor attempts, Quadduc introduced the concept of treating tiles and instances as Swing Children, insisted on its use, and implemented it. We're still not sure why he did this, and it made handling tiles and instances much more difficult. This may be a part of the cause for the slowdown. This also makes it much more difficult to efficiently fine-tune caching and other efficiency strategies. I suspect Quadduc had his reasons, or else he would not have done it - but he has not yet spoken up on the matter.
Whatever the solution, I expect that it will take some time to implement.
As mentioned in the other topic:
* Clam has expressed interest in rewriting the room editor to be much faster.
* I expressed interest in support for external room editors at a time when the room editor was not as functional as it is now. I'd still like to see this support, but so far no candidates have appeared or taken the initiative.
* Shortly after my initial room editor attempts, Quadduc introduced the concept of treating tiles and instances as Swing Children, insisted on its use, and implemented it. We're still not sure why he did this, and it made handling tiles and instances much more difficult. This may be a part of the cause for the slowdown. This also makes it much more difficult to efficiently fine-tune caching and other efficiency strategies. I suspect Quadduc had his reasons, or else he would not have done it - but he has not yet spoken up on the matter.
Whatever the solution, I expect that it will take some time to implement.
I'm not seeing the exact same problem, but it's similar...
I have a room with 400-500 tiles and about as many objects, and I can add several hundred tiles more without the editor becoming too slow (updates in less than half a second).
However, if I switch from the "add" tab to the "edit" tab before starting to add tiles, it's noticeably slower, maybe twice as slow. Furthermore, if I have already added many tiles before switching tabs, the program will freeze for several seconds, or even lock up completely.
The problem seems to be the JList of tiles, or at least the way it's updated. I removed the code that updates frame.tList in RoomEditor.processLeftButton, and in a room with more than 1600 tiles I could add 10 tiles per second holding shift, no hiccups at all.
I have a room with 400-500 tiles and about as many objects, and I can add several hundred tiles more without the editor becoming too slow (updates in less than half a second).
However, if I switch from the "add" tab to the "edit" tab before starting to add tiles, it's noticeably slower, maybe twice as slow. Furthermore, if I have already added many tiles before switching tabs, the program will freeze for several seconds, or even lock up completely.
The problem seems to be the JList of tiles, or at least the way it's updated. I removed the code that updates frame.tList in RoomEditor.processLeftButton, and in a room with more than 1600 tiles I could add 10 tiles per second holding shift, no hiccups at all.
With regards to Ism's first point above, I really just wanted to see if the editor could be made more ergonomic. At this stage I'm not going to attempt it due to other projects I'd like to finish, and also because I've made a start on a javadoc-esque system for the built-in functions (and a corresponding extension of the CompletionMenu).
I'm working on the instance and tile lists. I will make a custom ListModel that listens to changes in the list of instances or tiles. This means I will also have to use a custom ArrayList for the instances and the tiles.
Quote
The problem seems to be the JList of tiles, or at least the way it's updatedThis was also the issue with t34 in which the JList selection change caused the ResourceSelector selection to change, which caused the tile preview to update. The tile preview update was using inefficient code, so I corrected that with r329.
I found that by using a similar method to when a GmFile is loaded to time something, I could debug to locate where the bottleneck was. These may help to better locate what is causing this.
The excessive slowness disappears completely when I remove the line that sets tList's CellRenderer. I'll take a closer look at that soon.
This should all be fixed in r344.
Confirmed. Redownload the beta.
For me, now there's no significant slowdowns until about 1000 tiles, at which point the slowdown is still less than a second.
There is a bug with tiles with different width and heights, but that's unrelated to this.
For me, now there's no significant slowdowns until about 1000 tiles, at which point the slowdown is still less than a second.
There is a bug with tiles with different width and heights, but that's unrelated to this.