ratfink wrote:

So the only possible culprit from this testing seems to be the relatively poor [as measured] 2D display speed of the gtx560ti compared to the hd4850. To test that I'll have to move cards around which I don't really want to do.

Before getting to your quote above, that was going to be my first suggestion. 😀 That seems most likely to be the culprit. Another related possibility is graphics drivers. Maybe the Vista HD4850 drivers are more optimized than the Win10 GTX 560Ti drivers. You're left with, even if you swap cards, you might not get a clear answer if, let's say, the Vista GTX 560Ti drivers are better optimized than the Win10 HD4850 drivers. Sounds like a really annoying problem!

Nothing of importance or speciality is being unleased from your card by this software. It will all be down to the parallelism of your machine. ... Cores & Effect.

P.S The min requirements on the website say 1024 x 768 XGA so a bit of a give away o.0. You'll probably get the same performance with a Rage128 in there 😵
http://www.silkypix.eu/developer-studio-pro-7 … 8-bd81144a-47ee

You could try to run the Tom2D benchmark on both machines. (Of course I don't know if Silkypix uses GDI or Direct2D.)

Ok so I have tried running Vista on 4 cores using msconfig. Makes it a bit slower but - for example - the thumbnails in Silkypix still load almost immediately I click on a folder, whereas on the 10 machine it's 4-5 seconds before they appear. So whatever is causing this, it's not the number of cores.

Can't find Tom2D, seems the tom's hardware download has been removed 😒 .

Maybe just an operating system issue? It might be some windows update causing windows 10 to act weird, wouldn't be the first one.

Hmmm. Agree with Aideka, its probably win10 then 🙁. Can you process your RAW's (i.e process one raw some filters or exposure etc and then do the same with the same raw on the other system. Compare how long it takes to do this. It should be similar-ish). If its just the 'import' functionality (i.e previewing the raws before import) which takes time, then this could very well be a standard windows resource used by SilkyPix which has changed some what between the two OS's which has produced this 'hang'. If you are a paying customer, I would open a support ticket/bug with SilkyPix, as I doubt there is much you can do to improve this until ether win10 or SilkyPix sort out the issue, they should be able to isolate what's taking the time unless it only manifests on your PC (which wouldn't be good news as its one of those annoying issues which is out of your hands I'm afraid). Good Luck.

Ok - I have batch developed 19 RAW files on each, and the Vista machine was about 10% faster, which is in line with the passmark results. So the problem does indeed seem to be specifically on previewing. I've submitted a ticket to Silkypix. I'll post back if I hear anything.

Thanks for your help 😀

Could it be because Windows 10 includes Defender by default, and you aren't running any kind of anti-virus on Vista?

Windows defender is a good point, on my windows 8.1 laptop I have to shut down realtime monitoring sometimes when playing games that have a lot of files. Also, I was playing around with the Silkypix program and used a debugger, the software seems to sometimes call zipfldr.dll functionality when opening folders, what is weird is that I couldn't get it to display files inside of zipfiles anyway. I tried it on windows 7, but had no performance issues here. The image preview starts it's own thread every time you open a folder, and on my dual core i5 with hyperthreading the image preview used about 25% of the cpu power. That leads me to believe that te preview function isn't multithreaded and more cores won't help that part at all.

Deep Thought wrote:

Could it be because Windows 10 includes Defender by default, and you aren't running any kind of anti-virus on Vista?

I'm running Windows Defender on 10 and Microsoft Security Essentials on Vista. Both on recommended settings as far as I know [so real time protection is on].

Edit: I've tested disabling real-time protection in Defender on 10: it seems to makes no discernible difference to the preview lag.

Aideka wrote:

That leads me to believe that te preview function isn't multithreaded and more cores won't help that part at all..

That's not great, this is exactly the kind of process which could leverage threading for great success.

If they haven't threaded this, I wonder if any of it is threaded for multiprocessing. Especially since processing 19 images yields only 10% difference despite 50% more cores ???? That doesn't make much sense to me, even with the clock speed difference?

So, after some more testing I have come to conclusion that the software might afterall be threaded even in opening previews. I am not sure what I or the program did differently before. One thing I noticed though, is that the software seems to be loading the previews for 3 pictures at a time, and when those previews are ready, it starts to load more. I have a hunch, that the program automatically looks how many cores you have, and loads the previews on all but one core. That one core is then used on whatever else the software needs done.

spiroyster wrote:

I wonder if any of it is threaded for multiprocessing. Especially since processing 19 images yields only 10% difference despite 50% more cores ???? That doesn't make much sense to me, even with the clock speed difference?

Just to be clear, the Silkypix interface indicates that the images are being processed sequentially, one at a time. Although under Trouble-shooting there is a setting to prevent parallel processing of images [not set on my 10 system, will check Vista but I wasn't aware of it so should be the same]. Perhaps that is about concurrent access of the same image though.

It sounds like it is threaded to be honest (which isn't surprising).

The reason I asked this was because batch processing a set number of images and examining the time taken *could* give a indication as to what is happening.

Per pixel processing (such as increasing/decreasing exposure or applying a gamut) can be considered mutually exclusive from any other pixel and thus lends itself very well to parallelisation. This isn't as clear cut when applying filters since these tend to consider a region of pixels, and thus requires all pixels in that region to be pre-processed before being included in any filtering. This too can be parallelised but requires more sophisticated scheduling and memory management as race conditions can become more of an issue.

So for a batch process of 19 images, if threading was indeed employed at this stage of the workflow, more cores *should* be obvious, unless it is capped to use a max (say no more than 4) threads, in which case it is multithreaded, but the only difference would be down to the clock speed and not the extra/less number of cores (maybe this is the 10% difference, and the extra 2 core in the hexacore aren't used by SilkyPix? unsure). All this does not even take into consideration OS overhead differences.

Incidentally, the concurrent loading that you see in the import preview could actually be achieved without threading, yet still give the impression of parallelism, but would also mean there is only ever one thread employed for this. Think of it more like multi-tasking than multi-threading.

In short its a rough indication at best, but still perhaps slightly entertaining attempting to try and second guess what's going on 😀

tbh, if it wasn't using as many cores as possible, it probably wouldn't be that competitive with other software (unless its a lot cheaper or free compared to say Lightroom, I have never heard of silkypix before so idk). Sounds like Aideka did some rudimentary profiling to see what might have been taking the time and came across zipfldr.dll. The usage of this makes sense, as it appears this dll is used for querying the contents of a compressed folder, so not surprising this may be done when previewing files or navigating the file system. Couldn't find much in MSDN about it apart from some dated ME/XP-era references to its use, although win 10 obviously still has "Compressed Folder" feature and so it wouldn't surprise me if it still uses zipfldr.dll along the way some how or in its entirety (its certainly there in both System32 and SysWOW64 on my win 10 laptop).

It would appear that's its too low level an issue to try and fix without proper debugging (with symbols, not a "release" build) and so the SilkyPix team will hopefully find out what is wrong, you may get lucky fiddling with settings, or you may not. Still worth perhaps looking at if it pisses you off as, depending on their development cycle, it may some time before you see any response to this in terms of a fix.

Although under Trouble-shooting there is a setting to prevent parallel processing of images [not set on my 10 system, will check Vista but I wasn't aware of it so should be the same]. Perhaps that is about concurrent access of the same image though.

hmmm, this could relate to how many images it's going to work on (multi-tasking), but does sound more likely its going to be the number of threads (multi-threading). I doubt its to do with the access of the same image though, since these programs tend to have 'non-destructive editing' so access to these images isn't regulated. The original raws are probably not touched at all. One way to find out, process a large number of images with it turned on and then turned off and then try to make sense of the difference as you have done already with the other 19 images.

Thanks, can I just say that I'm very grateful to the time you and Aideka has spent looking at this - it's very kind of you and it's certainly improved my understanding of what might be going on here.

One of the reasons I put up the thread was that I was trying to decide whether there was a way of moving everything to 10 or whether I still needed to run Vista. Looks like the answer is that I do need Vista as for the foreseeable future this display lag is likely to remain in 10.

Thanks!