Draw file locking Rpi

I have a draw file that totally locks my RPi model B.
The drawfile is produced by combining two drawfile graphs created in !Tau using !ProCAD and exporting as a drawfile.
Symptons are that the drawfile partially renders on screen and then stops with no mouse pointer movement. The only way to recover that I have found is to restart the RPi. The same drawfile will load back into !ProCAD without problem.

The same drawfile renders without problem in ROsix running on VRPC.

With the drawfile as a figure in !Techwiter scrolling the figure into view will work if only a portion of the figure is visible, too much and the RPi locks up.

Using 5.21 17 Feb 2014 draw version 1.26 9/8/14

Softloading the RO6 version of draw (2.44 03/12/2009) onto the Pi and the Pi still locks up.

Any ideas please

Gwyn

What happends if you load it into ArtWorks?

Sorry but I can’t test since I don’t have a copy of Artworks

I think there’s a read-only copy of ArtWorks in the base Pi image.

Free ArtWorks viewer

Thanks for the suggestion. I did have the AWviewer, but this (as far as I can tell) doesn’t import draw files

I did have the AWviewer, but this (as far as I can tell) doesn’t import draw files

Well spotted, so it doesn’t. NetSurf can render DrawFiles though.

Added And so does PrivateEye

To really diagnose the problem with !Draw an example needs posting somewhere.

David

Offending file now available Drawfile

Update Renders in Netsurf without problem, Pi locks up when loaded into PrivateEye after about 50% loaded.

Note much quicker rendering in PrivateEye than Draw

Offending file now available Drawfile

Well that certainly stiffed my Pi (5.23)!

Will load into NetSurf OK.

John

Thanks for confirming that it not just my setup

Well that certainly stiffed my Pi (5.23)!

It certainly didn’t stiff my Pi (5.23)! That’s a Mk3 Pi OS5.23 (19-Jun-16).

It also didn’t stiff the Titanium nor did it stiff RPCEmu with OS5.17 (19-Jan-10) or OS5.19 (05-May-13).

P.S. It also didn’t stiff a Mk1 Pi (5.23).

So there must be something else involved.
help modules shows
Drawing module 1.21 5 Aug 2011
Drawfile 1.58 22 July 2013
!Draw 1.26 9 Aug 2014

Think it’s time to make a new sd card with 5.23

Drawing module 1.21 5 Aug 2011

What is that? I don’t have that at all. Try kicking it out.

I don’t have either Tau or ProCad.

It also loads ok into Draw on an ARMx6.

Draw 1.28
Drawfile 1.58

Drawing module 1.21 5 Aug 2011
Drawfile 1.58 22 July 2013
!Draw 1.26 9 Aug 2014

My 5.23 is the last one without the ZeroPain implementation dated 02 Jul 2015.

If I kill the “Drawing” module, Draw 1.21 (05 Aug 2011), then the Draw application won’t work at all!

My !Draw is 1.27 (24-Mar-15).

Drawing module 1.21 5 Aug 2011

Brain slippage, “Drawing module” is the Draw modules help.

*help Draw
==> Help on keyword Draw
Module is: Drawing Module  1.22 (08 May 2016)
*

GDraw 3.12 is part of the current ArtWorks viewer 2.16 and the test file still works in its presence.

!Draw is 1.29 (02-May-16) here, OS5.23 (19-Jun-16)

OK Tried with a fresh download of RC 14 and the RPi still stiffs
Downloaded the latest ROM 5.23 23 June 2016 and machine stiffs

Drawfile version 1.58 27 July 2013
Draw version 1.29 2 May 2016
Drawing module 1.22 8 May 2016

Now I am confused

Are you loading any add on to !Draw?
Have you tried !Draw+?

Hangs with clean install of 5.23 on new SDccard with RC14. Only extra file is the offending draw file
Pi has label with E2112RSV1.0B1.1 on it

Not tried !Draw+

To follow my own post

Drawplus (well OpenVector) file stiffs machine

ProCAD+ 1.06b file stiffs machine and with CAD type file

ProCAD+ 1.08 file Does not dtiff machine.

Can’t see anything obvious on David Snells website in the changes section to identify why

I wonder if you could ask someone who can load the file successfully to resave it and send it back to you.

If the result loads on your m/c, then that might indicate something, tho’ what I couldn’t say.

But it looks as though you’ve identified the cause.

Do you have SpecialFX installed and activated?

Steffen you are a genius

Removed SpecialFX from !Boot.Resources and rebooted. Now the offending draw file loads without problem and redraws much faster.

Never taken any notice of SpecialFX what is it for?

According to http://www.riscos.info/index.php/SpecialFX :

• It allows any programs that use vector graphics in their windows (i.e. drawn items rather than bitmap graphics) to enhance the appearance of those graphics by anti-aliasing them;

• It allows all applications that use outline fonts to improve the appearance of text by blending the characters’ edges to the underlying screen contents (useful if the text background is multicoloured), rather than using the more traditional ‘single-colour background to single-colour foreground’ anti-aliasing of RISC OS fonts;

• It cures a particular printing problem experienced by users of certain types of printer, most notably for Calligraph direct-drive laser printers.

I suspect it might do the first thing by redirecting all Draw operations to GDraw. There was a utility that did this back in the 26 bit days, I just kind of assumed that SpecialFX does the same sort of thing.

More details at https://web.archive.org/web/20081015204721/http://www.hallas.demon.co.uk/Software/SFX/