4.0b Beta 3: Very slow closing BWS panel

Lynden Williams said:

Rosie, can you be more specific. I ran a study on God using greek resources inlcuking the LXX and it responded right away. I am using the latest beta.

Yes, sometimes it is fast for me too. But here are steps to consistently reproduce the slow version:

Create a custom BWS template with just the Translation section in it, call it, say "BWS - Translation."

Open ESV, go to Gen 3:15, open Interlinear pane

Click on "he" in Gen 3:15 to scroll interlinear pane to that word

Right click on the Lemma for he ("הוא") - select Lemma tab on right of pop-up menu, and "BWS - Translation" from left side.

Click on the word "he" in BWS graphic to expand it out and show all places where it occurs (we're alreading grinding to a pretty slow speed by this time!)

Click the X to close the BWS window and start a stopwatch.......  It took 35 seconds to close!

Will try again to reproduce this after a reboot, but it's completely consistent even after shutting down and restarting Logos.

Lynden Williams said:

Rosie I concur. Just clicking the word in the center of the graph and Logos stops responding for a while. Closing it took 23 or more seconds. I got a not responding message for a while. Never got it to expand.

Yup, clicking "he" to get the list of places where that occurs took a really long time, too. About 22 seconds this time. Here's a new log with this experiment done after a cold boot and nothing else running. (Except my Windows Date & Time clock with a second hand and DeskPins to keep it up on top. But it runs slowly even without the clock so it's not a "Heisenbug" [:)] ) It takes 32 seconds to close the BWS window in this test. It appears that absolutely nothing is happening for about the first 29 seconds and then I start to hear hard disk noises.

0677.SlowCloseBWS.zip

DominicM said:

Bradley Grainger said:

it's removing the verses from the display when you close the panel

Am puzzeld by this, why not just destroy/close the panel?? presumably you recreate/redraw it each time its called..

seems a waste of processor time to me

Precisely! Why bother removing the verses one by one? Sure it's a problem that it was slow to put them there in the first place. But this seems like a separate issue to me.

EDIT: However I see that the original poster did mention both issues in the original bug report. Rather than completely remove mine as a "duplicate" perhaps I should link to this thread in that first bug report for further info. The fact that I've posted logs might be helpful in debugging the problem.

What do you think, Bradley?

Bradley Grainger said:

I haven't debugged it, but my guess would be that it's WPF tearing down the visual tree that is taking the time...

That sounds absurd (not your comment, but the underlying design of WPF if that's true about it). I don't know WPF at all, but what kind of display engine needs to create a "tree" of such complexity that it takes on the order of 30 seconds to dismantle it and make it disappear from the screen? I wonder who on the WPF architecture team failed "Algorithms and Data Structures" in college? (Or never took such a class.) Even if it does make sense for WPF to use a tree to store the visual info, trees are relatively simple data constructs. It doesn't take half a minute to free the memory used by them. I'm truly mind-boggled at this inefficency.

You're doing great work, Bradley. Don't worry. I'm not fuming, nor am I directing any of my speechless incredulity at you. Just really mystified, and I sometimes like to use hyperbolic language to express myself. [:)]

I'll go ahead and link that other bug to this thread. Thanks!