When I upgraded ScreenRecycler to version 0.62 (from 0.56 or 0.58 if I recall correctly), I had noticed that there was a newer way of updating the VNC client when lots of changes or movement on the remote display occurred.
Updates would be displayed first as a blob of unreadable pixellation, then would progressively update to match the precise pixels that need to be displayed.
This is bearable, and I can understand why it was done, but I kind of preferred the old method where things would update slightly slower, but where the pixels shown were the final pixels that needed to be there. "Oh well" I thought, and moved on...
...until I kept running into stability issues with it, where the VNC client would lock up, or certain things (or the entire remote display) would stay pixellated.
It turns out that this is probably due to the addition of Hextile encoding in ScreenRecycler, and the subsequent use of that as a default mode, as noted in its release notes.
Turning off hextile encoding in the ScreenRecycler preferences seems to have fixed this instability. I get my preferred way of screen updating back, too :-)
I'm sure the ScreenRecycler author is fixing these issues, and I'll be sure to send a report about this, but I thought other ScreenRecycler users out there might appreciate the tip if they run into the same problem.