Lister flickering

[majkinetor !]

Lister flickering in quick view is really annoying and because of that I almost never use it. No matter the type of the file, or lister plugin, you allways see lister reloading when you move through files with cursor.

Can this be fixed ? I already reported that Lister Plugin API should contain function Refresh() that will inform the caller that lister should load a new file and live screen cleaning and refreshing to the plugin.

I created an video screenshot how that looks like on my system (2 x 3 GHz CPU, 1Gb RAM)

[ghisler(Author)]

Unfortunately that's how plugins work when you switch to the next file: The plugin of the previous image is closed, then the plugin for the next file is loaded and the file is passed to it. This is necessary so multiple plugins can be used...

[majkinetor !]

I know.
You need to redesign this. Its unusable like this.

You need to close current plugin only if next plugin is different ! If it is the same, you don't need to close the current plugin, but to inform it about he new file.

[Alextp]

Good idea, support...
But I doubt, if Ghisler will find time for this and plugin authors will implement this.

[Lefteous]

This is really a good idea. TC would have to pass the matching existing window instead of the parent window in a new function. Reusing an existing window not just avoids flickering it also saves time for destroying and recreating the window.

[Alextp]

But we have this problem:

checking plugin for match for some filetype includes opening this plugin (yes, DetectString exists, but this is when it's empty). So, for example, if plugin ListDoc.wlx is open and we check all plugins for *.doc match, Office.wlx may match and open. If ListDoc will not be closed before cheching match, Office.wlx will open *above* opened ListDoc -> there will be 2 plugins opened at the same time. This also may lead to flickering when first plugin closes.

2Ghisler: is this right?

[majkinetor !]

But I doubt, if Ghisler will find time for this and plugin authors will implement this.

They will acctually have to add just several lines of code, since they already have routines for loading/unloading their stuf.

So, for example, if plugin ListDoc.wlx is open and we check all plugins for *.doc match, Office.wlx may match and open. I

I don't think so. This is, for 1, imposible in QuickView, since the first plugin on the list will open the file, you can not change it if several plugins handle it.

For non Quick View mode, this will applay to N & P keys (this flickers now, but if QV is solved, this will be too)

Ghisler, do you want us to desing the API update and test it in Viewer.exe that Alex developed ? If it is sucessiful, can we expect you to add it in TC and announce it as official ? You will hardly have any work here, as we will do everything, you wold just have to update SDK documentation and add several function calls here and there...

2 Alex
Scenario (User has 1st Office and 2nd ListDoc)

1. Open doc in Lister (Office grab the file)
2. User press 4 to swith to next plugin (ListDoc)
3. User press N

What will happen here:
TC will know that current plugin is used for doc files. It will not check plugins again to find that Office is first on the list, but it will just call letsay Next() function in ListDoc itself.

If file requires another type of plugin, then the previous should be closed.

So, I don't see any problems here. Just massive speed improvement, and finally ability to use QV while quickly moving through selected files.

[Alextp]

I suggest function ListReload, that can pass filename to already opened plugin window.
When TC moves to another file in QV mode:

- it tries to pass new filename to already opened plugin (ListReload)
- if failed, then as now: it tries all plugins from first

When not in QV mode, ListReload is not used.

What do you think?

Edit: better name is ListOpen.

[majkinetor !]

When not in QV mode, ListReload is not used

It can be used for N and P also. This is basicly the same as using QV, but you can use Full Screen and move window around.

I am happy with QV alone, since this will be major benefit. Quck View, like its name suggest, must be quick to open, quick to display and generaly quick.

One other thing: how plugins know they are displayed in Quick View ? I expected that to be among showFlags but there is nothing indicating that. If this flag doesn't exist it should be implmented also, so plugins know they are in QV so to avoid some special interface options and so. How plugins handle QV mode now ?

But I doubt authors will implement this.

I don't think so. If you write and improve your plugin for years, why would you ignore such functionality, which lays at your dorstep. This will require minimal amount of work to be set with currently developed plugins.

[Alextp]

how plugins know they are displayed in Quick View ? I expected that to be among showFlags but there is nothing indicating that. If this flag doesn't exist it should be implmented also

Agree.
Now they are checking for parent window class name.

[XPEHOPE3KA]

2majkinetor !

I don't think so. If you write and improve your plugin for years, why would you ignore such functionality, which lays at your dorstep. This will require minimal amount of work to be set with currently developed plugins.

You know such plugin authors? Most of them USED TO improve their plugins for some months. Then they run out of free time. I hardly doubt that anyone will improve his plugin just to avoid flickering.

[ghisler(Author)]

You know such plugin authors? Most of them USED TO improve their plugins for some months. Then they run out of free time. I hardly doubt that anyone will improve his plugin just to avoid flickering.

That's also my concern: There are dozens of lister plugins out there which haven't been changed for years because they just do what they should do. I doubt that anyone would rewrite such an old plugin just to avoid flickering. So what could we do? Make a screen capture of lister and display it as a bitmap which is then hidden after the next plugin has loaded? Or try to load 2 plugins at the same time, and risk that they influence each other? Any suggestions?

[XPEHOPE3KA]

2ghisler(Author)
The suggestion is to implement something like Alextp stated here so that NEW lister plugins CAN support loading new files without unloading them, while OLD lister plugins would behave like they do now.

[majkinetor !]

There are dozens of lister plugins out there which haven't been changed for years because they just do what they should do

And there are dozens of lister plugins out ther which are updated regulary, for years. This conversation is: glass is half empty/ glass is half full

I doubt that anyone would rewrite such an old plugin just to avoid flickering

Ok, old plugins will flicker, new plugins wont. And that is not just flickering. I never use QV just becuase of flickering. Next, obviosly WLX plugins can be run as standalone via Alex work, witch is excellent news, since now you have bunch of very small applications you get used to already, and you alwasy wanted to have standalone: font, image, icon, registry viewers.. just name it. So this system must avoid reloading the pluigin on every file for the performance and display reasons.

Take a screen capture of lister and display it as a bitmap which is then hidden after the next plugin has loaded?

This would eliminate flickering, but performance would be the same - slow. So this is not real progress.

Or try to load 2 plugins at the same time, and risk that they influence each other?

Maybe load 2nd, and close 1st after 2nd did the display.


Anyway, people who would like to avoid flicker in their own plugins have no oportunity now. QV would be whole another application with this. You could use it for fast preview on anything while moving through selected files, you would be even able to press up/down and hold and to see everything nicely, for short time. Now you can't do that. U can move, then wait a sec, then move, then wait a sec and so on... if you hold up/down TC will not display anything until you stop. In Alex's viewer + my QV script you can hold the keys and every file will be displayed witch is good, but flicker is still there.

I am sure that if this thing is implemented, you will all wonder how you could live without it.

[majkinetor !]

Here is the video screenshot of difference between Alex Viewer + QV script and internal QuickView.

First I start internal QV. I move slowely through files and you can see that when speed is very slow, images are shown nice. As I am increasing the speed you see flicker more and more until there is nothing except flicker. At the final speed, while holding the key, the QV doesn't display anything until I stop.

Then I start QV script. I am moving fast through files and every image is shown with less flickering then in internal QV. This doesn't make sense to me, since in later scenario we have 2 applications working together so internal lister must be much faster. At the end I hold up arrow and you can still see every image. Flicker is anoying but 10x less anoying then in internal QV + you can see everything.


Here is the link: http://rapidshare.de/files/25432719/1.sqx.html


NOTE: Recording video screenshots massively slows down computer. You should try this yourself to see the differences. These are the Viewer & the Script I used to create this (script is there also in exe version for those that doesn't have AHK installed:

http://rapidshare.de/files/25433492/Viewer_Script.rar.html

2Alex I fixed right trailing space.