Is it possible to make DO's internal viewer showing pictures (jpg, png,...) faster?
Compared to ACDSee the viewer is very slow when switching between next/previous picture.
That's probably because ACDSee pre-loads the next image while Opus doesn't load it until you display it.
It's really much faster, especially when searching between lots of pictures.
I was disappointed when DO first supported Flickr instead of other useful features, but maybe it's an argument now for preloading images 
On my machine, even the biggest of pictures are as close to instant as makes little difference.
Perhaps it's time to upgrade. 
It makes a different when viewing large images on a network drive.
Well store your prawn on a local machine. 
All my machines are local. That doesn't stop my wireless LAN being slow when I am viewing my extensive collection of kitten photos!
How did you know 
(not really!)
Quad2Core, Raid (not network), 4GB RAM,... I don't believe my computer is to slow 
There's really a difference on every computer I compared. ...not between 1,2 pictures, but when scrolling through lots of pictures via mousewheel (no prawn, simple properties we have in our real estate agency).
[ I made some slight edits to the thread to avoid needlessly tripping up work web access firewalls. 
]
Raid by itself doesn't mean much - which type of Raid ?
Perhaps your graphic card is slowing things down ?
Do you have the viewer set to resize to fit the window perhaps ? That's the only time I don't see things instantly. Resizing adds a tiny delay - not long enough to be measurable though.
I've added your 'edit' to the phpbb word censor.
When scrolling fast through some pictures, you'll notice a difference between ACDSee and DO's viewer. That's why I use ACDSee! Resizing to height is enabled on both viewers.
It seems like DO loads the full pic before switching to next, so there's a delay. ACDSee does not, so it switches much faster.
Sorry guys, tested on three high-end machines with very fast hardware (2GB+, S-ATA Raid and Non-Raid, Core2Duo, Quad2Duo, also newest graphic cards with 512MB/768MB ATI & NVidia, etc...).
Maybe I should make a video to proofe, which freeware ist good to record screen?
With all due respect, either you aren't really viewing the biggest of pictures or you haven't seen what pre-loading the image can do. It takes a finite amount of time to read and render a 5MB image. No matter how fast your machine, pre-loading and rendering the image is always going to provide a faster transition to that next image.
Image viewing is one area where DOpus could use a little spiffing up. Aside from issues already mentioned, I've had a repeating problem when DOpus has been loaded and running for quite a while that it begins to not decode JPGs. It only happens after DOpus has been running a long time and has been used to view a lot of images. At some point it begins to claim that perfectly valid JPGs are not valid images. The image size seems involved as well. Once this begins to happen, smaller images will generally display properly, but larger ones fail. It's difficult to accurately describe the situation because of the extensive use that seems to be required before it begins to misbehave.
I've also noticed that attempting to zoom in on very large images will sometimes result in a blank screen rather than a zoomed image.
There is also the long-standing issue of images smaller than full screen not being automatically enlarged to fill the screen, despite settings that would seem to indicate that's what should happen. This is apparently an area of some disagreement between the authors and the user community.
I realize DOpus is not primarily an image viewing program, but there are some fairly small things that could be done to greatly improve it in this area.
Please don't bring up other issues in an existing & unrelated thread. (This isn't a general "problems with the image viewer" thread; it's about image loader speed and pre-loading in particular.) If you want any of us at the forum to look into any of those problems then start new threads for them.
I've answered each point below, briefly, but if you want to follow-up on anything create a new thread so that this one doesn't become a mess.
In fact, I'll lock this thread as I don't think there's anything more to discuss about pre-loading. (Beyond this:)
I agree that it would be good. It's already been sent to GPSoftwre as a feature request. Implementing it could require changes to the way images are loaded, including changes to the plugin API while maintaining compatibility with exiting plugins, so I imagine it isn't a trivial 5 minute piece of work. If it was easily added then we'd probably have it by now. But GPSoftware know there is demand for it.
I've never seen that, after days of dealing with JPEG images without a restart. I don't think anyone else has reported it either so you'll need to do some work to track down and eliminate possible causes before we can help investigate/reproduce it.
When it happens see how much free RAM there is and how much the dopus.exe process is using.
Try disabling all viewer plugins in case they are leaking memory (especially the Movie plugin since video codecs have been known to do that).
Try to find out if it's triggered by particular JPEG files or in unusual situations like viewing thumbnails for 100,000 images or similar.
Post a new thread with any findings and we'll help look into it.
Black images in the viewer happen when Opus tells Windows to display the zoomed image and the zoom fails. The point where zooming fails seems to vary by graphics hardware/drivers and, I think, by available (video) memory. (Or something similar. I don't think it's a static limit as I've seen the same image fail to zoom to 400% sometimes and work okay in others.)
Unfortunately the Windows API which Opus uses to scale the images does not return a failure code so Opus doesn't know that it's put a black image on screen.
It is possible for Opus to fix the problem by zooming the images slightly differently. The original versions of my Animated GIF plugin had the same problem but newer versions do not as I changed the way they did the zooming and found it resolved the problem.
I will be working with GPSoftware to get the same change put into Opus itself (but as usual I've got a million things to do and I'm not sure when that'll happen exactly).
There is no setting in Opus which zooms smaller images up to the screen size. The option is "fit-to-page" and will only reduce larger images if they don't fit on the screen. If they do fit on the screen already then their size isn't changed.
I don't want to argue semantics about whether the name of the mode indicates it will do one thing or another but it isn't a bug, it's by design.
If you want a mode which also magnifies small images to fill the screen then tell GPSoftware.