PrivateEye 3.20 ready for testing

Hi all,

PrivateEye 3.20 has had some updates and is now ready for its trial by fire. Here’s what’s changed since 3.14:

Changes

• The user guide has been converted into StrongHelp format and incorporated into the app itself. The icon bar menu gains a “Help” menu entry to open it.
• RISC OS 5.21’s extended format sprites are now used where possible, e.g. when loading PNGs containing alpha channels. This avoids the need to use the Tinct module which, while having provided great service for many years, has become problematic due to being unmaintained.
• When in “Fit to screen” mode viewers now draw a paper document style backdrop behind images. Its redraw is optimised to avoid flicker where possible.
• A “Format” field was added to the image info window. This shows the screen mode of the display sprite and which OS versions it’s compatible with.
• Image info window’s “Colours” field now shows when CMYK format sprites are detected.
• Image info window’s “Dimensions” field shows centimetres in addition to inches.
• The checkerboard drawing code, used to indicate alpha transparency, was hoisted out of the viewer code (will use less memory). It now uses the PlotTiledSprite SpriteOp where available, in preference to Tinct’s equivalent.
• The icon bar’s height is now read from the OS rather than being assumed. Just in case it ever changes.
• The Sprite alpha channel detector now treats “all 0” and “all 255” values as indicating no alpha.
• Alpha channels and Alpha masks are now distinguished in the image info window. Note on terminology: “Alpha channels” are where the alpha data is inline amongst the pixels, as Tinct and various software uses. “Alpha masks” are where the alpha data stored separately in the mask bytes: the newer standard that RISC OS Select established. It’s theoretically possible, but meaningless, to have both in the same sprite.

Fixes

• Fix: Edits performed in “Fit to screen” will now refresh just the image area, not the whole window.
• Fix: Zoom-to-point (Shift-Click) now works correctly when in “Fit to screen” mode.
• Fix: Scale > Fit to screen now respects the cover icon bar flag.
• Fix: Sprites which error when rendering will now, like JPEGs, draw the error message to the viewer window rather than causing a crash.

If you’re feeling adventurous there’s a full summary and zip download at <https://github.com/dpt/PrivateEye/releases/privateeye-3.20>. Known issues and feature requests are at <https://github.com/dpt/PrivateEye/issues> if you spot a problem, let me know in this thread.

Regards,
Dave

Hi Dave – looks like another tasty update.

Haven’t had a chance to try it yet, but you’ve reminded me that I should have reported a previous-version bug, and never got round to it.

On systems that use software mouse pointer (I think some situations on Pi, also on Pinebook and >1080p on iMX6 to name a few) the rectangle bounding the pointer is displayed as a solid coloured rectangle (not immediately fixable by redraw IIRC) on the image when it is first shown. If memory serves, there’s a sync call that is best done around your redraw code if you’re plotting direct to screen, to avoid this kind of problem. Jeffrey Lee would know best, as I think he was the one who mentioned it when Zap/StrongEd had issues. I am struggling to find the right forum thread where this is discussed, I’m sorry. Just spent about 10 mins looking, but my google-fu is letting me down.

Hmm, I’m not doing any direct screen access, but Tinct is. Hopefully this new build will dodge the issue since it avoids Tinct where possible.

Was the hide-the-pointer magic folded into OS_RemoveCursors & co.? I was thinking the ArtWorks modules might not have been updated for it.

Excellent improvements – thanks David.

Some feedback…

1. Can the !Help file be changed to an obey containing something like…
IF "<Alias$@RunType_3d6>"="" THEN ERROR The PrivateEye Help file is now in StrongHelp format, but StrongHelp has not yet been seen by the filer.
Filer_Run <Obey$Dir>.Resources.Help
This will allow the Help to be opened directly from the Filer menu.

2. If the Viewer Cache size is set to 200704 KBytes, and lots of jpegs viewed, then when the PrivateEye dynamic area has grown to about 129528K an error is raised There is not enough memory to perform the requested operation. Quit any unwanted applications or see the RISC OS User Guide for ways to maximise memory.
Any further attempts to display a jpeg give the same error.
I suspect the maximum for the area is set at 128MB, and it is that causing the error.
Could the max be higher, and Choices set to limit at that level?

This is the first time that I use PrivateEye, and I’m pretty impressed! However, there’s a nasty bug on my setup: adding an effect freezes the computer. The buttons on the error box can’t be clicked and a reset is needed to regain control. This is on a Pi4, with RISC OS 5.29.

Martin: (1) Will do. (2) Yes, the cache code isn’t taking into account the maximum DA size. I’ll look at fixing that now.

Paul: That’s strange. What error box do you see? Does it happen with small images and large images alike?

Nice job David! Thanks a lot :)

The buttons on the error box can’t be clicked and a reset is needed to regain control. This is on a Pi4, with RISC OS 5.29.

That’s strange. What error box do you see?

*where &FC1FDD88
Address &FC1FDD88 is at offset &00000354 in module 'DragAnObject'
*

There is no such issue on RPCEmu, OS5.29 or OS4.39, effects apply as expected.

DragAnObject is the same on both OS5.29 instances above, 0.09 (04 Aug 2011)

The Titanium stiffs completely

