VNC Client

After hunting around the Wimp sources a little, I think the problem may be in AutoScroll.s, in particular poll_autoscroll which if I’m understanding things is called from Wimp_Poll(Idle) prior to cantchange. If auto scrolling is enabled, using OpenWindow events and is unable to scroll then it looks like this will return with R10 set to the autoscrolling window’s handle, which fits the observed behavior pretty well.

If this is a bug, then stacking R10 should fix it.

This should be fairly easy to reproduce.

Assorted updates…

Raised a bug for the AutoScroll crash: https://www.riscosopen.org/tracker/tickets/509

Is anyone still having Avalanche crashes with v0.26 which aren’t related to scrolling, or dragging in the VNC window? If so I’d be interested.

I’ve almost got a v0.27 which is mostly making the error handling and exit logic more robust when the application gets killed in unexpected ways. It will also check for System$LogFile for the “Show log…” iconbar option, which makes things a bit smoother if you’re using Julie Stamp’s SysLog module.

I’ve also been playing with making the toggle size icon do something useful for scaled views. The idea currently is to have ‘Maximise’ resize the window to so the scale factor is 100%, clipping to the local screen size. ‘Minimise’ would return the window to its previous size and location. Would something like this be useful? If so, I’ll probably roll this into v0.27 to get some feedback.

The idea currently is to have ‘Maximise’ resize the window to so the scale factor is 100%, clipping to the local screen size.

I use Avalanche on a machine with a 1920 * 1280 desktop, to access a machine with a 1280 * 1024 desktop. This means that 100% scale, which provides zero display artifacts, is not quite full height, never mind full screen. Thus, what you describe would work very comfortably for me – there wouldn’t need to be any clipping.

What I don’t want it to do is make any dimension fit the screen completely, as that would be over 100%.

Released Avalanche 0.27:

https://github.com/effarig/ro_avalanche/releases/download/v0.27/avalanche.zip

This includes a change to make the toggle size button do something more useful when the view is scaled to fit the window, as outlined earlier in this thread. This seems like it should be useful, but is the sort of thing which may need a few iterations to get right, so feedback welcome.

Auto-scroll will no longer be started if the window is full size or the view is scaled to fit the window, as in those cases the window cannot scroll so it serves no useful purpose. This should reduce than chance of triggering the auto-scroll abort bug discussed above in those two cases, however I’d advise disabling the “Enable automatic scrolling” option if you don’t find it useful.

There has been quite a bit of work making handling of unexpected termination and fatal errors such as aborts more robust, and hopefully to debug in future.

If there are any crashes with 0.27 when not auto-scrolling please let me know.

0.27 working here on a RasPi with yesterday’s RO.

I like that a click on the maximise icon takes it to 100% – that’s much quicker and easier than getting to 100% by dragging the corner!

Thank you.

Using v0.27 here on a Titanium with RO v5.29 from 14th April,
connecting to vncsvr v0.22 on RPi3, both running at 1920×1080:
View settings are Full Screen unselected, Scale & Lock selected.

1. Window starts small & scaled @ 12% – fine. Toggle Size points down/left (wrong?).

2. Click on Toggle Size and window enlarges to fill screen – but with some scroll bars as it has not scaled to fit window, and it covers the task bar. Toggle Size still points down/left (ok?).

3. Click Toggle Size again and window shrinks back to small size & scaled. Toggle Size points up/right.

4. Click Toggle Size again, and window enlarges with scroll bars.
Toggle Size points down/left.

5. Click on Adjust Size & move fractionally, and scaling adjusts to fit window (96.1%). Toggle Size points up/right (wrong?).

6. Click Toggle Size again, and window enlarges with scroll bars.
Toggle Size points down/left. So back to state after 4.

So, a vast improvement, but as you say a few iterations needed.

I have also had a couple of ZeroPain errors while I have been experimenting:
Location: Offset 00032064 in module SharedCLibrary
in _kernel_default_unwind_handler +38
I can send them direct if you wish, but I will try and track down what I did to provoke them!

Thanks for the feedback. The zero pain log would be useful.

Steps 1 and 2 are bugs. I suspect the necessary code isn’t called when a new window is opened, only on the Wimp open window event. I’ll look into that.

Been meaning to make the initial size of the window larger and shift slightly for each new window in the usual way, never remember.

Step 5 is expected, as it is no longer maximised after resizing. Clicking on toggle size after this will reset it to 100% again. This only way to get back to the maximised state. “Maximised” is a bit of a misnomer, as it’s no longer maximised if you make the window bigger than 100%. This isn’t the normal behaviour of toggle size, but arguably more useful.

