New RiscOSM version released

A few days ago we released an update to RiscOSM (the OpenStreetMap based map software for RISC OS). Main changes are the ability to export maps directly as PNG and JPEG, building on the release of the CompressPNG module, and a speed improvement of around 10% on newer computers, thanks to Stuart Swales’ work on supporting VFP for applications compiled using the Norcroft compiler.

There are various bug fixes as well. You can read the full details on the version history page

The speed increase is noticable – after a brief test the time to load and draw a 1:12,500 map of London is reduced from about 14 seconds to about 9 on this Titanium – I suspect mostly in the drawing phase.
Thanks for the update!

and a speed improvement of around 10% on newer computers, thanks to Stuart Swales’ work on supporting VFP

Drawing map of Gaydon at 20000 scale:

ARMX6 RiscOSM 2.02 67 seconds
ARMX6 RiscOSM 2.04 67 seconds

Pi3B+ RiscOSM 2.02 10 seconds
Pi3B+ RiscOSM 2.04 08 seconds

Shows that ARMX6 is not one of the newer computers.

We need to prod some vendors (are you listening?) into updating their VFPSupport modules:

to at least 0.16 (28 Jun 2021) [which adds elementary function acceleration using VFP:
https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/VFPSupport/-/commit/0dfe15e56d19d40d82a00d696601c889ac7350c4]

and ideally to 0.17 (03 Nov 2021) [pow bug fix with NaNs:
https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/VFPSupport/-/commit/c6391c0d0fed212e5be951b1c76c6b0b7989d7cc].

It’s not just RiscOSM that benefits from newer VFPSupport, BASIC VI VFP does too:
https://www.riscosopen.org/news/articles/2021/07/10/going-round-in-circles-quickly

So ARMX6, RISCOS 5.29 (3rd Nov 2020) , VFPSupport 0.13 (20 Feb 2018).

RiscOSM 2.04
Map of Gaydon 1:20000.
Default style
Screen 1920 × 1080

4 seconds.

Clearly some ARMX6’s aren’t the same :-)

Clearly some ARMX6’s aren’t the same :-)

Indeed not: https://www.riscosopen.org/forum/forums/1/topics/12448

Thanks for the reminder Stuart as I forgot to mention I had that installed as I made the classic assumption every RComp ARMX6 owner would have it and I also forgot it was a purchable addition.

We need to prod some vendors (are you listening) into updating their VFPSupport modules to 0.16 (ideally 0.17).

As Stuart suggests, the speed improvements depend on the VFPSupport module being up to date. We did our testing on a Raspberry Pi 3 using a recent nightly build.

Clearly some ARMX6’s aren’t the same :-)

Clearly not! but I do have the turbo graphics enabled (IMXGC320 1.30) and the OS is at the same level so there must be some other explanation as to why Doug’s ARMX6 is 16 times faster than mine.
VFPSupport is 0.13 (20 Feb 2020)

From where can we obtain the newer VFPSupport module? Currently I also have version 0.13

Gaydon seems to have become the new default testing site for RiscOSM, so I thought I’d have a go on a standard Pi4 running 5.28 stable release:

RiscOSM 2.04
Map of Gaydon 1:20000.
Default style
Screen 1920 × 1080

approx. 1 sec.

NB: although the screen is as above, the map initially displays as a 271 × 184mm oblong at 100%, which is the default setting, i.e. not full-screen. I assume this is similar to the tests described in earlier posts? Extending the map to full-screen takes about another second.

From where can we obtain the newer VFPSupport module? Currently I also have version 0.13

It appears to up-to-date be in the nightly Ti & Pi ROMs. I have a standalone soft-load one built for ARMX6 which I have used for testing, but don’t want to tread on anyone’s toes!

Thought I would try running RiscOSM on the Gaydon map with a clean start. The ARMX6 runs 24/7 and has not been restarted since I don’t remember when.
After reboot the map took under 3 seconds to finish.
Why it previously consistently took over a minute is difficult to fathom – perhaps there was not much free RAM left.
(@George – the map initially displays as a 271 × 184mm oblong at 100% – yes same as mine)

The 4te (Pi 4B) takes about 2s to display Gaydon 1:20000, RiscOSM 2.04 VFP (26-Oct-2021), RISC OS 5.29 (19-Feb-2021) with VFP Support 0.13 (28-Feb-2018) and April 2021 map data.

Gaydon is not a brilliant example for benchmarking because it has very little detail to render! For most systems it will only be a few seconds: even our old Iyonix does it in 15.

People wanting to make comparisons need to consider whether you have contour data being loaded and rendered: that will make a difference. Loading the data can also be slower if you have a lot of datasets of different countries available. If the area you are drawing overlaps with a crude bounding box for the dataset (bounded by lines of latitude to the north and south and longitude to the west and east) then the dataset will need to be scanned to determine if there is data to load. For this reason it is useful to look at the detailed timings (use F5 to open the window) which break down the selection process, loading data, rendering etc.

I’m not sure why a machine which has been running a very long time would be so much slower at drawing a map. I think someone has reported that before. We’ve never experienced this as we turn our computers off when not in use.

By the way, RiscOSM version 2.05 is now available, fixing an embarrassing bug with the new PNG and JPEG export: the files were ending up as big as a sprite, but with nulls padding out the end of them!

People wanting to make comparisons need to consider whether you have contour data being loaded and rendered:

True, it’s a bit short of contours until you get down to Edge Hill, but there’s plenty of small scale artificial contours and railways tracks in that same south-westerly line down to Edge Hill

I have just run a URL file containing
geo:54.374760,-2.998790;scale=50000
which is an area of the Lake District (lots of contours!) and from F5 the time taken just to draw was:
v2.02 Map 4s Contours 11s
v2.05 Map 2s Contours 2s
A very worthwhile improvement there!

I’m not sure why a machine which has been running a very long time would be so much slower

Because RiscOSM multitasks while processing the map, it is very sensitive to any other tasks that are null polling. E.g. just having ArtWorks sitting on the iconbar can make the rendering take twice as long :-( (really should raise this with MW)

If you have Iris running I imagine the impact would be huge!

just having ArtWorks sitting on the iconbar

Yes indeed, ArtWorks is a CPU hog even when idle. !Usage gives a useful overview of which app is using what.

Because RiscOSM multitasks while processing the map, it is very sensitive to any other tasks that are null polling.

Might help not to yield too often – when recalculating, which is done on null events, Fireworkz runs through work until at least a centisecond has elapsed before polling again.

Might be reasonable to yield less frequently if your app has focus, but more frequently if the user is trying to make use of another app…

With ArtWorks, Otter Browser and Iris all running on a Rpi400 @2.4GHz RiscOSM takes about 3 times longer to render. Desktop is still responsive.

With just one running the difference in times is barely noticable.

From where can we obtain the newer VFPSupport module? Currently I also have version 0.13

Please have a look at the ‘FP support’ thread: https://www.riscosopen.org/forum/forums/2/topics/3457

Would it be possible to do a version for Emulators RiscPC etc instead of using the FPEm module?

Would it be possible to do a version for Emulators RiscPC etc instead of using the FPEm module?

Perhaps best to continue the non-RiscOSM points over on the ‘FP support’ thread at this point: https://www.riscosopen.org/forum/forums/2/topics/3457?page=11#posts-128439 .

Also Colin, if you were thinking of the possibility of a non-FPE, non-VFP RiscOSM, see my points there.