RadOpenFolderDialog is super slow

[Mathieu]

I don't know if it's related to my last post: https://www.telerik.com/forums/radopenfolderdialog-generate-a-lot-of-exception

But that dialog is not usable if it's slow like that.  (see video compare to standard windows explorer, https://send.firefox.com/download/9e9308b253d19daf/#Xz4Pj9NHmh7NnG95iTlRRw)

 

I have a GetForce RTX 2080, I have 4k monitors and I use Windows 1903.  And I use WPF UI 2019.3.1023.45

[Vladimir Stoyanov]

Hello Mathieu,

Thank you for the provided video.

I tested the First Look example of the RadFileDialogs, however I was not able to replicate the same delay with the dragging operation on my end. 

Are you able to observe the same behavior with the First Look example of the RadWindow? Can you replicate the same scenario in a standalone sample project? Additionally, can you share if you have increased the Windows DPI on your end? 

I am looking forward to your reply.

Regards,
Vladimir Stoyanov
Progress Telerik

[Mathieu]

-I have the same problem with RadWindow
-I have 200% scale in Display Settings, I still have the problem with 100% scaling
-I have the same problem in my app, without the debugger it's the same behaviour as the demo.  With the debugger attached it's like 100x worst

[Vladimir Stoyanov]

Hello Mathieu,

Thank you for the update. For the moment, we are not sure what could cause the observed behavior, however we will continue trying to replicate it on our end. 

May I ask you to update the demos application to the latest version and give it a try? Additionally, can you try modifying the Windows Mouse Settings to see, if any of them have influence over the dragging speed? Can you also share whether the monitors on your end are touch monitors? Can you try dragging around another application (Excel, Word) to compare the dragging behavior?

I am looking forward to your reply.

Regards,
Vladimir Stoyanov
Progress Telerik

[Rob A.]

Glad someone else posted this ... I'm having the EXACT same problem.  Takes about 20 seconds before the Dialog window shows up (RadOpenFileDialog).

Valadimir,

I suggest you test this problem with NAS mapped network drives and/or mapped drives that are currently NOT connected.  I tested on another computer that only has a C and D drive and no NAS or network mapped drives and the RadOpenFileDialog worked in <1 second.

I need a fix for this problem ASAP, as I'm about to deploy in a week or two.

Cheers, Rob.

[Vladimir Stoyanov]

Hello Rob,

May I ask you to share some more information so that we can replicate the scenario on our end and investigate it? Can you elaborate on what you mean by "NAS mapped network drives"? You can share some steps/guidelines or a video demonstrating how we can achieve a similar setup and test the scenario. 

Alternatively, you can let me know how you are disconnecting the network drives on your end. Again, some guidelines or steps, which I can follow in order to test the scenario will be appreciated. 

Thank you in advance for any help you can provide.

Regards,
Vladimir Stoyanov
Progress Telerik

[Rob A.]

Hi Vladimir,

See attached image for my drive mappings.  NAS stands for "Network Attached Storage".   In the attached image my Z drive is mapped to my NAS.  My T, U, V, W, X, Y drives are mapped to other computers on my network that are currently NOT powered on hence the red X.  My C, D, E, F, L, M drives are local storage contained inside my development PC.

Here is an unlisted video demonstrating the problem:

Video of slow RadFileOpenDialog

It takes 9 seconds for the FileOpenDialog to appear on first attempt.  4 seconds to appear on subsequent attempts.  This is "per RadWindow" session ... meaning if I close the RadWindow with the Browse button, open that RadWindow again and repeat the Browse (FileOpenDialog) test, it will be 9 seconds first attempt and then 4 seconds every subsequent attempt.

All other applications I have that do NOT use the Telerik RadFileOpenDialog appear within less than 1 second, so the issue is specific to Telerik RadFileOpenDialog.

 

Cheers, Rob.

 

[Vladimir Stoyanov]

Hello Rob,

Thank you for the provided picture and video. 

I am afraid that I do not have access to any NAS drives to test the scenario. That is why I tried to replicate the disconnected drives scenario. Here are the steps, which I performed: 

1. I created 10 folders on my machine, which I shared (you can check out the sharedfolders.png and sharedfoldersproperties.png).

2. I mapped each of the 10 folders to a drive and then I stopped sharing each of the folders. You can check out the result in the drives.png.

With this setup, I was not able to reproduce a difference in the opening time of the dialog. On my machine it is opened for the same time with or without having the disconnected drives. I am attaching the sample project, which I used for testing purposes.

May I ask you to try setting up the shared folders as described above on the computer that only has a C and D drive and try opening the dialog with the shared sample project? Is there any difference after having the additional drives?

On a side note, you can check out the following article: Improve Load Performance for some tips on how to speed up the loading of the dialogs. 

I am looking forward to your reply.

Regards,
Vladimir Stoyanov
Progress Telerik

[Rob A.]

Per my screenshot, perhaps you missed it, the mapped drives are shares on different computers and those computers are OFF ... they are NOT shares on the same computer so you are not duplicating the test scenario I presented.

If I use the standard Microsoft FileOpenDialog, I do NOT experience any performance so clearly the problem lies within Telerik RadFileOpenDialog.

