Forum > LCL

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

<< < (9/9)

SymbolicFrank:
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:
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

SymbolicFrank:
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:

--- Quote from: SymbolicFrank 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.

--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page

Go to full version