Pattern requester

[jens-maus]

Michael created the issue:

Pattern requester list .info files as separate objects
IMHO it should not do so.

[jens-maus]

Michael uploaded file mui39b-pattern-req.png (183.5 KiB):

[jens-maus]

Michael commented:

[[Image(mui39b-pattern-req.png)]]

also missing translation for KB, MB

[jens-maus]

Michael commented:

One more thing, when you disable image preview, it still loads it internally.
Maybe it's a good idea to disable image loading when they are not shown ?
Will give a massive speed boost for browsing large directories and saves a lot of ram too.
PS: I don't know how the memory is handled, but on a real miggy, freeing resources from an image drawer with say 50 images, takes a long time with 100% cpu load.

[jens-maus]

@tboeckel changed status from new to closed

[jens-maus]

@tboeckel changed component from undefined to Dirlist.mui

[jens-maus]

@tboeckel changed priority from undecided to normal

[jens-maus]

@tboeckel changed resolution from ** to duplicate

[jens-maus]

@tboeckel commented:

You are mixing up three different issues here again. Stop that!

The reasons why icons are shown as separate objects has been answered in #45 already. So please refer to my latest answer there.

The missing translations are covered by #79. No need to repeat this here again.

Thumbnails will always be generated, no matter if they are shown or not. Dirlist.mui keeps a separate setting for each directory about how the contents will be displayed. MUI 3.9 is definitely not targeted at low end systems like real classic machines. We stated this more than once by now. There is no point in trying to push these systems any further.

In fact Dirlist.mui will compress the thumbnail images using bzip2.library to save as much memory as needed when the images are no longer in use. Of course this takes its time and this is what you see as 100% CPU load. However, deleting bzip2.library is not recommended, because lots of other stuff in MUI depends on it.

[jens-maus]

Michael commented:

"You fail to provide the necessary information again. Of course icons can be rejected if that is requested by the application. So which application are you referring to? If you are referring to the image browser then the display of icons is perfectly valid, because icons are images, if you like it or not."

I see, someone uses icons for backgrounds in MUI prefs ?

As for the speed.... Loading speed is actually ok, what bothers me is when resources are freed, it takes almost as long as loading them!
Maybe the debugging tools are really slowing it down, but I have never experienced such slowdowns on simple mem free operations. (eg. change dir, or even close the requester)

[jens-maus]

@tboeckel commented:

Replying to [comment:4 Michael]:

I see, someone uses icons for backgrounds in MUI prefs ?

I do not care if someone does or does not. Icons are images and as such they will be displayed like any other image file. Like it or not.

As for the speed.... Loading speed is actually ok, what bothers me is when resources are freed, it takes almost as long as loading them!
Maybe the debugging tools are really slowing it down, but I have never experienced such slowdowns on simple mem free operations. (eg. change dir, or even close the requester)

This has nothing to do with debugging tools. You obviously did not read my previous answer.

[jens-maus]

Michael commented:

"In fact Dirlist.mui will compress the thumbnail images using bzip2.library to save as much memory as needed when the images are no longer in use. "

Hmm... What's the point of storing the images in ram if we do not use them ?
Especially if we are leaving a directory or closing the requester. What are our chances of needing the images soon ?
Is not it easier to reload them when needed?

[jens-maus]

@tboeckel commented:

Replying to [comment:6 Michael]:

Hmm... What's the point of storing the images in ram if we do not use them ?
Especially if we are leaving a directory or closing the requester. What are our chances of needing the images soon ?

The reason is simple: speed. The images are cached to reload them faster when they are needed again. All the cached images will be freed as soon as no instance of Dirlist.mui is alive and if there is a low memory situation. That is early enough.

Is not it easier to reload them when needed?

Some days ago you were complaining about too slow image loading. Now you are complaining about too much memory consumption. Do you really know what you want? Speed always comes for a price, and usually that is a certain amount of additional memory. What's the worth of free memory if it could be better used to cache things to access them faster next time?

Honestly, you really should decide what you want. Either a MUI version for absolute low end systems or a MUI version for high end systems. A single version for everything is not going to happen. Nor the first version. MUI 3.9 and MUI4 are targeted at high end systems. If you cannot accept this fact then stick with MUI 3.8.

[jens-maus]

Michael commented:

I have not complained much on loading speed or memory usage in this case.
But the problem is when you switch directories there is heavy cpu load and nothing happens for a while and there was no reason for that. Now I know why, you are saving and crunching the cache. But in practice it is not gaining any speed, but making things slower. It would benefit in case we had a large folder of full screen images in jpg maybe, then again it might be just fine to reload them when needed since you are unlikely to jump from one dir to another and back full of such images. It's better to have a responsive system, and the nice features can crawl if they are required, I would prefer to wait for the dir lister to render when I need to see images, but waiting while something is happening in the background and being out of control is not nice. Do a few clicks and we get the famous windows lag response when things start to happen seconds later without your control.

I never said absolutely low end systems, yes it should work there too if possible, but we are talking about reasonable configs where it should perform with acceptable performance, and if it requires to disable some fancy stuff, the user should have a choice. (eg. in games you might have an extreme quality setting that looks nice, but there is usually no hardware to play it when the game is released, so you have a choice of performance v features but playable game, not a slide show)

Actually wondering... Where is the fancy font requester ?

As always, life is full of compromises. And things can be made adaptive to the environment they work in if there is an option or good will. I know you are hard to persuade and you do your best with your own vision of things.

[jens-maus]

@tboeckel commented:

Replying to [comment:8 Michael]:

Actually wondering... Where is the fancy font requester ?

That is part of MUI4, not of MUI 3.9.

As always, life is full of compromises. And things can be made adaptive to the environment they work in if there is an option or good will. I know you are hard to persuade and you do your best with your own vision of things.

There is ticket #60 for this purpose. Add your wishes there instead of turning every bug report into a fruitless and endless discussion.