1.0.6.0 ExpansionPlanner woes.

[torrenal]

Expansion Planner -- When there are tons of rows in the table and I colonize one planet, I find myself (in my current game) waiting a full two seconds for the plan to update with the colony ship icon appearing on that row. I've seen delays over 3 seconds in some games.

A trademark of the delay is the scroll bar starting with the full space, then rapidly shrinking to occupy just the top ten or so pixels of the scroll-bar space.

This, sadly, is a common bug I find in software products everywhere (yes, even the one I develop at work) and very easy to fix. In java, the fix works something like: ----- TableModel model = table.getModel(); table.setModel(new TabelModel());

updateModel(model); /* Routine to update the model with the new data */

table.setModel(model); /* Reselect current row here */ ----- By setting a blank model, when you update the real model, the GUI is not required to update the screen, allowing the quick update of multiple rows, and setting the model back at the end triggers the only required redraw of the table. The net result in my experience has been multi-second updates being reduced to immeasurable times (99+% of the delay is eliminated). //Torrenal

[Carewolf]

If you think that is bad, try selecting "By galactic priority", this lists all know moons and planets, and often takes so long that Windows asks if it should terminate the program for me.

This is probably either a "Update UI for each sub-change" mistake (like you suggest) or a "Append to end of list" mistake. One making O(n) graphical updates or the other making O(n*n) logical updates. I find it odd that the UI should be so slow that a few hundred updates should be able to stall it, but it is not unlikely. As a developer I more often see the append to end of list go horribly wrong as a short list of ten elements take in the order of 100 operations, making the application pass small tests in flying colors, but where a real-world list of of 100 elements suddenly takes in the order of 10000 operations and cripples everything. When using standard libraries it is often also hard to know if a data-structure has fast or slow 'append to end of list' mechanics, so it is not even something the developer has a chance to be aware of before it explodes in their face.

[torrenal]

ORIGINAL: Carewolf
This is probably either a "Update UI for each sub-change" mistake (like you suggest) ...

Watch the scroll bar on the right side.
It shrinks dramatically during when it starts rebuilding the list. This is a clue that it's calculating the size of the table repeatedly, and each time it calculates the size, the table is larger, and thus requires a smaller scroll-bar.

It's an 'Update UI for each sub-change' error. The performance is roughly equal to what I see out of a Java table with a similar number of rows and a 'update UI for each sub-change' error.
//Torrenal

[Carewolf]

ORIGINAL: torrenal

ORIGINAL: Carewolf
This is probably either a "Update UI for each sub-change" mistake (like you suggest) ...

Watch the scroll bar on the right side.
It shrinks dramatically during when it starts rebuilding the list. This is a clue that it's calculating the size of the table repeatedly, and each time it calculates the size, the table is larger, and thus requires a smaller scroll-bar.

It's an 'Update UI for each sub-change' error. The performance is roughly equal to what I see out of a Java table with a similar number of rows and a 'update UI for each sub-change' error.
//Torrenal

Yeah you are right, it does looks like that. I don't usually do UI, so I guess I am just biased to different types of performance problems

[torrenal]

Meh. I just see this alot. Not counting the bugs like this I've fixed at work, and not counting DW, I deal daily with 3 applications that have the same thing going for them.

I'm also someone who pays intense attention to the UI. Things like this stand out for me -- I'd spot it even if we were looking at 50 rows and a 1/2 or 1/4 second delay
//Torrenal

[Wicky]

When you send a constructor, a new mineral source is acquired and the demand is not so high anymore. The game must take into account when priorities shift, and when other minerals take it's place in the galaxywide resource ranking, AI constructors need to re-evaluate targets, etc. You get the point.

[unclean]

Bump! This one is really annoying.

If the current behavior needs to stay for some reason it should at least let you make multiple selections.

edit: this is still around in 1.5.0.1