Recent

Author Topic: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up  (Read 16977 times)

del

  • Sr. Member
  • ****
  • Posts: 258
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #30 on: October 31, 2021, 09:12:12 pm »
Update: I thought I'd try to explicitly specify GTK2 as the widget type
Quote
LCLWidgetType:=gtk2
and the original problem (TOpenDialog - 100% CPU - Fan Revs Up) came back. So it looks like it's a problem in GTK2 somewhere. Which I have no real interest in using. So I'm gonna use GTK3 (libgtk-3.so.0 => /usr/lib/libgtk-3.so.0) for a while (the fonts are bigger than with QT5 - may be a system setting) and see how that goes.
« Last Edit: October 31, 2021, 11:47:46 pm by del »

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #31 on: November 01, 2021, 12:10:14 am »
Great, I will be very interested to see how you go using GTK3.  You were, almost certainly using GTK2 originally, its the Lazarus default on Linux.

If you revert back to qt5, there is a utility, qt5ct, that you can install using your distros package manager that will let you alter a number of display parameters for qt5 apps. Things like colors, fonts, sizes, styles etc.  Pretty useful if you like fiddling to get exactly what you want.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

del

  • Sr. Member
  • ****
  • Posts: 258
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #32 on: November 01, 2021, 02:58:11 am »
Thanks Davo. I've used QT in the past with Python and C++ and I like it. It seemed to work great. There was one weird thing: the TProgressBar seemed backwards. I have a vertical one in my app that's supposed to fill up like a thermometer. It was upside down, like gravity was up. So as it showed "progress" the bar descended from its origin at the top. But I can deal with stuff like that.

I was curious about the C++ / wxWidgets app (very similar functions) that I built last week to test / compare. It behaved normally as I described in a previous post:
Quote
ldd $(which CppOps) | grep gtk
   libwx_gtk3u_xrc-3.1.so.5 => /notroot/WXWIDGETS/build/lib/libwx_gtk3u_xrc-3.1.so.5 (0x00007fd3a9570000)
   libwx_gtk3u_html-3.1.so.5 => /notroot/WXWIDGETS/build/lib/libwx_gtk3u_html-3.1.so.5 (0x00007fd3a9496000)
   libwx_gtk3u_qa-3.1.so.5 => /notroot/WXWIDGETS/build/lib/libwx_gtk3u_qa-3.1.so.5 (0x00007fd3a9466000)
   libwx_gtk3u_core-3.1.so.5 => /notroot/WXWIDGETS/build/lib/libwx_gtk3u_core-3.1.so.5 (0x00007fd3a8c05000)
   libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007fd3a2d4e000)
It looks like its default was GTK3. Thanks everyone for all the help - I've learned a lot  :)

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #33 on: November 01, 2021, 05:38:48 am »
There was one weird thing: the TProgressBar seemed backwards. I have a vertical one in my app that's supposed to fill up like a thermometer. It was upside down, like gravity was up. So as it showed "progress" the bar descended from its origin at the top.

I probably live on the opposite side of the world than you, so we are used to things being upside down.


Seriously, if you can replicate that issue in a very small app, I'd log it as a bug, zeljko, who looks after Qt5 is very helpful.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

del

  • Sr. Member
  • ****
  • Posts: 258
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #34 on: November 05, 2021, 05:27:24 am »
Great, I will be very interested to see how you go using GTK3.
I'm glad you asked. Not so good. GTK3 fixes the original problem. But I can't use TSaveDialog because it segfaults on create

Quote
[FORMS.PP] ExceptionOccurred
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00007F95BAF38BC4

That's with release build run from the command line. If I run it from Lazarus in the debug mode I get this:
Quote
Project CustomOps raised exception class 'External: SIGSEGV'.

 In file 'gtk3/gtk3wsdialogs.pp' at line 1279:
CreateOpenDialogHistory(OpenDialog, PGtkWidget(FileSelWidget));
I get the impression that the bindings for GTK3 have been stagnant for several years. Here is the library on my machine
Quote
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007fb1ec884000)
libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007fb1ec790000)
Maybe the bindings are mature and GTK3 is stable and this is just an easy bug. Or it may be the first worm in a can of worms. So for now I'm switching to QT5. :)

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #35 on: November 05, 2021, 05:55:11 am »
...... So for now I'm switching to QT5. :)

Good move.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: [SOLVED] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #36 on: November 05, 2021, 09:56:00 am »
Maybe the bindings are mature and GTK3 is stable and this is just an easy bug. Or it may be the first worm in a can of worms. So for now I'm switching to QT5. :)

I didn't want to comment on this aspect lest it looked like a complaint.

By and large, distreaux are trying to move away from gtk2 onto gtk3.

Lazarus/LCL is still slightly... immature as far as gtk3 is concerned. I don't know why, but in the past the Gnome (etc.) developers have been criticised for gratuitously breaking the compatibility of their APIs and if this is still an issue it is tempting to assume that it makes life extremely difficult for large-scale projects such as the LCL components.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

