On Sat, 11 Dec 2021 17:44:13 -0000 "Stian Grenborgen" <stian...@users.sourceforge.net> wrote: > I have fixed several performance issues already. For example, we had a full > repaint of the entire map every time the mouse moved 1px! We probably need > better testing in order to avoid such problems in the future, as such > mistakes are easy to make.
That was probably me earlier this/last year. There were a whole bunch of weird cross references between *GUI, Canvas, *Frame, *Viewer. I tried to make sure everything low level went through GUI, and higher level functionality moved to Widgets. This was worth doing not just for clarity as it revealed a bunch of dead code, but yeah, probably was not well tested at the point I had to step back with the job incomplete. > BTW, the supporting code that made the game run smoothly on a 200MHz CPU have > disappeared. Like fullscreen mode, buffer strategies (page flipping etc), > aggressive clipping and incremental painting. IIRC full screen mode had some nasty fail on Windows that wintertime concluded was intractable. I do not recall what happened with the page flipping and incremental painting. I do recall seeing cases where the clipping was causing broken images but not who/how that was fixed --- my only involvement was complaining because I was trying to fix a bug in animation. > Adding such optimizations back in might be unnecessary, though, as ten year > old hardware can render the entire map in HD several times per second. In > addition, we cannot add the original code back in without also converting > every JDialog back into a JInternalFrame. The JDialog problem is my doing, and alas, I have to stand by it. I can remind you of the last time we discussed it below. TLDR: JDialog is a pain but an unfixable bug that hangs games inside our fake event loop is worse. > But then again, I think 250ms latency while moving the map is acceptable. My > guess is you want the latency to be lower than 100ms? 250ms for a big map change is fine. I was seeing really slow single unit moves (independent of animation) without any map changes. I just did a quick test of the current trunk and can not reproduce that ATM. When I get a bit more time together I will haul the old machine out of the shed and see if it is still there, but things are looking hopeful. Cheers, Mike Pope ----JDialog-is-bad-but-at-least-it-does-not-hang-the-game---- From: "Michael T. Pope" <mp...@computer.org> To: freecol-developers@lists.sourceforge.net Cc: stian...@student.matnat.uio.no Subject: Re: [Freecol-developers] Weird full screen problems Date: Mon, 27 Jan 2014 22:31:39 +1030 Organization: FESOSA On Fri, 24 Jan 2014 20:08:09 +0100 "Stian Grenborgen" <stian...@student.matnat.uio.no> wrote: > Another problem with using JDialog is that they don't mix well with > JInternalFrame. Layering, focus etc is handled by the windowing system for > the former, while JDesktopPane handles it for the latter. That's why the > ChooseFoundingFatherDialog is always in front of the Colopedia help panel > you get when clicking the "help" button, for example. True, but this is new code, and there is a routine in place to try to place both dialogs and frames such as to avoid overlap. I do not know why it is not working in this case, but this looks like a mere bug, not a fundamental showstopper. Now I cheerfully concede not really understanding Swing et al. What I do understand is FreeCol bug reports. Here is the justification for the JDialogs: - Some dialogs in FreeCol need to be modal, some need to be non-modal. - We had a trick for non-modal dialogs the centered around reimplementing an event loop handler inside FreeColDialog.getResponse. This was very clever, but outdated (did we really want to track the Java event loop code? no one had ever bothered) and brittle --- for unknown reasons it was occasionally possible to get stuck in the getResponse handler, and as such caused at least six, and possibly as high as twelve serious FreeCol bugs (we will never know, it was a client-side effect and did not reproduce easily, so several reports are suggestive but frustratingly inconclusive). - When a getResponse bug hit, there was nothing you could do but kill freecol and restart from the previous save. That is serious. - JDialog is a standard way to provide a modal or non-modal dialog. I consider that a strong case for killing getResponse. Even if it were true that JDialogs are causing windowing misbehaviour, that is nowhere near a game-killer bug. > Considering the other problems with dialogs appearing behind each other: > It should be possible just to grab the panel that is blocking the other, > and click on the panel behind. Unless you are clicking on a component (or > there are additional JPanels intercepting the mouse click), this should > make the panel you click appear in front. Isn't this working? In every case of overlap I have seen, yes, grabbing and moving either panel fixes the problem. Annoying, probably worth a bug report, but not a showstopper. The bad breakage is when panels or dialogs appear *behind the map*. That one is baffling. I do not understand how a JInternalFrame can do that, and all JDialogs should be getting a focus request when first brought up. Cheers, Mike Pope
pgp2F1ZmXmS6j.pgp
Description: OpenPGP digital signature
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
