Slow window repaint when dragging

[molecool]

I don't think the subject line really describes the problem properly which is why I made a video:

http://evilspeculator.com/stuff/2015-05-09_1410.swf

Take a look at let me know what I can do to adjust this. Again, a lot of us are using remote systems housed in data centers these days, especially in the trading arena. So the use of RDP or LMI is probably very widespread. We need a way to adjust pane and panel repainting in a fashion that makes remote usage less painful.

For the record - the actual repainting seems to be faster on NT8 than on NT7 - it's the continuous repainting that's slowing things down. Also please disregard the last part of the video - clearly repainting behavior is driven by the GPU and not the CPU.

I filed a separate report on the strange cross hair cursor behavior.

[NinjaTrader_Ray]

I don't think the subject line really describes the problem properly which is why I made a video:

http://evilspeculator.com/stuff/2015-05-09_1410.swf

Take a look at let me know what I can do to adjust this. Again, a lot of us are using remote systems housed in data centers these days, especially in the trading arena. So the use of RDP or LMI is probably very widespread. We need a way to adjust pane and panel repainting in a fashion that makes remote usage less painful.

For the record - the actual repainting seems to be faster on NT8 than on NT7 - it's the continuous repainting that's slowing things down. Also please disregard the last part of the video - clearly repainting behavior is driven by the GPU and not the CPU.

I filed a separate report on the strange cross hair cursor behavior.

Thanks. If you are on a shared VM, the rendering is actually done through software (WARP) and we can see clearly what you mean. Will add to our list to consider a non-repaint approach for window re-size/move operations.

[sam028]

I do not have this problem in RDP.
See http://www.screencast.com/t/lOV226eWeBSl , connected to one of my VPS in NJ, with around 100ms latency from my RDP client.
So it's more an RDP bandwidth/latency issue in this case, IMHO. It can be verified in trying to watch a 720p Youtube video from the remote server in RDP (not in full screen, that will be too much).

[molecool]

Thanks. If you are on a shared VM, the rendering is actually done through software (WARP) and we can see clearly what you mean. Will add to our list to consider a non-repaint approach for window re-size/move operations.

Thanks Ray - I actually opened a few more apps and observed standard repaint behavior as on NT7. So it's got to do with the UI kit you guys are using - should be easy to turn off repainting until mouse up. Again, I know this is probably low priority for you guys right now - I'm just reporting stuff as I come across it.

[molecool]

I do not have this problem in RDP.
See http://www.screencast.com/t/lOV226eWeBSl , connected to one of my VPS in NJ, with around 100ms latency from my RDP client.
So it's more an RDP bandwidth/latency issue in this case, IMHO. It can be verified in trying to watch a 720p Youtube video from the remote server in RDP (not in full screen, that will be too much).

That's exactly my point though - the behavior is connection dependent. BTW, I got a fiber connection at my house but clearly the latency between Spain and the U.S. (where my server is) affects me. But in general this is the first time I observed this issue via RDP, thus I think it's a good idea to nip it in the bud early on. It's great that you don't have any issue but as soon as there is any latency the problem will emerge. Plus it's fixed relatively easy.

[gregid]

A compromise would be new property in Options: "RDP mode" (bool).
Checked it would remove some niceties like the window rendering on move.

[molecool]

A compromise would be new property in Options: "RDP mode" (bool).
Checked it would remove some niceties like the window rendering on move.

This seems to be a WARP related issue. Should be relatively trivial to automatically set a flag when a RDP client is detected. Then simply skip repainting during mouse down. I know - easily said - I'm not familiar with the WARP API but have hopes that it offers that capability.

[gregid]

This seems to be a WARP related issue. Should be relatively trivial to automatically set a flag when a RDP client is detected. Then simply skip repainting during mouse down. I know - easily said - I'm not familiar with the WARP API but have hopes that it offers that capability.

Automatic flags would apply to everyone on the RDP including those (like Sam) who don't have this problem. So manual flag may be considered a better option.

[molecool]

Automatic flags would apply to everyone on the RDP including those (like Sam) who don't have this problem. So manual flag may be considered a better option.

Sam - could you please try if you have any problems with the crosshair cursor and scrolling the chart via mouse dragging over RDP? Thanks!

[sam028]

Sam - could you please try if you have any problems with the crosshair cursor and scrolling the chart via mouse dragging over RDP? Thanks!

This is what I've done and it's shown in this video (it was in my previous post).
On another VPS, with less horsepower, higher latency and a backup running (so everything is slow on it right now) I have the same behavior as you, a bit worst in fact (the crosshair is never visible, scrolling via mouse dragging is impossible).

[molecool]

This is what I've done and it's shown in this video (it was in my previous post).
On another VPS, with less horsepower, higher latency and a backup running (so everything is slow on it right now) I have the same behavior as you, a bit worst in fact (the crosshair is never visible, scrolling via mouse dragging is impossible).

Awesome, thanks for doing that - so it seems it's not just me (phew - I was getting worried )

[sam028]

I did more tests and it's not a latency/bandwidth problem, while connected in RDP.

So few major issues while connected to a Windows 2008 R2 machine:
- the cross hair is only shown on the top right, when you're back on a chart and click to go to the latest bars
- scrolling with mouse, is not working
- all actions inside the chart zone, where the bars are painted (not the menu buttons not the instrument tab at the bottom) seems to cause a "lost focus" (see the red arrow in the video below)

This video should be self-explanatory.

If you guys @NinjaTrader want to check by yourselves I can give you few Windows 2008 R2 VPS to try.

[molecool]

I did more tests and it's not a latency/bandwidth problem, while connected in RDP.

So few major issues while connected to a Windows 2008 R2 machine:
- the cross hair is only shown on the top right, when you're back on a chart and click to go to the latest bars
- scrolling with mouse, is not working
- all actions inside the chart zone, where the bars are painted (not the menu buttons not the instrument tab at the bottom) seems to cause a "lost focus" (see the red arrow in the video below)

This video should be self-explanatory.

If you guys @NinjaTrader want to check by yourselves I can give you few Windows 2008 R2 VPS to try.

Cross hair only showing only on top right - confirmed.
Scrolling with mouse not working - confirmed.
I also am unable to do a right mouse click and get detailed price information.

By the way - my remote systems are running Windows 7. Thanks again for testing this, Sam.

[NinjaTrader_Matthew]

Just wanted to let you guys know we're triggering more in depth VM/RDP testing as a result of some of the observations in this thread.

[sam028]

Just wanted to let you guys know we're triggering more in depth VM/RDP testing as a result of some of the observations in this thread.

Thanks.

It would be a very big problem if the remote users have to use Windows 2012 R2 or Windows 8.1, and not the good old 2008 R2/Seven.
I had some hope and did an update to RDP 8.1 on a Windows 2008 R2 host but same result...