>All,
>
>I'd be interested to know latest thoughts on SYS(602) bitmap configuration under terminal services.
>
>Standard VFP does refreshes using off-screen bitmaps that get snapped onto the visible screen for crisp refreshes; however, since this uses "a lot of memory" we were told that when using TS it's good practice to use SYS(602) to turn this feature off.
>
>However: I have an app using backstyle_access in a grid control to deliver dynamic row appearance. Under RTS with off-screen bitmap off using sys(602), the grid flashes and flickers unpredictably. No problem with standard bitmap setting. I have experimented with set focus and similar, but the flickering continues intermittently if off-screen bitmaps are off.
>
>VFP's use of memory seems very low regardless, so I would leave the setting on- except it was also suggested in one of the guru VFP books that VFP's standard bitmap behaviour can send a deluge of updates down the wire; I suppose that could be true if the whole screen gets refreshed every time compared to just updating the changes.
>
>Does anybody have updated info on this?

Not really any new info per se, but some comments:

I believe SET BITMAP=OFF for CONFIG.FPW was introduced in VFP6 (AFAIK SYS( 602 ) is basically the same thing but callable within an app). That was around the turn of the century. The remote access world was very different:

- Low connection speeds. For SMB, any kind of nascent broadband was a luxury, if available at all. I was setting up SMB networks with shared dial-up internet access (at best 56 Kbps). Bandwidth was a real issue, watching any screen redraw could take multiple seconds. Reducing screen redraws would be a big win

- I believe RDP is much smarter than it was back then. As I understand it, it takes server-side screen output calls and transmits those directly to the RDP client, which renders them on the client. This is the same idea as printer control languages such as PostScript and PCL; you transfer commands if at all possible and bitmaps only when you need to. In that scenario I'm not sure you even need a virtual frame buffer server-side, you just redirect commands that would have affected one over the wire to the remote client

- It wouldn't surprise me if RDP were smart enough to recognize multiple screen updates happening very close together, buffer them server-side, and send only the final result to the client. If this happens at a reasonable refresh rate, it would appear very crisp to the client-side user

- I imagine that any VFP controls or screen elements which in later versions of VFP have actual Windows presences would help in the above

- As for server-side memory, other than some VFP9 patches, VFP development ended in 2005. At that time Windows was basically 32-bit; 64-bit Server 2003 was rare and exotic, 64-bit XP even more so. A typical 32-bit Terminal Server only had ~3.2GB total memory available. If that had to support a bunch of remote users then yes, anything which could reduce session memory usage could be useful. In the modern 64-bit world I don't think VFP apps need to worry about memory usage

So if there's any truth in this wild-eyed speculation:

- It's possible SYS( 602 ) is a corner-case "trick" which RDP doesn't know about and which might interact badly with its optimizations
- I doubt any RDS memory savings using it would be significant on a 64-bit server

All that said, I think the most important thing is "YMMV". Test it for a particular remote-access environment, or offer it as a configurable preference in the app. What works great for RDP over broadband with low latency may not for GoToMyPC or Teamviewer at lower speeds over satellite.

UPDATE: some further speculation, some other VFP-specific things might affect screen displays in remote access apps. For example:
- .LockScreen
- .AutoYield
- DOEVENTS