Directory Opus extremely slow on gif and archive

Help & Support
1

on windows 8, loading .gifs in a folder takes 1 seconds for each .gif to show up.

loading archive files like .zip .rar and especially .7z takes even longer. .zip and rar takes around 2-3 seconds for each .gif to load and for .7z takes sometimes 8 seconds. for still pictures non-gif animation, pictures will still take long time in 7z sometimes upwards 6 seconds.

my computer is i7 6 cores at 4.7 ghz, each time switching picture cpu usage would load up takes a long time. is there any hardware acceleration to use GPU instead?

I can't use this to replace window explorer if its so slow.

2

A second is quite long to load a gif if we're talking about a normal sized one on a local drive, not in an archive. Archives can complicate things, although are usually fast as well.

What happens if you open the same archives in something else and double-click the images in there? Are they faster or the same sort of speed?

7z and RAR in particular may be solid compressed, which can mean you need to extract, as an example, 2 GB of data (if the archive is that big, of course) just to extract a small gif file (because solid compression means you have to extract all the files that come before it first).

Antivirus can also slow things down if it is scanning the archive when Opus opens it, and blocking reads from it until the scan completes.

3

thanks for responding Leo.

these are large .gif files, like anywhere between 15MB+ all the way to 100MB+ per .gif, no antivirus on my computer. and if DO lags because of antivirus then lots of user will have problem. window explorer and many others such as total commander or tree view has no such problem, they are all explorer type.

I am using ACDSee 7.0 with power pack right now and decided to try DO. opening it in ACDSee 7.0 and double click the image is instant, loads every .gif instantly in both .zip file and .rar file. for .7z I do not have the plugin to load it in ACDSee 7.0 which that software is like 15 years old.

I have also tried others such as Nomac, though it has no archive reading function, it loads these large .gif instantly even when no compression which DO couldn't do.

Also I wonder if this can be done, this is from quickviewer which is open source maybe DO can take a look at what they did that is different. they can read these large .gif files in rar & zip instantly, compression doesn't even hold them back. only when it is .7z they load up entire .7z into memory maybe takes 5-10 seconds, then once that finish everything in it is instant too.

there must be some thing that can be improved here.

4

Can you send me one of the gifs?

5

here is some smaller ones between 10MB+ to 30MB
https://www59.zippyshare.com/v/WHY0Xp2j/file.html

bigger ones some lag less some lag more so it might not be fully on file size but also resolution. try keeping it in archive first then also extract them into a folder without compression and it also lag like 2-3 seconds for me.

6

I get a "403 Forbidden" error from that link.

You should be able to attach zip archives directly to posts here.

1 Like
7

pictest.rar (62.7 MB)

uploaded here.

8

were you able to find any issue with the gif and DO?

9

I'm looking into why those images are slow.

Will reply when I have something definitive. Please be patient!

10

I think we can speed that up. I'll update the thread when it's done. Aiming for the next update, if all goes according to plan.

1 Like
11

thanks for checking back Leo. could you please tell me what loading speed you are on those image? two of the bigger resolution .gif took me 4.73 and 4.83 seconds to load each respectively with no compression (meaning not in an archive).

would this also improve the speed when reading from an archive? such that loads the entire archive to ram or extract them into ram/temp folder, so each image is fast instead of extract and reloading each image at a time. this would apply for zip, rar and 7z, especially 7z.

12

Let me finish the change and then I can say how much it'll speed things up, or we can give it to you to test and say if you still see any issies.

13

After spending some of today looking at this in more detail, we've decided it will take longer than I first thought, and be part of a more general overhaul of the viewer (to use GPU acceleration, among other changes).

Retrofitting it to the existing animated gif code is looking too complex for the benefit it would bring and user demand vs other changes.

However, if you're happy with the viewer you get in Explorer then you can use the same viewer in Opus. You aren't forced to use your viewer for gif or any other image type. You can configure Opus to use the Windows Photo Viewer for some or all image types, if that's the one you prefer. See How to stop the Opus image viewer from being used by default

And if you just want the first frame of the image in the Opus preview pane, which is what you get in Explorer's preview pane, then disabling the Animated Gif plugin entirely in Opus will give you that (Opus falls back on its internal gif code, which only shows the first frame).

To give more detail on why those images take so long to load with the current code/design:

The animated gif plugin for Opus pre-renders every frame before it starts playing. This is fine with most animated gifs, but ones which are high resolution and high framerate will take a couple of seconds to render. (Those images are more suited to the MP4 format than gif, but we can't deny such things exist, or that we load them slowly, so we do want to improve this.) The design is partly due to some of the unique features the plugin has over other gif viewers, such as being able to play gifs backwards, and flatten everything into a grid showing every frame at once. But it does mean the usual case of playing the animation forward takes longer than if each frame was decoded on the fly.

Making it start playing as soon as the first frame was decoded, and decode the subsequent frames in parallel with playback, was my initial plan, but the logistics of retrofitting that to the old code ended up being quite tangled, and with it being a larger piece of work than expected, we'd rather put that time into a more general viewer overhaul, which will be able to speed this up but also bring a lot of other features people have asked for over the years.

2 Likes
14

thanks for looking into it.

I have a rough understanding now about the difference to other viewer. is there currently settings where I can turn off the ability to play gif backwards and the grid thing you mentioned in order to improve performance before hardware acceleration is implemented?

also my fear for hardware acceleration is that in both chrome and firefox, some gif and mp4s dont play properly because of codec or decoder issue and hardware acceleration has to be disabled in order to view said animation, and that would defeat the purpose in the first place.

do you know approximately how long until HW acceleration and improvement to .gif will take to make it's way into the next dopus?

15

No, the animated gif plugin always loads the whole image up-front. The only things you can do at the moment are disable animated gifs entirely (only show the first frame) or, for double-clicks, use a different viewer.

That shouldn't be an issue. We won't be using hardware to decode the images, only to put them on screen.

Can't say at the moment. There's other work that we need to finish before starting on this, since it's not a small change.

1 Like
16

thanks for responding again.

I will purchase Dopus once this is implemented, since I work on many gifs and archive file such as .7z and .rar at the moment the speed is a serious matter and being able to view everything (including explorer stuff) under a single software is extremely useful and Dopus is closest to what i'm looking for.

also not sure if this may help, the other software that has no lag/delay (ie. quickviewer) uses openGL to load images, not sure what that mean as I am no techie. if it can be implemented into DO along with fast archive viewing (including compression, not just stored) then it'll be one heck of a software.

thank you.

17

I don't think the issue is with how Opus handles archives. It's just that those gifs have a huge number or high res frames and the gif plugin loads everything up-front. They are slow to load whether in an archive or not.

OpenGL relates to how things are rendered, not how the data is loaded into memory, which is where the issue is. But we plan to move to a 3D accelerated viewer for other reasons, and to change the way huge animated gifs are loaded as part of that re-write.

1 Like