bugGNU Octave - Bugs: bug #55816, Laggy file browser

 
 

bug #55816: Laggy file browser

Submitter:  None
Submitted:  Sun 03 Mar 2019 02:59:22 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Need Info Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 5.1.0
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 15 Jan 2022 11:36:36 PM UTC, comment #15: 

Selecting the "windows" style solved my sluggish file browser problem :-)

Anonymous
Sat 18 Apr 2020 07:22:09 AM UTC, comment #14: 

I think this really might depend on the selected style, which was introduced in version 5 (if I remember correctly). Could you please test selecting the style "windows" instead of "default" or "windowsvista"?

Torsten Lilge <ttl>
Group Member
Fri 17 Apr 2020 10:22:09 PM UTC, comment #13: 

I installed 5.2 this morning and am still seeing this issue.  No issue with 4.4.1.

comment #7:

> I've been using Windows Octave for the past several months, I think it is 5.1.  I haven't noticed the major delays like described in previous posts, but generally it is kind of laggy compared to linux.  Typing at the command line seems responsive, editor seems fine too.  Running a command, though, has a delay of about two seconds, as if the interpreter is taking much too long.  Stepping through debugging is slow. File I/O seems slower than it should be, too.
>
> On the other hand, much of this might just be the nature of Windows.  It's really difficult to know what is happening, given so many threads associated with the OS.  The original post mentions 3.25 GB, which isn't a lot for all the applications running that one can't seem to control.  Windows does a lot of swapping to disk, I believe.
>
> I will try 5.2.0 when I get a chance next week.
>
> If there is a tooltip issue, and someone looks into it, if there is one feature above all that I'd like in the debugger it is the ability to position the cursor over a variable and have its value automatically appear in the tooltip.

Anonymous
Sat 11 Apr 2020 10:59:31 AM UTC, comment #12: 

FWIW, I recognize the "very wide Name column" in the file browser from many months ago, but not slowness. (FYI I only run development Octave versions and I make & install Windows crossbuilds on average about twice a week.) At that time I was just pondering about entering a bug report when in a next build the file browser behavior came back to "normal".
I speculated that the file browser issue was related to a mix-up of qtsettings files that maybe have backwards incompatible sections (= problem is on my side) so I didn't bother. The more so since I'm comfortable with the fact that living on the bleeding edge has some consequences.

@Dan (1):
+1 for the tooltip suggestion in comment #7. Is there a feature request for it? (I think I saw some time ago.) As a workaround I use the Variable Editor a lot for on the fly tracking of variable values.

@Dan (2):
At work I'm "convicted" to Windows so I use that mostly. On those heavily managed systems I often see delays, esp. as file operations are invoked, sometimes indeed several seconds. That seems equally valid for many other SW incl. Matlab. Yet at home on my own HW I see little or no "snappyness" differences between Linux and Windows on the same multiboot boxes, and on both OSes Octave and Matlab are fast and responsive.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 11 Apr 2020 09:51:20 AM UTC, comment #11: 

It seems that the "windowsvista" style depends on the system wide design. With the "Classic" design, the "windowsvista" style is the same as the "windows" style. Only when selecting "Aero" or whatever is the modern system design, "windowsvista" sort of dapts to this style and shows triangles instead of plis/minus signs in the tree view.

However, in both cases the file browser is responsive as expected.

What system design have you selected? Does this selection have an influence on the issue you are seeing in the file browser?

Torsten Lilge <ttl>
Group Member
Sat 11 Apr 2020 06:16:18 AM UTC, comment #10: 

It sounds like some kind of infinite loop developing in which a redraw causes a resize, which causes a redraw, which causes a resize.  Maybe eventually some sort of stack is overflowing.  Debugger gdb might be of use.  I've used it before, but not much.  I think it is pretty easy to build a debugger version, run it and watch for issues dumped when you have the Name column too wide at the start.  It might also be a good idea to check the Qt bug tracker site for any reported issues with the vertical and horizontal scroll bars.

Dan Sebald <sebald>
Fri 10 Apr 2020 10:19:27 PM UTC, comment #9: 

Octave 4.1 seems to use the style "windows" with "+" and "-" signs for expanding/collapsing folders, this style did not lag on any of the computers

SillyMon <sillymon>
Fri 10 Apr 2020 10:14:10 PM UTC, comment #8: 

Original submitter here.
I can now give a more concrete description of the problem.

In Octave Preferences, General tab, interface settings, there is a style option visible only in 5.1 and 5.2. I have not found/managed to make this choice/setting visible in 4.1
On 3 of my computers the default style used by Octave 5.1 and 5.2 is "windowsvista" and with only this style is the lag present, but only in two computers.
Hovering the mouse or navigating with keyboard arrows between file or folder will cause lag/page faults/high cpu usage, close to a full core.
The "delta page fault" is around 140 000 +- tens of thousands for mouse hovering and around 60 000 for a single arrow key press, other actions dose not cause any page faults. "Process Explorer" has named it "delta page fault", i assume it to be "page fault"/"second"
From "Resourcemonitor", the Octave gui process did not create any "hard faults"/"second". I therefor assume the page faults are soft.

Another way to fix the page faults and lag in the file browser is to reduce the row length/length of the "Name" column, the only column. On my two computers with the lag problem this column is unreasonably long by default. In other words there is room for loots of horizontal scrolling. Going to the end of the "Name" field and double clicking the edge to auto scale(reduce horizontal scroll length, only way to do it, simply moving it dose nothing) fixes the problem completely in both versions of octave even if the change is done in only one.

Expanding a column to create a unreasonably large horizontal axis again dose not reintroduce the lag.

On my third computer that did not have any version of Octave installed before 5.2, never had any lag in the file browser and the horizontal scroll bar is not there. The column "Name" field is not large enough to create a scroll bar.

