Since we updated to DOpus 11 (anything else was untouched) we see occasional freezes in DOpus on our systems (Win7; x64; DE).
If it happens it is very simple to reproduce. We just have to modify or create a file inside the dropbox folder and DOpus freezes for 5-10 seconds (hourglass is shown). If it happens for first time it can be reproduced each time (when files are changed). It can be easily fixed by restarting DOpus or closing Dropbox. After restarting DOpus the issue doesn't occur for around 10 minutes. Then it comes back. There are no freezes in other applications (e.g. Explorer). It's the same dropbox version as we have used for more than two years with DOpus 10 without seeing this issue. Updating the dropbox version doesn't help as well.
BTW: The freezes only occur if the changes are made by DOpus itself (e.g. copying, renaming, etc.). If the files are changed in the Explorer and the folder is opened in DOpus as well, there are no freezes at all.
I haven't changed anything by intention in the last 1-2 month. There were no changes in hardware or in deeply integrated software. But certainly there have been lots of auto-updates by various tools and Windows itself. Thus there are thousands of potential reasons for that behaviour.
I will disable the shell extension and I will manually step back to DOpus 10 to see if the freezes occur with the last version as well (then it must be any intermediate change).
For me it looks like a repaint / update problem since the overlays and the context menu are laggy and some parts are flickering (as there are hundreds of repaints). Unfortunately the flickering can't be seen in the video due to the encoding.
That shows the hang is inside the Dropbox shell extension, which is waiting on something. It's not something we can debug. You should report it to Dropbox.
I will do so but as long as I can't reproduce this problem in Explorer, I'm not that optimistic that they will try to reproduce that.
Can you say if there is a chance that DOpus may "flood" the Dropbox API by repetitive calls?
Since I have some clearly visible flickering it looks as DOpus calls the Dropbox DLL multiple times in a sequence within the same second before the freeze occur. On the other hand the same operation performed in Explorer does not show this flickering and even does not freeze. Thus DOpus seems to use the Dropbox API something different.
Assuming that the Dropbox DLL initiates some asynchronous stuff (e.g. network traffic) on each DLL call, it would be an explanation for this behaviour ...
But could it be that DOpus asks the system for the icon overlay multiple times in a sequence within a short time period during a folder refresh operation?
It looks as DOpus incrementally updates the folder by first showing the items, than the file and folder labels are applied, than the folder sizes are shown, etc. Each time the file and folder icons need to be painted again. I can see that there happens many things at different stages before the folder is finally done refreshing. Assuming that the Dropbox DLL is called multiple times at each stage, it could be that the DLL simply blocks after some calls because it doesn't handle these kind of usage very well.