Mouse in need of viagra?

With the latest d/loads (19th ROM/ 20th disc) my mouse pointer seems to have shrunk lots. I’m fairly sure it’s not my imagination… though it’s possible.

BB -xm, X1024 Y768 C16M EX1 EY1 F60

[Edit]
OK, not imagination. It seems to be related to the absence of Resources:Configure.Sprites22.

In !Boot.Backup.Resources.Configure I have !Inetsetup ClrMonitor Monitors Sprites & Sprites22.

In Resources:Configure I now have !InetSetup 2DTools ClrMonitor FontChange Monitors & Textures. Correct?

If I ‘IconSprites !Boot.Backup.Resources.Configure.Sprites22’ I get a normal size pointer back.

The ‘hand’ & ‘hourglass’ pointers are unaffected. As a temporary fix I’m loading ptr_default & ptr_double from a sprite file I keep in PreDesk.

my mouse pointer seems to have shrunk lots

Sounds like I’ve fluffed up the merging of sprites files and have copied an EX2/EY2 mouse pointer into the EX1/EY1 file. Does “*SHOW Wimp$IconTheme” show “Sovereign.” for you?

The files in Resources:Configure sound right, the Sprites/Sprites22 files in there did nothing but slow the boot sequence down a bit (because they duplicated those that got loaded into ResourceFS). Similarly the “NewLook” and “!+Resource” obey files should now be absent from Choices:Boot.PreDesk.

Does “*SHOW Wimp$IconTheme” show “Sovereign.” for you?

Yes, it does.

Similarly the “NewLook” and “!+Resource” obey files should now be absent from Choices:Boot.Tasks.

Do you mean Choices:Boot.PreDesk?

Whilst looking at the above I’ve been trampling through the rest of my !Boot. I’ve come across the following items which differ from the latest disc image & I think I may need to alter.

Is PreDesk.~SetupMimeMap redundant?

Is Resources:!+Resource redundant?

This may not be related, but after building a disc image from some sources I grabbed late last night, I get an abort on data transfer at line 596 of ResourceFS.s.ResourceFS, while ThemeDefs is running. This is running on a Raspberry Pi, with Wimp$IconTheme as “Sovereign.”

I can’t give you a register dump or much more useful information, as *showregs triggers the abort again, followed by “recursion in messagetrans” errors on subsequent attempts.

On subsequent attempts it boots fine, although after leaving the machine idle on the post-shutdown screen for a couple of minutes I got an abort in the heap manager due to what I guess is RMA corruption.

I’m still getting the shutdown abort after reverting to my previous disc image (which is at least a year old, so predates Sprow’s tweaking). I guess I’m on my own for tracking down this one.

Looking into this a bit, the problem is that at the point the *ICONSPRITES command is done you are in a low res mode so the low res mouse pointer is loaded which then gets shrunk on a mode change. It’s the opposite of the problem of switching into a EX0 EY0 mode and getting a clipped mouse pointer bottom. The hourglass is right, so it could be something that the Wimp forgets to rescale.
To mask the problem, in !Configure choose “Protect ROM sprites”, this will force the theme loader to put all 3 resolution variants into ResourceFS so the Wimp will pick them up correctly on mode change. I’ll have a think about a better solution.

Do you mean Choices:Boot.PreDesk?

Ah, yes – I was going from memory, original post corrected.

Is PreDesk.~SetupMimeMap & Resources:!+Resource redundant?

Yes. I think you asked the same question a few days ago?

On subsequent attempts it boots fine, although after leaving the machine idle on the post-shutdown screen for a couple of minutes I got an abort in the heap manager due to what I guess is RMA corruption.

Hmm, the theme loader doesn’t use RMA, it loads stuff into a dynamic area (for RISC OS 3.50+).

Yes. I think you asked the same question a few days ago?

So I did. Obviously then moved on oblivious.

I’ll have a think about a better solution.

OK, the mouse should be back to normal when ‘Protect ROM sprites’ isn’t selected (with the overnight auto build).
The bug in !ThemeDefs exposed 2 extra problems

• The Wimp doesn’t try to rescale the pointer if it doesn’t have the right one for the current mode, leading to a cropped pointer in EX0 EY0 modes if an EX1 EY1 pointer is in use
• The kernel’s merge sprite file function gets very slow very quickly because it does delete/compact/append for each individual sprite, in the case of the mammouth 350+ sprites in the bonus disc resources (approx 2MB) this results in 700MB of data being shifted around in the merge

Two more things for someone to do…

The kernel’s merge sprite file function gets very slow very quickly because it does delete/compact/append for each individual sprite, in the case of the mammouth 350+ sprites in the bonus disc resources (approx 2MB) this results in 700MB of data being shifted around in the merge

How slow is “very slow”? I did notice that the new boot sequence took longer (around 5-10 seconds before the predesk screen output starts?), but wasn’t sure if I was just imagining it or if other factors were at work (e.g. USB stick being a bit slow to start up).

With regards to the memory corruption I found, it looks like it could be that either EtherUSB or the USB drivers are writing to one of the data buffers after they’ve been freed. But I haven’t got as far as adding/enabling logging to confirm that’s the case. Two of the three stack dumps I’ve got were from inside the internet module, while apparently deleting a route, so that does reinforce the idea that it’s something network related. Hopefully I’ll kill two birds with one stone and find that this memory corruption is the cause of the recent ShareFS problems.

but wasn’t sure if I was just imagining it

No it is definitely over 10s slower, leaving the ‘No keyboard – autobooting’ message there for some time before anything appears to happen.

How slow is “very slow”?

The bug I fixed a few hours ago in the theme loader meant it was loading the data 3 times over (oops) for good measure. My test machine (due to desktop space I only have one at a time) is an A7000 and that took 3 mins 15 secs to needlessly shovel around 2100MB of sprite data.

With some optimisation the kernel really only needs to move 2MB around (a factor 1000 speedup in this rather exceptional corner case!).

OK, I’ll try getting latest and seeing how bad it is now that it’s not loading things three times over. If it’s down to only a second or two then we probably don’t have to worry about fixing it in time for the Pi release.

If it’s down to only a second or two then we probably don’t have to worry about fixing it in time for the Pi release.

In the ‘Protect ROM sprites’ mode (using the Window setup plugin) it’s as fast as however fast loading the sprites into a dynamic area is (so, for Sovereign that’s about 4.9MB of sprites).
When deselected (don’t protect ROM sprites), it’s the time to load ~2MB with 350ish sprites plus the speed of the kernel shuffling 700MB of data around.

For RPi, the disc image could simply insert “*Set ThemeDefs$Disabled 1” and rely on the ROM copy.

When deselected (don’t protect ROM sprites), it’s the time to load ~2MB with 350ish sprites plus the speed of the kernel shuffling 700MB of data around.

This seemed to take about a second, so certainly isn’t anything we need to worry about at the moment.

This may not be related, but after building a disc image from some sources I grabbed late last night, I get an abort on data transfer at line 596 of ResourceFS.s.ResourceFS, while ThemeDefs is running. This is running on a Raspberry Pi, with Wimp$IconTheme as “Sovereign.”

I believe I’ve fixed this; although you were being careful to allocate enough space for terminating the resource FS block, you weren’t putting the terminator in place, so it was pot luck whether the block would be terminated or not.

you weren’t putting the terminator in place

I was at some point in history triggered off src="" at the end of the DATA table. But when I made that conditional on FNintoresfs() that code never gets called. Good catch sir!