BUG: When NA28 active, resource tabs shift position / "flash" and spike CPU

I'm trying to capture this with screenshots. One will show NA28 active with the tabs in one position (so to speak), the second with NA28 with the tabs shifted slightly because an icon shows up on the NASB 95 tab.You can see that some of the other tabs also look different in the second position/view.

This happens every time I make the NA28 active. It just keeps shifting back and forth between the two "positions", and the CPU spikes to 20+%.

I just updated to 25.1.53, and it's still happening.

Thanks.

Find more posts tagged with

Desktop App

Comments

MJ. Smith

Have you tried changing the width of the panel? This normally is the result of having exactly the wrong total width of tabs for the panel. Think of it as a routine that requires the total tab width to be < or > but stumbles on =. It can be fixed by (a) deleting a tab (b) adding another tab (c) making the panel wider or (d) making the panel narrower. If none of these solve the problem you have found a new bug.

Donnie Hale

https://community.logos.com/discussion/comment/1258119#Comment_1258119

My window is maximized. I have two main vertical panels that take up the majority of the window (with the new vertical menus taking up the remainder of the space on the left).

If I try to widen the panel in question (which of course will shrink the adjacent main panel):

1. I don't get any feedback that it's accepting the widening while I'm still dragging. The mouse cursor with the alternate icon moves, but the bar separating the panels doesn't move, nor does the panel appear to be getting wider.

2. I have to move the cursor *a lot* before it will accept the widening - it seems like possibly the width of a tab, so something like 100px.

3. When it allows that widening, the behavior starts when I have the ESV tab active. It then becomes somewhat difficult to shrink the panel to its previous width.

Maybe this is a new bug, maybe not. But even if it's not new, it's a really bad behavior - both visually and with the CPU spike. So just "stumbles on =" is no excuse not to fix it.

I should probably add that I've never encountered this before. And I've used this same main window layout for years - 95+% of my time in Logos is with this main window layout. I first encountered it probably a month ago after an update I applied.

I appreciate the reply,

Donnie

MJ. Smith

https://community.logos.com/discussion/comment/1258145#Comment_1258145

It sounds like the long standing problem (which is not as easy to solve as I made it sound). I would suggest calling and letting the techs watch the problem in action.

Dave Hooton

https://community.logos.com/discussion/comment/1258145#Comment_1258145

My window is maximized. I have two main vertical panels that take up the majority of the window (with the new vertical menus taking up the remainder of the space on the left).

Have you tried alternating the width of the vertical toolbar.

If I try to widen the panel in question (which of course will shrink the adjacent main panel):
1. I don't get any feedback that it's accepting the widening while I'm still dragging. The mouse cursor with the alternate icon moves, but the bar separating the panels doesn't move, nor does the panel appear to be getting wider.

That is frustrating. I have a third, narrow vertical tile which is created when opening tools like Highlighting, Info, Favorites. It much more sensitive to width changes and a move back and forth will fix the problem when it occurs.

Andrew Batishko

As mentioned, this is, unfortunately, a known, long standing problem.

Contributing factors include:

The exact width of the space available for the visible tabs
The number of tabs
The tab titles (usually book title in this case)
The abbreviated form of the tab titles (usually book abbreviation in this case)
Any link set or target options set on each tab
The width of the icon on each tabs (some books have different shaped covers)
The order of the tabs

Workarounds include making changes to the factors above, many of which are under your control.

Donnie Hale

https://community.logos.com/discussion/comment/1258155#Comment_1258155

Thanks for the reply, Andrew. Very kind of you.

Given that you suggest workarounds, it sounds like something you either can't or won't fix.

Is the underlying issue something internal to WPF or something like that, where it's out of your control?

Just curious. Thanks,

Donnie

Andrew Batishko

https://community.logos.com/discussion/comment/1258217#Comment_1258217

It's not beyond our control, but it is something that has had at least 3 or 4 fixes over the years, and stubbornly continues to cause problems. It's related to rounding errors. It has just never been a high enough priority for it to be selected for work.

The most likely solution will likely come with a complete overhaul of the panel tab bar, since there is a fairly high desire to replace it with a better design. I have no guesses as to when such work might be done.

Donnie Hale

https://community.logos.com/discussion/comment/1258223#Comment_1258223

[Y]