del

  • Sr. Member
  • ****
  • Posts: 258
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #37 on: June 02, 2022, 10:11:41 pm »
UPDATE - I've been using wxWidgets / GTK-3 recently and I thought the problem was behind me. But it's reappeared and it may have have shed some light on the mystery. The fix in wxWidgets / C++ was to "scope" the life of the dialog so that it gets destroyed as soon as possible:

Code: C  [Select][+][-]
  1.   MFileName firstFrame;
  2.   wxString fileTypes = "frames (*.bmp);(*.jpg);(*.png)|*.bmp;*.jpg;*.png";
  3.  
  4.   { // Scoped to shut down dialog background activity
  5.     wxFileDialog frameDlg(NULL, _("First Frame"), lastDir, lastFile, fileTypes,
  6.       wxFD_OPEN | wxFD_FILE_MUST_EXIST);
  7.  
  8.     if (frameDlg.ShowModal() == wxID_CANCEL)
  9.     {
  10.       return;
  11.     }
  12.  
  13.     lastDir = frameDlg.GetDirectory().ToStdString();
  14.     params.SetVal("lastDir", lastDir);
  15.     params.SetVal("lastFile", frameDlg.GetFilename().ToStdString());
  16.     params.SaveToFile();
  17.  
  18.     firstFrame.ReUse(frameDlg.GetPath().ToStdString());
  19.   } // End of scope
  20.  

What I think is happening is that the Dialog is engaging the API in a way that triggers a lot of background "file manager" housekeeping. By scoping the life of the dialog (between the two curly braces) the dialog dies as soon as it leaves scope and all the busy housekeeping never gets a chance to take over the machine. This is a real problem when the dialog interacts with directories containing hundreds of thousands of video frame images. Otherwise the dialog behavior seems normal. So I could probably fix my problem in FPC if I could figure out how to scope the dialogs (or at least cleanly kill them quickly).

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #38 on: June 24, 2022, 02:25:57 pm »
Depending on the display format selected, the OpenDialog has to show the file format as an icon or thumbnail. So it reads all the files to record the format and create that thumbnail. The same happens if you have many networked or spun down drives (or even worse: OneDrive): it has to build a tree with all of those. And accessing them is slow. Like, if you drag files to a drive that has to spin up and/or contains many files in Windows Explorer: everything freezes for seconds or minutes.

So if you have 10.000+ media files or directories, it can take minutes to show the dialog.

To fix that, the simplest way is make your own dialog: a form with a list of just the file names and a button to go one directory up. Double-click the row to select.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #39 on: June 24, 2022, 02:37:06 pm »
/Why/ does the OS/GUI/widgetset have to read them? Most have an association between the last portion of the filename ("extension" on Windows) and a MIME type, and the MIME type has a preferred icon for each display resolution.

There's no need for the basic OS (etc.) to open the file, and even less need for it to read any more than the first block which contains one or more "magic numbers" or other identifiable information.

If a malware scanner wants to go into more detail that's a separate issue, but even then I'd hope it cached stuff.

Historically, the thing that's given me the most problem was when a directory (or directory-like list) was scanned, but the (identifiers of the) content were too similar resulting in a runtime O(n^2) or worse due to a grossly unbalanced tree.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #40 on: June 24, 2022, 02:49:55 pm »
It depends on the format. If it is a recognized format, there's a list somewhere if there's a function to make a thumbnail, and if there is, that is called. For an image that means: read and scale. For a video: find a full image some time after the start, read and scale that. For a document: render the first page and scale. Etc.

You can fix that by never allowing thumbnails, but it depends on the OS and GUI used how easy that is to configure. And that's for the user to decide, not the application.

I'm not sure if there's a setting not to populate the directory view completely up front. At least on Linux, they're only mounted when needed.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #41 on: June 24, 2022, 03:05:11 pm »
I was of course forgetting content-derived icons... greeked thumbnails would be a better description. Didn't have those when I were a lad :-)

But even so: /surely/ there's some level of caching? Or is the dialog(u)e doing something to flush that?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #42 on: June 24, 2022, 03:25:21 pm »
I assume there is some caching, but that is OS and GUI dependent. And often the TOpenDialog is just a wrapper around the OS/GUI one. There's also a difference between local drives and network drives.

Anyway, the only real way to circumvent it is DIY and use a list of file and folder names.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: [UPDATE] TOpenDialog - 100% CPU - Fan Revs Up
« Reply #43 on: June 24, 2022, 04:03:55 pm »
I assume there is some caching, but that is OS and GUI dependent. And often the TOpenDialog is just a wrapper around the OS/GUI one. There's also a difference between local drives and network drives.

Anyway, the only real way to circumvent it is DIY and use a list of file and folder names.

I think we might need to be cautious here about what exactly we mean by "GUI". If we mean "desktop environment" with a "file manager" etc. being an integral part of that, then it would be reasonable to expect caching since there it is a long-lived subsystem with its own processes etc.

If OTOH we mean "widget set" then my understanding is that this is basically a shim layer between (e.g.) the LCL and a set of libraries, and unless the (process associated with the app) caches stuff there's basically no long-lived element to do so.

Which broadly agrees with your DIY conclusion, unless there is an accessible API provided by the desktop environment which allows access to stuff it's got in its memory space. After all, even opening ~10,000 prebuilt icons on disc will take a while...

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018