Forum > LCL

[UPDATE] TOpenDialog - 100% CPU - Fan Revs Up

<< < (8/9) > >>

dbannon:

--- Quote from: del on November 05, 2021, 05:27:24 am ---...... So for now I'm switching to QT5. :)

--- End quote ---

Good move.

Davo

MarkMLl:

--- Quote from: del on November 05, 2021, 05:27:24 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. :)

--- End quote ---

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

del:
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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---  MFileName firstFrame;  wxString fileTypes = "frames (*.bmp);(*.jpg);(*.png)|*.bmp;*.jpg;*.png";   { // Scoped to shut down dialog background activity    wxFileDialog frameDlg(NULL, _("First Frame"), lastDir, lastFile, fileTypes,      wxFD_OPEN | wxFD_FILE_MUST_EXIST);     if (frameDlg.ShowModal() == wxID_CANCEL)    {      return;    }     lastDir = frameDlg.GetDirectory().ToStdString();    params.SetVal("lastDir", lastDir);    params.SetVal("lastFile", frameDlg.GetFilename().ToStdString());    params.SaveToFile();     firstFrame.ReUse(frameDlg.GetPath().ToStdString());  } // End of scope 
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:
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:
/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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version