More efficient painting (for example, remote desktop)

[chrisant]

SE tends to do full-window repaints, even when only a subset has changed (especially when scrolling).  This makes SE very difficult to use over a Remote Desktop Connection, because the screen is constantly doing full repaints.  Also it seems to clear the entire background, and then paint each line.

When I'm on a 1Gb local LAN it's possible to use SE over RDC, but it's cumbersome.
When I'm on a 16Mb cable connection SE isn't really usable over RDC.

Some suggestions:
- Do minimal (or at least less maximal) repaints.
- Avoid multiple full repaints in response to a single user action; try injecting a Sleep(500) at the end of each WM_PAINT to help to flush out cases where several full window repaints happen in a row.
- Try to use ScrollWindowEx on Windows when scrolling window content, so the parts that were already visible don't need to be repainted.
- Instead of erasing the window background at the beginning, erase the background for a line immediately before painting that line.
- Consider double buffering to eliminate flicker.

If you don't have a way to repro using SE over a slow RDC, you can try injecting a Sleep(500) (or higher) at the end of each WM_PAINT.  Or let me know and I can record a video showing what the experience looks like.  (Is there a decent free screen capture video recorder for Windows?)

Severity:  High -- This is very painful when trying to use SE over RDC.
Priority:  Medium-Low -- The scenario isn't a critical one, and most of the time there is one way or another I can work around it and get my task done (worst case use Notepad or whatever).

[jorick]

I have to agree with the last post.  Screen refreshes are sometimes numerous and constant.  Many times I can see the search results window flickering as it redraws itself at a rate of 4 or 5 times a second for minutes at a time (usually happens when some other application has focus).  In fact, it's happening right now as I type this.

BTW, I use HyperCam 2 (unregistered) to record a video of a window.  Best recording software I've seen.

[LBCEi]

@chrisant:  I've used CamStudio with good results.  Might have to check out HyperCam as well based on jorick's recommendation.

[timur]

SE tends to do full-window repaints, even when only a subset has changed (especially when scrolling).  This makes SE very difficult to use over a Remote Desktop Connection, because the screen is constantly doing full repaints.  Also it seems to clear the entire background, and then paint each line.

This problem exists in Linux as well, using a remote X Window connection.  Also, I've noticed significant screen corruption when running SE on Linux inside Parallels Desktop.  Granted, the corruption happens to other apps, so it's not an SE bug, but because of the excessive redraws that SE does, it's much worse with SE.

However, I suspect that this is something that will never get fixed, because it's probably entrenched in the window library that SE uses, which is necessary for keeping SE cross-platform.  This is why I asked in another thread whether it's okay to install SE on multiple computers.  It's easier for me to install SE on every possible machine that I use and just copy my source files back and forth.

[chrisant]

In my case, I can't install 65GB (yes 65GB) of prioprietary work sources on my personal computers -- the only way I can work remotely when needed is to use Remote Desktop Connection.

[Clark]

SE tends to do full-window repaints, even when only a subset has changed (especially when scrolling).  This makes SE very difficult to use over a Remote Desktop Connection, because the screen is constantly doing full repaints.  Also it seems to clear the entire background, and then paint each line.

When I'm on a 1Gb local LAN it's possible to use SE over RDC, but it's cumbersome.
When I'm on a 16Mb cable connection SE isn't really usable over RDC.

Some suggestions:
- Do minimal (or at least less maximal) repaints.
- Avoid multiple full repaints in response to a single user action; try injecting a Sleep(500) at the end of each WM_PAINT to help to flush out cases where several full window repaints happen in a row.
- Try to use ScrollWindowEx on Windows when scrolling window content, so the parts that were already visible don't need to be repainted.
- Instead of erasing the window background at the beginning, erase the background for a line immediately before painting that line.
- Consider double buffering to eliminate flicker.

If you don't have a way to repro using SE over a slow RDC, you can try injecting a Sleep(500) (or higher) at the end of each WM_PAINT.  Or let me know and I can record a video showing what the experience looks like.  (Is there a decent free screen capture video recorder for Windows?)

Severity:  High -- This is very painful when trying to use SE over RDC.
Priority:  Medium-Low -- The scenario isn't a critical one, and most of the time there is one way or another I can work around it and get my task done (worst case use Notepad or whatever).

SlickEdit 2012 (v17) will be using double buffering which should fix all blinking we have right now.

[chrisant]

SlickEdit 2012 (v17) will be using double buffering which should fix all blinking we have right now.

Nice about the flicker.  Any sense yet about minimal repaints?