On 23.09.2011 08:33, Hans-Emil Skogh wrote:
>>> When I use the log dialog to look at the changes made in a file
>>> in an old revision, by selecting the revision and double clicking
>>> a file, a "Getting file" dialog appears. This dialog has no
>>> window title (showing up without a name on the task bar). But
>>> worse, there is a significant delay (more than two seconds on my
>>> machine) between that the dialog appears and the text "Getting
>>> file FILENAME revision ###" is shown in the dialog.
> ...
>> The text is shown as soon as the operation starts. What happens
>> before is only DNS-resolving, connecting and authenticating. That
>> doesn't take two seconds.
>
> Perhaps it does for me? I know that there have been some issues with
> the network here as of late, but I haven't seen any strangeness in
> any other app so far. (Except for perhaps an occasional
> slowdowns/hickups, but not frequently.)
>
> Would it be possible to try to change so that the DNS-resolving,
> connecting and authenticating happens after the text is shown? I
> think it sort of would make more sense to show the text first
> anyway.
Actually, the title and the first info line are set right at the start,
just after creating the dialog object and even before showing it.
>> But what sometimes happens in the progress dialog is that the text
>> isn't shown immediately but with a delay as well. I don't think
>> that behavior can be changed (it's the IProgressDialog from Windows
>> we use here).
>
> Ok. What I'm seeing here does not feel very intentional. But it would
> not be the first time there's a bug in a windows control on the other
> hand...
>
> ...
>
> I'll merge the apply patch progress comments below, since they both
> seem somewhat related. Dialog drawing delays in TortoiseSVN on my
> system.
>
>>> However, applying the patch takes quite a while, and during this
>>> time nothing (visibly) happens. When TortoiseMerge starts to
>>> apply the patch, a dialog is opened (I presume to show the
>>> progress), but it is empty, and without a window title. After a
>>> while windows annotates the dialog with "(Not responding)". When
>>> the patching is done the dialog disappears and everything is back
>>> to normal.
> ...
>> Strange, that dialog shows a lot of progress info for me.
>
> Strange indeed. When I tried to reproduce it one more time this
> morning, it didn't go as far as "(Not responding)", and after a short
> while of "emptiness" the dialog caught on and actually showed some
> progress. The delay was still there, but much shorter. When I tried
> it again the delay was longer, but I still managed to catch a glimpse
> of progress before the dialog closed, as opposed to yesterday where I
> couldn't see any progress at all.
>
> Are we doing anything at all here that is specific to TortoiseSVN
> that potentially could introduce these kinds of delays?
In TMerge, the whole operation isn't done on a separate thread. Unlike
in the log dialog. Using a separate thread should improve the drawing of
the dialog a lot, but apparently not on your system.
Also, the IProgressDialog itself creates its own thread to display the
dialog, so it shouldn't even be an issue. But apparently it is - no idea
why or how I could improve this.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2843808
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-09-23 09:37:42 CEST