It seems both SaveDialog and OpenDialog are taking long time. Moreover, OpenDialog seems faster with higher number of images.There's some lag when the dialog opens before it will let me click on it. And there's some variable delay as I move the mouse and make my selection. The drive is hardware. No anti-virus. In Windows I could tell the PC to not index certain directories and that would greatly speed up the response in directories that contained temporary video frames. Maybe I can do something similar with Manjaro.
Would it be possible to share some hardware specs?
Is this HDD or SSD based folder?
Anti-virus software?
Oh $deity... I'm reminded of some of the filesystem tuning hacks related to turning off atime updates etc.
There is of course an xkcd for this https://xkcd.com/2531/
No, nothing more to do there I am afraid, that shot has already been fired.OK Davo - thanks for the suggestion. It's always great to learn new stuff anyway. The fact that the C++ / wxWidgets file dialog doesn't freeze means that the problem is solvable in software. It's a real corner case (large number of files with new files rapidly flowing in). I'll just accommodate the situation by avoiding the need to enter that directory during downloading.
There are some other FS fine tuning things but none of them are without cost nor really offer a lot of potential benefit.
Sorry !
Davo
I've just taken a quick look back through the thread: I don't think you've answered the question of what widget set the app is compiled against which implies that you've probably not looked at different ones.Going to QT fixed it. I built the libQt5Pas library (libQt5Pas.so -> libQt5Pas.so.1.2.6) in a non-root directory and put the path in the project options. After rebuilding the app and navigating to a directory with 46111 jpegs and two more being added each second the Open File Dialog did not get hung up. It wasn't snappy but that's because there were 46111 files in the directory. Thanks for the tip. Some of the visual stuff looks a little weird - (font sizes, etc) but I'll play around with that :)
If you're using GTK try Qt, and vice versa.
MarkMLl
I am pretty sure you would have found libqt5pas1 and libqt5pas-dev in your distro's repository. But good practice ;-)
I am pretty sure you would have found libqt5pas1 and libqt5pas-dev in your distro's repository. But good practice ;-)Manjaro doesn't seem to have it. The only thing I could find that was close was in this directory:
Davo
Manjaro doesn't seem to have it. The only thing I could find that was close was in this directory:What you have done is fine but if you want to let someone else use your software, you would need to tell them that it depends on libqt5pas, sadly that seems to have a number of different names in different repositories, libqt5pas, libqt5pas1 and surprisingly, at least one repo capitalises the 'P' (from memory). On Manjaro, I think it uses pacman ? You might need to do some sort of wildcard search....
+ <SharedMatrixOptions Count="1">But it didn't show any subtractions, i.e., it didn't show what got replaced by the QT5. So I can't tell you what the default was. Right now the test directory has over 51000 jpegs in it with two new ones streaming in per second, and the gtk3 Open File dialog is working fine.
+ <Item1 ID="829919207870" Modes="Release" Type="IDEMacro" MacroName="LCLWidgetType" Value="qt5"/>
+ </SharedMatrixOptions>
LCLWidgetType:=gtk2and 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.
ldd $(which CppOps) | grep gtkIt looks like its default was GTK3. Thanks everyone for all the help - I've learned a lot :)
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)
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.
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
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$00007F95BAF38BC4
Project CustomOps raised exception class 'External: SIGSEGV'.I get the impression that the bindings for GTK3 have been stagnant for several years. Here is the library on my machine
In file 'gtk3/gtk3wsdialogs.pp' at line 1279:
CreateOpenDialogHistory(OpenDialog, PGtkWidget(FileSelWidget));
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007fb1ec884000)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. :)
libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007fb1ec790000)
...... So for now I'm switching to QT5. :)
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 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.