Strange. On this Titanium with RO5.29 (20 Oct 2022) if I view a 51M sprite (converted from jpeg) I get an error There is not enough memory to pergorm... if I try to open Effects. And I have set my cache back to zero (see above!).

I get a similar error as djp when adding an effect, albeit with a different address. However, it resolves to exactly the same offset in module ‘DragAnObject’.

So it’s the drag of the effect icon itself? OK. I can see if I’m doing something daft in that area.

The effects require two additional bitmaps of the same size of the original image, so a 51M sprite might need another 102M of dynamic area to open up the effects window. If your system is clamping DAs to a max of 128M, for example, PE won’t be able to comply.

When I get the time/inclination I’ll have a look to see why using the WimpSlot for all memory was being unstable.

So it’s the drag of the effect icon itself?

It is the step before that, it errors immediately on clicking on the effect, it does not get as far a allowing the actual drag to be started.

I’ll just drop this download link here for those using NetSurf. ;-)

+1 to what djp says. The moment I click on an effect, the program dies. Doing a postmorten stiffed the machine solid. As above, offset +&354 in DragAnObject.

Are you being called back in SVC mode by mistake? If I remember correctly there’s some weirdness about getting the right mode returned.

The machine is an ARMv7 (original) Pi 2 with RISC OS 5.29 (4th September).

Repro’d on latest 5.29. 5.28 doesn’t show a problem.

I’ll just drop this download link here for those using NetSurf.

Thanks, Rick!

5.28 doesn’t show a problem

Confirmed here, this is apparently odd as DragAnObject is at the same version.

From my collection of Titanium ROMs the last working OS5.29 was 09Jan21. PrivateEye 3.20 does not even start with ROMs of 24Jan21 and 26Jan21, “Filing system or path PrivateEyeRes: not present”. It does start with 31Jan21 but with the Effects crash well and truly present.

If I remove draganobject_FUNCTION_USE_USER (bit 18) then the crash stops, but’s that’s wrong…

I suspect it’s something in the OS. Ideally I want to see what changes happened in the OS between those 09Jan21 and 31Jan21 builds.

I see that Browse is also a user-land user of DragAnObject. Are there 32-bit builds of that available anywhere?

PrivateEye 3.20 does not even start with ROMs of 24Jan21 and 26Jan21, “Filing system or path PrivateEyeRes: not present”.

That issue was due to an errant short lived change in FileSwitch as described here It can be avoided by using an updated ResFind as found in StrongED. The ROM of 24Jan21 does have the PrivateEye crash.

To see what the differences in the two ROM the output from Verma can be diff-ed.

--- ADFS::Titan4.$.Work.ROOL.Machines.Vers-Dev-t.210109	2022-11-02 14:20:24.0 +0000
+++ ADFS::Titan4.$.Work.ROOL.Machines.Vers-Dev-t.210124	2022-11-02 14:20:24.0 +0000
@@ -2,3 +2,3 @@
 Version number: RISC OS 5.29
-Build date    : Sat,09 Jan 2021.04:58:19
+Build date    : Sun,24 Jan 2021.04:58:28
 *
@@ -7,5 +7,5 @@
   ----- ----- ---------- ---------------------- -------------------- ----
-  0     0     Active     UtilityModule          5.29 (19 Dec 2020)    Y
+  0     0     Active     UtilityModule          5.29 (23 Jan 2021)    Y
   1     1     Active     PCI                    0.19 (29 Aug 2020)    Y
-  2     2     Active     FileSwitch             2.87 (12 Oct 2019)    Y
+  2     2     Active     FileSwitch             2.88 (23 Jan 2021)    Y
   3     3     Active     ResourceFS             0.26 (18 Aug 2016)    Y
@@ -107,3 +107,3 @@
   92    88    Active     DrawFile               1.60 (13 May 2020)    Y
-  93    89    Active     BootCommands           1.49 (02 Aug 2015)    Y
+  93    89    Active     BootCommands           1.50 (23 Jan 2021)    Y
   94    90    Active     WindowScroll           0.02 (29 Apr 2020)    Y

BootCommands and FileSwitch can be ruled out with builds of the current OS5.29 with the older known good versions inserted. There is a difference in the Utility module not yet identified.

There is a difference in the Utility module not yet identified.

That’s a red herring, isn’t it? IIRC the Utility Module exists primarily to enumerate the RISC OS version number.

You may want to concentrate on Kernel changes. According to my notes:

Kernel 6.48 (16 Jan 2021) had Make supervisor stack inaccessible to user mode plus 4 other commits.

Kernel 6.49 (23 Jan 2021) had Preserve LR and CPSR in DebugTX

Kernel 6.50 (30 Jan 2021) had Expose ABTSTK via OS_ReadSysInfo 6 plus 2 other commits.

I see that Browse is also a user-land user of DragAnObject. Are there 32-bit builds of that available anywhere?

I don’t think so. And there isn’t going to be one here either :-

Errors in :†ADFS::ROOL.$._ROOL.Browse.h.Menus
    33 S #include file <HTMLLib/HTMLLib.h> wouldn't open

That header is nowhere to be seen.

Are there 32-bit builds of that available anywhere?

Attached to this post when I remember to update it.

#include file <HTMLLib/HTMLLib.h> wouldn’t open

That’s generated during the exports phase of HTMLLib (from api.h).