First, there is a Windows setting for menu delay, see
How to Control the Delay of the Start Menu Display or
Setting Up Menu Delay Time In Windows 7 or other articles containing the keyword
MenuShowDelay.
But even with reducing this delay and restarting Windows for example to value 100 for 100 ms (which I use since more than 15 years on Windows), the delay of 400 ms (default value of MenuShowDelay) for opening a submenu in UltraEdit v22.00 remains. There is no configuration setting for this delay in UltraEdit itself. A submenu opens immediately when clicking on it.
I restored UltraEdit version 14.20 from my archives, the last version using GDI library of Microsoft, and looked on speed of opening submenus when mouse pointer is positioned over a submenu item. The submenus opened in UE v14.20 as fast as the start menu items, i.e. without a noticeable delay.
Next I restored UE v19.10 from my archives, the last version using GDIPlus library of Microsoft without the additional theme feature making (nearly) everything of UE GDI customizable, and also tested opening speed of submenus. I could see again no noticeable delay.
Last I restored UE v20.00 from my archives, the first version with theme support, and I could see same delay of 400 ms as in UE v22.00.
Conclusion: The new, nearly fully customizable GDI does not take control panel value
MenuShowDelay into account. So the new GDI of UltraEdit does not use
SystemParametersInfo function with parameter
SPI_GETMENUSHOWDELAY to get from Windows the current value for menu display delay and make use of it.
I suggest to send an appropriate enhancement request by email to IDM support. I will not do that as I execute nearly any command in UltraEdit by key and therefore this delay of 400 ms on opening a submenu does not bother me.
BTW: Using Windows Classic as application style (UE theme setting) on a Windows using Windows Classic desktop theme (and therefore no Aero) boosts UltraEdit display updates a lot. Disadvantage: no stylish user interface.