[8.0b13x64] Slow selection in Connect to ftp server

[Sob]

Something very bad happened to Connect to ftp server dialog in 64-bit beta 13. Selecting items in list is suddendly horribly slow and that's understatement. Well, whole dialog was never fast, it has been kind of slow since 7.50 betas (*1), but how it's now it was never before. Clicking another item in list now takes up to half of the second before it is selected (depends on position of item in the list, it seems to be worst at the beginning of open folders).

Sample ini file: http://web.hisoftware.cz/sob/tmp/test-wcx_ftp.7z

TC 8.0 beta 13, 64-bit only. Older betas and 32-bit beta 13 are fine (when not counting *1).

--
(*1) I also complained back then in Extremely slow redraw of 'Connect to ftp server' dialog. Oh the memories. ;) Unfortunately the issue was never fixed completely, even now with much faster computer than I had before it's enough to slowly resize the dialog and TC uses 100% of one CPU core. Not that I'm doing it too often, but even without it, the slow feel is still there (when opening the dialog, expanding folders, ...). Some small optimizations would not hurt. :)

[karlchen]

Hello, sob.

Cannot reproduce the problem. I do not really perceive any difference in speed affecting the "Connect to FTP" dialogue between T.C. 8.0ß13 x32 and T.C. 8.0ß13 x64.
There are about 30 machines in my ftp server list. Maybe this is not enough to experience the reported speed difference?

Total Commander 8.0.ß13 x32
Total Commander 8.0.ß13 x64
Server 2008 R2

Kind regards,
Karl

[Sob]

Let me show you what I see. This is 32-bit version:

http://web.hisoftware.cz/sob/img/tc80b13x86-connect-to-ftp-dialog.avi (1.4 MB)

Although there's sometimes flickering after the item is selected, it's not that bad. While in 64-bit version it looks like this (ignore the wrong cursor, it's recording software's fault):

http://web.hisoftware.cz/sob/img/tc80b13x64-connect-to-ftp-dialog.avi (1.2 MB)

And no, it's not 486 (I'm sure, there were no 64-bit ones :), it's relatively modern 2.66 GHz quad code. And the same can be seen on two other machines I tested. 2 x Windows 7, 1 x Windows 2008 R2.

If you look at all items, not only those being (de)selected, you can clearly see that the whole list is redrawn, but there's no reason to do it.

The used ini is linked in first post. It's created for testing and it mirrors the structure of my real ini file which I didn't want to share for obvious reasons.

One small update: It's little better with Aero, the rest of the list does not flicker, but the slowness and flickering of items being (de)selected remains.

[ghisler(Author)]

That looks like a problem with classic theme. For your information, the aero themes are all double buffered, but the classic theme is not. I will check what the problem could be. Did it work with an older 64-bit version? I'm not aware of any changes in beta 13 which could cause that...

[Sob]

That looks like a problem with classic theme.

Yes, it is better with Aero, but still far from perfect. Unaffected items (all other except selected and deselected one) do not flicker. But for those two, it still takes awful lot of time for selection to move from one to another. For some reason they are redrawn far too many times as can be clearly seen in slowed-down part of the video:

http://web.hisoftware.cz/sob/img/tc80b13x64-connect-to-ftp-dialog-slowed-down.avi (0.1 MB)

And since stuff can happen much faster than the screen capture software can catch it, I guess the number of redraws can be hundereds or thousands, why else it would take so long.

For your information, the aero themes are all double buffered, but the classic theme is not.

I understand that. But it seems to me that even if it can solve some problems, it can also hide other ones. If you look at the last second of video in this post, you can see how the whole list was redrawn. Sure, it was classic theme and it would not be visible with Aero. But why the redraw of the whole list occured in the first place? Only items needing redrawing were those two that exchanged selection. And those were already fine when redraw of the whole list occured.

Did it work with an older 64-bit version? I'm not aware of any changes in beta 13 which could cause that...

There were no differences between 32 and 64-bit versions up to beta 12, they were all fine (minus objections in the first post ;). It's this bad only in 64-bit beta 13. Maybe it has something to do with fix for two selected lines bug which occured in beta 12?

[ghisler(Author)]

You seem to be right - I had to replace W_Connect_List.selected[-1]:=false with a for loop because Lazarus no longer accepts negative indexes (-1 means all in Windows). I will try to find a better solution.

[Sob]

Fixed in beta 14.

Now it is as it was before. Occasional "blink on select" still remains, I kind hoped that one could be fixed too, but can't have everything I guess. ;)

[ghisler(Author)]

Thanks!