Where can I see, whether anything happened at all? Because when importing preferences, it was asking for a "*.epf", which the import-me was not. (At least it didn't find it until I changed the extension to look fo "*.*".
It should have updated the user preferences. In particular, the ones regarding how code was formatted (indentation style and which column to insert line breaks) and how the tool modifies code (adding import statements for individual classes instead of all in a package, and trimming spaces from the ends of lines when saving).
Some of those are not going to be visible (like spaces at the ends of lines) and others are only applied when something changes (like the import statements). You can verify the import by deleting the import that uses an "*" and then saving the file and seeing how Eclipse regenerates the import statements.
The distinction is important. The EDT does not only react to user interaction but to programmatically issued redraw events as well.
Exactly -- it is important. Which is why I said "GUI" and not "EDT". You are right that repaint events can still be delivered while the "GUI" is blocked because the EDT is not
blocked. I was not aware that repaint events are still generated while the GUI is blocked. I'll need to figure out why that would be happening and not being deferred until later.
I haven't seen any image problems. Concurrency was with the members I mentioned and that came from PropertyChanges, I believe.. I also haven't seen any concurrency library being used. But then I might be foraging in old code.
Image problems are the visual manifestation of (most) concurrency bugs in MT. (Obviously, since it's primary purpose is the display of graphics.)
Yeah, the concurrency library stuff is pretty isolated and was fairly recent. I don't recall where it's actually located...
Well, do you want the bug fixed or not? The synchronized is a sure thing here. I am certain that you will not see that string again, as long as the synchronizing is observed.
[...] Therefore all other access to the cache should be removed.
Sounds good to me.
Obviously it was added for a reason so I'll need to look at the patch to determine if there's a side effect somewhere, but this sounds like the way to go.
I haven't noticed any difference. Do you have any specific performance tests? I noticed a lot of timers in there but don't know how to read them.
When running MT go to the menus and choose Collect Performance Data. I think it's on the Tools menu, or maybe the View menu. Now you'll be able to measure the performance difference.
I also don't know how my HW relates to the weakest HW you intend to release on. I have Ubuntu 10.1 on i686 (and ran maptool out of the box, ie. no memory increase).
I'm not too concerned about that. We have some folks running MT on Java 5 on really old PowerMacs, but they're going to be dead when we move to 1.4 anyway. I'd like them to have a usable 1.3 though.
What do you mean by "validity toggling"?
I have traced the problem into the renderToken
routine. Sometimes the locations for tokens (more precisely, objects on the BG layer; but they all go by the name of token in the code as far as I can tell) are available in the cache, sometimes they are not. For "general repaints" the locations are there, for rescaling events they need to be generated. But for some reason the initial "general redraw" has invalid locations. Off screen? I don't really know and I don't know what separates the rescaling repaints from the ordinary, eg. initiated through map shifts.
Hm. I vaguely recall the code you're talking about, but I'll need to look at it to be reminded. I believe the background layer is rescaled and saved in a BufferedImage so that later repaints can simply blit the image into the visible component. Changing the zoom level requires the BufferedImage to be regenerated. Things that users can interact with during normal operation are not part of the BufferedImage (since that would make them more different to manipulate). The same applies to the fog of war re: caching the results.
It is very tedious to find out the deeper roots for this.
You've got that right! Every time I go into the code I find out something else I didn't know about.
As you said, 1.3 is in its final phase. I'd rather carve out the cache and use it locally in paintComponents only.
As above... Go for it.
How does 1.4 profit from 1.3 fixes?
Good question. We expect that much of 1.4 will be written from scratch by the time a final build comes out. There are ideas for redoing the VBL, redoing the way campaigns/maps/tokens are saved and loaded, and taking advantage of new technology like JavaFX. Since it will be built on an OSGi base, much of the internal plumbing will be different.
I doubt anything done to 1.3 at this point will be carried over as anything more than a learning experience.