Pinned Windows

Concerning the pinned windows in Nvil, such as by default config, the "material Window"

In last 32bit version (dec-23), the pinned window after it being shown, would scroll back quickly, but more importantly, would not interfere with other functions.
In the latest 64 bit (jan-09), the pinned window after it being shown takes longer to scroll back, but the main problem is that it is interfering with such as viewport navigation.

For example.
In last 32bit version, while a pinned window was scrolling back, I could still viewport navigate(rotate view). But in latest 64bit version, I cannot viewport navigate(rotate view) until the pinned window as scrolled all the way back to position.

I have never really seen a need for scrolling windows, but just put up with them in Nvil, that is until they interfere with workflow, as they are doing now.

Please fix.

Have you tried increasing scrolling speed? Edit > Preference > Colors > Form Color Scheme > Dock hide speed.

But that does not fix the bug, it just shortens the time the bug causes issue.

What about the "Instant help", that is also interfering with commands and viewport navigation.
For simple example, there are numerous streamline tools enable to NMB, as with "Polygon extrude normal"(A). With sub_selection made, press "A" and move mouse, the extrusion will stop for a short while as the instant help window is scrolling down or up.

That's the only thing I can do with the autohide panel. The maximum speed is 10 and I can't see a way to get it hidden instantly.

Do you want a way to hide the "Instant Help" faster? Can do that as it is all my coding.

That's the only thing I can do with the autohide panel. The maximum speed is 10 and I can't see a way to get it hidden instantly.

But the problem with the scrolling windows is a new bug. It was not a problem before you changed to 32+64bit and slimDX. Are you saying this is how it should now work and interfere with tools/functions?

Do you want a way to hide the "Instant Help" faster? Can do that as it is all my coding.

Personally I would prefer no scrolling on Instant help (and for it to remember window size between sessions).
But I am more concerned with the fact that it interferes with functions and will be off-putting to new users, who will not know about any possible extra option you put in place to attempt to workaround such a bug.

It should work as before now. I also link the Instant Help scroll speed to the dock hide speed setting.

It should work as before now.

No. It does not. (Have also checked with a new config)

It appears the only change you made, was to change the default dock speed from 1 to 10. As I have already stated, that does not fix the bug, it just shortens the time the bug causes issue.

Try the new update again.

It is still not the same as before.

In the previous 32 bit version, it appears(to me anyway) you where probably using multi-cores, a cpu core for windows (transitions) scrolling and a cpu core for(example) screen navigation.

In the 64 bit earlier versions, the multi-core as been removed, and the scrolling was taking up a single core, and the screen navigation could not be used until the scrolling had finished.

In the latest version, it appears you have added some form of interrupt to force a single core to jump between the window scrolling and the screen navigation, which causes both to (for lack of a better word) stutter.

If you insist on having transitions/scrolling windows, at least have them work correctly, and not cause issue with other functions. The UI is what new users see first, if that is not working well, IMHO, new users can easily be put off.

The dec-23-2013 version and the jan-10-2014 versions are the same in threading handling. I have checked that they have the same behaviour in my pc. Viewport navigation scutters on both versions while the pinned window is scrolling back.

I did create a boost on the rendering thread in the jan-11-2014 version. The viewport navigation gets better but the pinned window's scrolling gets worse.

I don't control the pinned window scrolling thread in my code. It is actually out of my control.

There are rendering thread suggestions in a SlimDx page.
http://slimdx.org/tutorials/BasicWindow.php
I use the second method as It is not for a game which needs constant rendering so message cue won't cause much problem.
If I use the third method, you won't be able to navigate viewport at all when the pinned window is scrolling.

There are rendering thread suggestions in a SlimDx page.
http://slimdx.org/tutorials/BasicWindow.php
I use the second method as It is not for a game which needs constant rendering so message cue won't cause much problem.

The link takes me to a page concerning slimDX and Direct3D 11. Nvil loads and uses Direct3D 9.

The threading is the same. It has nothing to do with Direct3D9, Direct3D10 or Direct3D11. The third method is from Top Miller who was in charge of MDX which is Microsoft Direct3D9.

So a long way of telling me you cannot fix it.

I don't know. There may be a way but just don't find it yet. Or maybe there is no solution at all. My current concern is if there is no solution for this, which one has the priority in performance, pinned window scrolling or viewport navigation?

On checking again with a new config, the problem is only seen as the pinned windows are scrolling on the view-port (as it scrolls over the Visual tools, it is as before). So I would suggest you at least make the "material window" by default not scroll out as for as it does (which at the moment is too far).