VNCServer top row updating

I’ve noticed that VNCServer 0.21 (02 May 2020) isn’t calculating the redraw region correctly, it leaves off the top row of pixels initially.

This can be seen when you close a window, the area of the window is redrawn leaving the line at the top, which is then redrawn after the rest of the window.

It seems to be miscalculating subsequent updates, for example a PackMan progress bar will be seem to slope downwards as it is growing, until the top part is redrawn later.

It’s also obvious if you drag out a rectangle on the pin board, the left, bottom and right crawling ants are updated frequently, but the top line gets far less frequent updates.

I suspect if the redraw region is corrected, it might improve performance as it would no longer need clean up that top row later on.

Yeah, the code for detecting screen updates is a bit funky and could do with an overhaul. I think the last time I looked at it was in 2006, when I was trying to improve performance on the Iyonix.

If you do look at it, is there any chance that a way to restart the remote computer could be added? It is possible to shut down, using the cog or equivelent icon’s menu, but it is impossible to click on the restart button that follows.

I notice that TightVNC viewer has the option to send ctrl-alt=del – maybe that could be trapped.

I use RealVNC on windows and can click on restart and it works when connected to a pi4 and armx6. You don’t get an animated button press so it looks like nothing is happening but eventually the desktop comes back.

I use UltraVNC and the reset button works in a similar way to how Colin describes. On RISC OS, Avalanche also allows the reset button to work here, too. Nothing seems to happen and then the window disappears and you can log back in.

If you do look at it, is there any chance that a way to restart the remote computer could be added? It is possible to shut down, using the cog or equivelent icon’s menu, but it is impossible to click on the restart button that follows.

That should probably be considered an OS bug; on shutdown the OS closes all the open files, which means the DeviceFS streams that EtherUSB is using also get closed, causing the network connection to drop.

Non-USB ethernet should typically maintain its network connection while on the “shutdown complete” screen.

is there any chance that a way to restart the remote computer could be added?

A work-round is to have a little app to perform a restart, and double-click that instead.

It’s a one-liner in BASIC: SYS “TaskManager_Shutdown”, %101000

I’d give credit to whoever it was who taught me that one, if only I could remember who it was.

That should probably be considered an OS bug; on shutdown the OS closes all the open files, which means the DeviceFS streams that EtherUSB is using also get closed, causing the network connection to drop.

So that’s why it does that.

Closing files on shutdown does seem sensible though…
I suppose on other systems this would be dealt with by assigning the file handles to different run levels or to a special user and only closing the ones for that level just before the real restart?

That should probably be considered an OS bug; on shutdown the OS closes all the open files

system equivalent of CLOSE#0 by any chance?

A work-round is to have a little app to perform a restart, and double-click that instead.

I have something to do that job built into my slalom scoring system. It already had a messaging system so that a master program could control what slave computers were doing, so I added “shutdown” and “restart” options. Restart uses the mechanism you mentioned.

It’s a one-liner in BASIC: SYS “TaskManager_Shutdown”, %101000

I’ll drop that into the Apps folder so it’s ready to use. Oh, wait, during startup…

This is what I used in the slalom system. Note that it is necessary to empty the RAM disc first, or shutdown doesn’t happen.

DEF PROCshutdown(restart%)
LOCAL flags%
flags%=1 + (1<<1)
REM wipe discs, force, no verbose, X to suppress "EMPTY" error
SYS "XOS_FSControl",27,"RAM::RamDisc0.$.*",,flags% TO ;flags%
REM don't send pre-quit
flags%=1<<1
IF restart% THEN flags% += (1<<5)
REM don't use flag bit 6, power off, as it silently fails to shut down if
REM the hardware doesn't allow it.
SYS "XTaskManager_Shutdown",flags% TO ;flags%
ENDPROC

I don’t send the warning messages because I’m likely to be using this to fix a program that is not working correctly, and I don’t want to give it a change to abort the restart.

Yeah, the code for detecting screen updates is a bit funky and could do with an overhaul. I think the last time I looked at it was in 2006, when I was trying to improve performance on the Iyonix.

Yep, and the invisible drag and drop is a problem for me. Would it be possible to consider that cursor and surrounding are always to be redrawn?

the invisible drag and drop is a problem for me

Have you tried ‘Filter manager’ off? There might be a slight hit to performance, but it is very much more convenient.

Yes, I know, but perhaps what I suggest could be a solution to keep Filter manager on :)