[GRASS-dev] Issues of 6.5 build on WinXP

[Glynn Clements]

Michael Barton wrote:

> I've tried to follow this all out. As it is currently written, it is not
> easily fixable. As best I can tell, OnUpdateSelection (called with every
> key press) sends the window ID to a threaded routine, which then uses
> the ID to grab what has been entered after each keypress and send that
> to another thread-related routine that populates the dictionary for the
> vector map with its database connections, layers, and columns for each
> related attribute table. This happens after each keypress. Of course,
> for most keypresses, there is no valid vector map and the attempt to
> create a dictionary fails. There may be a try/except somewhere to catch
> this, but I didn't see it.

It runs the commands every time. If the map name isn't valid, the
command won't generate output.

> Probably this is where most of the slowness
> is. It doesn't seem to slow down my Mac more than a blink. But, the more
> columns there are, probably the more it drags. Also, the size of the
> vector might slow it down too. 

The size of the vector shouldn't affect it. It's mostly a question of
how long the various commands take, which will depend upon the
platform and (for db.describe, the database). The lag is much worse on
Windows than Linux.

> Anyway, I can't see an easy way to turn off this check on each keypress
> the way it is now because it must get the ID of the widget that contains
> a map name for the update to work. It seems to me that i more
> straightforward way to accomplish might be to simply have each keypress
> build a mapname in a variable [e.g., vecname]. Whenever a combobox that
> needs associated columns, layers, or db connections is clicked, it runs
> gselect.ColumnSelect.InsertColumns(vector=[vecname]) to refresh its
> values. This might lag a bit when the combobox is opened. But a check
> could be made to see if [vecname] has changed and skip the refresh if it
> has not. This would confine a lag to the first time open.

Even if it occurs every time the menu is popped up, that's better than
having it occur every time a key is pressed while typing in a map
name.

> To do this would require a fair amount of rewriting.

Much of the slow-down could be removed without significant structural
changes by:

1. Making a list of existing vector maps at start-up and only
executing the commands if the map is in that list. This list should
already exist in order to populate the menu for the map name combo box
(however: this doesn't work for me on Windows; the menu lists the
mapsets but no maps).

2. Storing the output from the commands in dictionaries keyed with the
map name, and only running the commands when a stored value isn't
found. This would mean that the commands would be run at most once for
any given map name (rather than running the same commands for the same
map once for each combo box or option menu).

-- 
Glynn Clements <glynn at gclements.plus.com>