Did you look at my screenshot of my mapped drivers?  You can see the computer names are different for drive mapping T, U, V, W, X, Y, Z  these are NOT local resources or local shares (hence the red X in the map icon).

As far as the Improve Load Performance link:

I'm using XAML with StyleManager, this can NOT change ... but I think this is where you NEED to look as there is clearly some "caching" happening hence the variance in load times from initial 9 seconds to subsequent 4 seconds.  My hunch the slowness problem is related to XAML and StyleManager.

ExpandToCurrentDirectory = False - made no difference in load times

LoadDrivesInBackground = True - made no difference in load times

Setting InitialDirectory to a shorter path made no difference in load times

Changed my project to "Release" mode (x64) and load times reduced by 1.7 seconds (down from 9 seconds in debug to 7.29 seconds in release)

Is there any work around until you can get this fixed with XAML/StyleManager approach, perhaps add an option to disable theme for the RadFileOpenDialog where it would just default to whatever the Windows theme is?

Cheers, Rob.

[Rob A.]

I made another video that clearly demonstrates the performance problems with RadOpenFileDialog ...

My application running on the same computer using "debug" mode x64 ... first part of the video is using Microsoft's openFileDialog (<1 second to load), the second part of the video is using RadOpenFileDialog (9 seconds to load).

Video of Fast MS FileOpen Dialog vs. slow RadFileOpenDialog

No offense, but this is clearly a problem with RadFileOpenDialog and it's NOT my environment.  As a work around I'm going to use the Microsoft OpenFileDialog, but I do hope you folks address this problem.

Cheers, Rob.

[Vladimir Stoyanov]

Hello Rob,

Thank you for the additional information. 

To address your question, the UI for WPF controls will always have one of the themes applied. When using the StyleManager approach, the default Office_Black theme will be used, if you have not specified a theme explicitly. The Xaml dlls are generally bigger in size, since they contain the xaml for all of the available themes and lead to slower loading times. That is why using the NoXaml dlls with implicit styling will generally lead to faster loading times as you can only include the dll of the theme that you want to use. 

With regards to the mapped drives my understanding was that the drives have to be inaccessible and it does not matter whether they are mapped to folders on the same computer or on a different one. That is why I shared some folders on my own machine, mapped drives to them and then I stopped sharing them. 

That said, I tested the scenario with drives mapped to inaccessible folders on one of my colleague's machines (you can check out the drives.png image). With this setup there is still no difference in the opening time of the dialogs on my machine (around 13 seconds). 

I should state here that we are aware that there is room for improvement with regards to the loading times for the RadFileDialogs. We have an item logged in our feedback portal for that scenario: FileDialogs: Improve the initial loading time.

That said, the RadFileDialogs do not inherit the default windows dialogs, which allows for customizing their look and have some wrappers over native APIs. This means that there will always be some overhead with regards to the native windows dialogs. If the loading time of under one second is important for your scenario, my suggestion would be to stick to the native dialogs. 

Regards,
Vladimir Stoyanov
Progress Telerik

[Rob A.]

Hi Vladimir,

Glad to see this is logged in your feedback portal and I hope it gets priority.

FYI, as a test, I coded my own FileOpenDialog using RadWindow and RadTreeView and other telerik controls that are "themed" and populated with file/dir information and it displayed in about 2 seconds.  Not as fast as MS control, but much faster than your RadOpenFileDialog.

Maybe your RadOpenFileDialog code is attempting to populate ALL files and Dirs from the initial drive prior to display rather than just dirs and only the files in the select/initial folder/dir?  This might explain why it's so slow.

Cheers, Rob.

[Dilyan Traykov]

Hi Rob,

My name is Dilyan and I'm stepping in for my colleague Vladimir who is currently out of office.

I can state that we do not load all the files and directories from the initial drive upon loading the dialog.

What I can suggest at this point is to profile the application to determine which method(s) cause the degraded performance and share the profiling results with us so we can try to pinpoint the exact cause. You can also handle the ExceptionRaised event and see if and what exceptions are being raised which may also slow the performance of the control.

Can you also please clarify the exact version of the Telerik UI for WPF suite you're using and whether, if it's not the latest, you would find it possible to update to the latest release? I'm asking this because we did introduce a few improvements with our R1 2021 release related to some operations being executed on a background thread as well as the LoadDrivesInBackground property which may prove handy in your particular case.

Please let me know whether you would find using the latest release possible and if the LoadDrivesInBackground property provides some improvement in the performance.

Regards,
Dilyan Traykov
Progress Telerik

[Willy]

Is this not available for Winforms? I am having the same issue with the Open Folder Dialog

[Dilyan Traykov]

Hello Bill,

Can you please clarify which functionality you're referring to? Are you talking about the LoadDrivesInBackground property?

Would you also clarify whether you're using the WPF RadOpenFolderDialog or its WinForms counterpart? If the latter is the case, may I kindly ask you to open a new thread regarding this in the respective WinForms forum and describe your issue in detail?

[Willy]

Yes LoadDrivesInBackground for WinForms. I can open a new thread in the other forum!