ZP logs emailed.

Thanks, that’s useful, though I didn’t really understand what it was about until I searched for _kernel_CallBackHandler and found https://www.riscosopen.org/forum/forums/4/topics/10737 which is very similar and references https://www.riscosopen.org/forum/forums/5/topics/273#posts-1868

Avalanche has little bit of assembler which uses R10 (sl) and R11 (fp) and isn’t in the C$$Code segment. From ZeroPain, this is what was being executed, so is very similar the scenario to described in the second link.

James, a suggestion for a useful feature.

I’d like to be able to double-click something (a URL file, or an Obey file) to launch Avalanche (if not already running) to connect to a named entry in its Hotlist. In my case:

vnc:HomeAutoGateway

Nice automatic launch without requiring to enter the password.

Should be easy…!

Two interesting bugs.

After a lot and lot of copy+paste, I can still get the error “Message protocol failed”. And I have sometimes another strange effect: local keyboard switches from AZERTY to QWERTY, and character encoding switches from Latin1 to something else. I must reboot RISC OS to get back to normal.

Second bug, funny: If there is a video running on the remote computer, Avalanche tries to render each frame, and so is late, then more late, then more and more late. After a moment, you can’t click on pause. And if you can, it will continue rendering each late frame. When you have this delay, other applications that need a screen refresh crash randomly (most of the time, DigitalCD and Messenger).

I’ve altered the assembler so it is now compliant with the SharedCLibrary rules, which I believe will fix the ZeroPain error reported by Martin. I’ve released 0.28 with this fix:

https://github.com/effarig/ro_avalanche/releases/download/v0.28/avalanche.zip

I’ve being working on improving the window handling, especially of views opened with scale-to-fit enabled. This is mostly done, but there are still a couple of quirks to iron out.

Dave Higton: I’ve added your request to the queue. There are a few things to consider: hotlist items can be renamed, which would break such links; also there is a RFC for a VNC URI scheme though I don’t know if anything actually supports it.

David Feugey:

If my understanding of the “Message protocol failed” error was correct, then I suspect there is a different problem as Avalanche no longer responds immediately to applications claiming the clipboard. There may be another bug in Avalanche, though I’m not going to be able to diagnose the issue without being able to reproduce it or getting a trace of the Wimp messages getting sent between the applications.

Regarding the local keyboard and character encoding changes seem unusual, are these happening after some other crash or error, or just on their own?

The laggy video, can occur if a lot of frame buffer updates from the VNC server get queued up in network and application buffers. Looking at the logic there, each time Avalanche receives such an update it requests another one from the server which is probably not quite correct as it doesn’t take into account when the update is actually rendered. Thanks for reporting this, I’ve added it to the queue.

I really don’t know why this is effecting other applications however.

Regarding the local keyboard and character encoding changes seem unusual, are these happening after some other crash or error, or just on their own?

Always after an error or crash.
And most of time, when “Message protocol failed” begins to appear.

The laggy video, can occur if a lot of frame buffer updates from the VNC server get queued up in network and application buffers. Looking at the logic there, each time Avalanche receives such an update it requests another one from the server.

Perhaps it should simply waits to finish the screen update before asking for another frame. On the other end, mouse movements should follow another time-laps since it’s quite difficult to resize a Raspberry Pi OS window under high load (the same with trying to highlight some text, with mouse or keyboard).

I really don’t know why this is effecting other applications however.

I believe applications crash just because they can’t do the required screen updates. DigitalCD doesn’t like this kind of congestion.

Nota: I’ll be happy to test any new version. I’m not trying to be negative here: I just use RISC OS all the day for my work, and Avalanche for heavy tasks (Teams conferences, etc.). It’s damn stable now, but still slow compared to RDPClient :)

Nota: I use Avalanche several hours a day. It’s still difficult to make drag and drop or selections under heavy load.

An option to omit frames when buffers are saturated would be nice, as some RISC OS applications tend to crash randomly each time Avalanche is saturated (for example when trying to read a YouTube video on the remote side).

It would be nice too to have an option to take control of the remote host, without seeing its desktop (with a magic key to quit the application). So I could switch the output to my Raspberry Pi OS computer and use it without using some complex USB switcher.

A recent update to Real Vncserver has knocked out any chance of a connection to Avalanche. I used the following commands:

vncserver-virtual -Authentication=VncAuth :1 -geometry 1080x1200

I now get the following error message:

Server Aborted Connection: No configured security type is supported by
3.3 VNC Viewer)

Fortunately, I found this page, which provides a solution that works.

Has anyone encountered the issue with Real Vncserver or managed to solve the connection issue?