The resolution on the third computer is 1366x768, the two other lagy computers, 1680x1050 and 2160x1440, if that is relevant. Interacting with the gui on the third 1366x768 non lagy computer generally feels smother

On a unrelated note, changing the size of any Octave window causes a "delta page fault"(soft i assume) between 10 000 and 30 000 on all the computers. Changing the octave "Command Window" to fast, to soon after start up, or making this window to large, or maybe it is just randomly on resizing of the Command Window, crashes octave on one of the computers. I have not managed to crash octave on the other two Intel 64bit computers with any kind of windows resizing. 32bit octave on all the computers.

SillyMon <sillymon>
Sat 15 Feb 2020 10:20:09 PM UTC, comment #7: 

I've been using Windows Octave for the past several months, I think it is 5.1.  I haven't noticed the major delays like described in previous posts, but generally it is kind of laggy compared to linux.  Typing at the command line seems responsive, editor seems fine too.  Running a command, though, has a delay of about two seconds, as if the interpreter is taking much too long.  Stepping through debugging is slow. File I/O seems slower than it should be, too.

On the other hand, much of this might just be the nature of Windows.  It's really difficult to know what is happening, given so many threads associated with the OS.  The original post mentions 3.25 GB, which isn't a lot for all the applications running that one can't seem to control.  Windows does a lot of swapping to disk, I believe.

I will try 5.2.0 when I get a chance next week.

If there is a tooltip issue, and someone looks into it, if there is one feature above all that I'd like in the debugger it is the ability to position the cursor over a variable and have its value automatically appear in the tooltip.

Dan Sebald <sebald>
Sat 15 Feb 2020 09:44:22 PM UTC, comment #6: 

No answer for more than half a year. Is this issue still present in the new version 5.2.0?

Torsten Lilge <ttl>
Group Member
Mon 29 Jul 2019 06:52:08 PM UTC, comment #5: 

Which tooltip are you referring to?  The tooltip "Double-click to open file/folder, ..."?

Regarding comment #2, is it possible to post a screenshot from the "pale blue marker"?

Torsten Lilge <ttl>
Group Member
Mon 29 Jul 2019 03:19:16 PM UTC, comment #4: 

I can confirm this issues in comment #2. My impression is that the influence comes from tooltips. I compaired it with 4.2.1. There is neither tooltip nor some highlighting the current row under the cursor. I hope this hint can help. Best Regards

Anonymous
Mon 04 Mar 2019 12:03:17 AM UTC, comment #3: 

my previous description of the lag using a mouse indicated that the lag increased with time. I now notice that colapse/expansion of a folder is very slow the first couple of clicks but improves for each click. But never gets as good as 4.4.1. the arrow symbol next to the folder is inconsistently delayed 0-2 seconds. I can not find a pattern at least.

Also scrolling the File Browser window with the scroll wheel or arrow keys lags with around 1-2 sec. Scrolling by holding the window navigation bar thing and draging with the mouse is smothe with short 0.5 second freezes every 2-4 sec maybe

Anonymous
Sun 03 Mar 2019 11:44:41 PM UTC, comment #2: 

Sorry, true.
Key board arrow presses to navigate the marker of files and folders and expanding collapsing folders has around 1-2 sec delay this is consistent. With keyboard, the arrow symbols ">" and "^(downward version)" next to the folder being collapsed or expanded changes simultaneously with showing/hiding content of the folder.

Using a mouse the delay/lag changes with time, having tried a couple of times expanding/collapsing a folder seems much more responsive right after starting octave but degrades to a 1-2 seconds delay after leaving the computer for 10 min(it may take much less than 10 min). This is also true for the the blue marker showing that a file or folder has been marked after a mouse click. The arrow symbol next to the folder is also responsive the first time navigation is done in the file browser. The symbol changes when the expansion/colapse animation is finished, but it degrades to the same 1-2 second lag with time. The pale blue marker showing which folder/file the mouse arrow is above has a consistent 1-2 second delay.

The expanded/collapsed symbol on 4.4.1 is a -/+ symbol in a box and there is no pale blue marker showing which folder the mouse arrow is hovering above. navigating folders with keyboard presses or a mouse is smooth. No lag that i care about or can describe accurately without checking frames of a recording.

Opening a file in 5.1.0 may be slightly slower than 4.4.1 barely noticeable, less than 0.5 sec.

Expanding the folder path drop down history of previously accessed folders is also delayed by around a second on 5.1.0, collapsing is instant. no issue on 4.4.1

Additionally i have noticed a aproximately 5*3 cm black box sometimes appearing for 1 sec below, to the right and after a mouse click to mark a file or folder. The box has appeared both after and before the blue marking showing that the file or folder is marked.

Anonymous
Sun 03 Mar 2019 08:51:48 AM UTC, comment #1: 

What does "file browser lags, is excruciatingly slow" mean?  That the response to keyboard presses is slow?  That there is, say, a ten second delay for the first file window to open (sounds like a Windows font bug that has been around a while)?  Use seconds units to describe what is happening in detail.

Dan Sebald <sebald>
Sun 03 Mar 2019 02:59:22 AM UTC, original submission:  

32bit x64 Intel quad Q6600 4GB(3.25 usable) ram
windows 10 pro version 1803

first time install bug #55688 happend: avast detected gpg-agent.exe as a virus.

updated avast.
uninstalled Octave 5.1.0.0. Removed everything, verified folder "Octave-5.1.0.0" was removed. Restarted computer. Installed octave without issues. Started 5.1.0.0 and the file browser lags, is excruciatingly slow.
Octave 4.4.1 is also on the computer and works without file browser lag

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sillymon (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code