SchemEd behaviour

I’ve recently been using SchemEd to draw up some circuit diagrams, and noticed an extreme slowdown of my ArmX6 when it was running. At one point I had a Reporter window open with “Commands” enabled. It showed me that while the pointer was over the SchemEd window, about 20 tasks per second were being run. This happens even while the pointer is not being moved.

It’s possible that having Reporter display this is slowing things down even more, and also possible that if not reported, the rate could be even higher.

I looked through the SchemEd directories for an obey file, but none found, so I assume the application is creating the tasks on the fly.

The slowdown is sufficient to interfere with NetFetch which eventually (possibly because of the use of Alt-break) resulted in corrupt directories, now fixed with DiscKnight. (I should mention that the machine is currently running from a hard disc, not an SSD.)

Does anyone have any thoughts on why SchemEd would be doing this? The command is being reported as “[Appl/SchemEd] Pointer 1”

I wonder if this is related to the issue that the ABC compiler is (was?) really slow on iMX6 systems?

Hi Alan,
I am not an expert of SchemEd, but yes it sounds a little weird…

So, few things comes to mind to check:

1. Does your SchemEd has configured to Automatic Saving like every second or some very small amount of time? (Menu → Choices → Automatic Saving)
2. Do you have the SimProbe set for AutoRun? ( Menu → Analysis → SimProbe → Enable AutoRun checked)
3. Not sure if something else is impacting/interacting with your SchemEd

Mine on a mini.m i.MX6 is running totally fine on RISC OS 5.27

And just for the record, if it’s anything related to ABCLibrary version, then I am using ABCLibrary 4.20 (16 Mar 2019)

Often applications will use unthrottled Idle events to track the mouse pointer when it’s in their windows to provide feedback and change mouse pointer shape appropriately. Continuous OS_CLI *Pointer 1 seems a bit daft as it should at least only issue pointer visibility / shape changes when the detected state is different. And use SWI OS_Byte 106 if it’s just turning on/off rather than using a *command. And throttle Idle events using SWI Wimp_PollIdle.

Does your SchemEd has configured to Automatic Saving like every second or some very small amount of time? (Menu → Choices → Automatic Saving)

Unticked

Do you have the SimProbe set for AutoRun? ( Menu → Analysis → SimProbe → Enable AutoRun checked)

Unticked

Do you have Reporter – if so, could you run it, make sure Commands is checked, and see what it says when you put the pointer in a SchemEd window.

Note that the slowdown doesn’t show IN SchemEd, but other things, notably NetFetch, grind to a halt. NetFetch does a regular email fetch in the background.

OK, I can see what aspect of SchemEd is involved. When placing components, the pointer is changed to a picture of the component. At this point the task changes from Pointer 1 to Pointer 0. I suspect therefore that the tasks are changing the pointer image. It seems to be doing this on null polls, which it not particularly efficient, although I don’t know whether there is another way to detect pointer position changes.
Pointer 0 turns the pointer off, so presumably at this point the pointer is being drawn by the application. However issuing the command every null poll even when the pointer hasn’t changed state and when the mouse hasn’t been moved, seems highly inefficient.
It seems to be what happens when a BASIC OSCLI command is used.
What sort of overhead is involved in running a separate task like this? Paging memory in and out?

Thankfully OS_CLI doesn’t in itself start a new task, Alan!

Thankfully OS_CLI doesn’t in itself start a new task, Alan!

So I don’t understand what Reporter is reporting.

OK, so there’s a separate option “Tasks”. That doesn’t report any activity.
“Commands” is reporting lots.

I cannot even get the SchemEd !Install from sch_108i/zip to run – it just locks up until Alt-Break. So I cannot help, apart from saying that with Command reporting on, any commands issued are reported. What commands are being shown?

What commands are being shown?

“Pointer 1” most of the time, “Pointer 0” when adding a component to the drawing. At that point the pointer is replaced by the outline of the component.

At this point the task changes from Pointer 1 to Pointer 0. I suspect therefore that the tasks are changing the pointer image.

You seem to be confusing the words “command” and “task”…

SchemEd seems to be using *Pointer to manipulate the mouse pointer shape. This appears to be legitimate, and Acorn documented it as one approach in the PRM.

The other issue is that SchemEd is doing it on Null Events. Again, enabling Null Events to track the mouse is a very valid thing to do, and is probably the only way that SchemEd can achieve the effect that it is after. The number of times that the handler is called will, to some extent, be a function of how busy the machine is: the calls go down if the machine is doing other stuff.

I’m not going to make any judgement on the way that SchemEd is coded, beyond noting that in some operating modes it does a single *Pointer call on Pointer Entering and Pointer Leaving Events, whilst in others it also seems to call it on Null Events as well. This suggests that there’s some logic to its behaviour, so without seeing what that is, I’m not going to condemn it.

Either way, I don’t see that it’s doing anything harmful. It’s certainly OK on a Titanium.

PS. This does have a feel of “seeing something in Reporter and claiming it’s bad”, as opposed to being a problem. Reporter can reveal a lot of curious things about how RISC OS works under the bonnet, but most of them aren’t wrong.

PS. This does have a feel of “seeing something in Reporter and claiming it’s bad”, as opposed to being a problem. Reporter can reveal a lot of curious things about how RISC OS works under the bonnet, but most of them aren’t wrong.

I suspect if Martin were commenting on this he would point out that, as you allude to, Reporter is a tool allowing you to see what is happening.
Judgements on whether the events you see are good, bad or just plain routine, are an analysis that Reporter isn’t expected to make.

PS. This does have a feel of “seeing something in Reporter and claiming it’s bad”, as opposed to being a problem.

It’s a case of “suddenly the machine is not behaving” at the same time as “Reporter is showing something unusual”.

The machine has been behaving, until yesterday when I started using SchemEd. It got so bad I was having to use Alt-break to regain control. By the end of the day I had a number of “broken directory” messages, and they were all related to Netfetch/Newsbase/Messenger. It seems likely therefore that one of the things I killed was NetFetch. I don’t remember for certain now.

I’ve stopped using SchemEd, and it’s back to normal. Coincidence? possibly.

Which begs the question, what else could it be. I’m now wondering whether the disc errors could be the first thing to happen, rather than the last. I was getting strange boot problems, at the point where the SSD was initialising, so I swapped (temporarily) the SSD for a spare SATA hard drive. That drive wasn’t new, but it’s been running now for ten days, while the boot problems were running at one every two days on average. So I suspect the SSD was going bad, and I now suspect the hard drive might be doing so too.

I cannot even get the SchemEd !Install from sch_108i/zip to run

That’s odd. That’s the version I am using on the ARMX6 (RO5.27), and on a pi3B with RO5.24.

Again, enabling Null Events to track the mouse is a very valid thing to do, and is probably the only way that SchemEd can achieve the effect that it is after.

I’ve been wondering about this for a while, for a utility I might make. I don’t think these days it is acceptable to sit on null events like this.

For example, try running Usage and open one of WimpInfo’s windows :-/

I’d really like a way to respond to mouse movements without doing null polling.

That’s odd.

But have you tried to run the !Install from the zip?
Even if I drag the 4 apps out of !Install.Apps, the only one to run is FontEdit – the rest lockup.

without doing null polling.

Null polling is not itself bad, it is the frequency of them. Unfortunately Wimp_Poll is often used when restricting the frequency using Wimp_PollIdle is much better – and 1/sec can still be overkill.

As Martin says, null events are sometimes necessary to allow the checking of things in the background that can’t be done any other (sensible) way.

However, the use of Wimp_Poll with null events is less acceptable. It’s possible, if everything else is idling, that your app might be called several hundred times a second. For what?

If there is something you need to keep an eye on, work out how often you actually need to check it, and use PollIdle instead. If you tell it you want null events and to come back in a fifth of a second (20cs), it will do just that and your app will run five times a second instead of potentially 500.

For what I was looking at, which I don’t remember right now, 50cs or twice a second was more than adequate.

I do hate null polling tasks begin called 10,000’s a times second on modern machines. Of course everyone should use Wimp_PollIdle, but I think sequential Wimp_Poll nulls should also be capped at 1ms intervals. Can anyone think of a valid use case for a desktop app (not a device driver) to be called more than 1000 times a second?

[I see Rick is also on the same page]

Sorry Alan, I’ve got busy…

Yes !Report reports a lot of Pointer 1 messages when you have the pointer on the SchemEd Window, that’s the NULL polling people are mentioning here.

Pointer 1 should correspond to the regular mouse pointer (aka mouse sprite on), while Pointer 0 (IF I understand SchemEd correctly) correspond to hide the pointer when on the SchemEd window and display the Circuit Diagram you have selected from the library. This is to help the user to place the circuit diagram correctly on the window.

Now if you move your mouse OUT of the SchemEd window the Pointer 1 (or pointer 0 if you have enabled a circuit diagram) messages should stop. If you had the pointer 0 then (when out of the SchemEd window) the regular mouse pointer should appear again.

Am I making sense?

Pointer messages in !Report should be every 00:00:00.02 time distance from each other.

I think Wimp_Poll should also be capped at 1ms intervals.

You’d need to ensure that it didn’t break the valid use case of looking for the first Null Event after doing something else, to indicate that the something else is done. The logic would need to cap the events at 1ms, unless there were other events in between, or something like that. Otherwise you’d need to start working out what the events are that would need to be handled correctly, and since I’m sure some are User Messages, that’s going to get messy.

I don’t think these days it is acceptable to sit on null events like this.

That’s what they’re for . The key thing is getting the timing correct, and using Wimp_PollIdle when appropriate.

Alan,
another thing worth mentioning is this: you should check how much CPU SchemEd is taking.

For example, on my minim the Pointer 1 / Pointer 0 stuff is not impacting performances at all. The rest of my minim is idle 97% when my pointer is on the SchemEd window and when it’s out it’s idle 99%.

I am also running Messenger Pro, NetFetch 5.53, a bunch of !StrongED editing some ASM code files, !NetSurf, !CubeChat and !Draw.

My NetFetch is working fine.

@Steve good point, I’ve clarified it to say “sequential Wimp_Poll nulls”.

sequential Wimp_Poll nulls

Yes, that makes sense. But even so, 1ms timing is a lot – far faster than the Archimedes would have cycled it’s apps (in the days when loads of things used null polls) and it wasn’t even possible to filter unwanted messages.
I’d be inclined to suggest that they (sequential nulls) should coincide with TickerV and happen no more than every centisecond.
Can anybody suggest a use case where that is inadequate, given that much of the underlying system (CallAfter, etc) either hangs off the centisecond tick or VSync (which is slower)? Especially given that the Wimp makes no sort of assurance regarding when it will return to your app.

[I see Rick is also on the same page]

Yes. Whizzing around paging in and running a task’s polling loop only for it to do nothing is not only pointless, it’s wasteful.
Wasteful because perhaps if the Wimp is smart and it knows that nothing needs done right now, it could not only drop to slow speed but also idle the processor.
Having a task want null polls with Wimp_Poll means there’s always something (that one app) that needs to be processed… Only for it to immediately return (but the Wimp doesn’t know that).
So, yeah, this isn’t so much being on the same page as simply finding the alternative to be incomprehensible.

“seeing something in Reporter and claiming it’s bad”, as opposed to being a problem

Hehe. One of my programs in debug mode – Manga can output so much stuff to DADebug that I don’t only have switches to include (or not) the debug core code, but I also have a number of switches to turn on what it is that I want information on.

My server currently has message debugging on. All it to show you your private mail a couple of times and DADebug’s 400K buffer will wrap around. ;-)

The amount of diagnostic information picked up doesn’t necessarily indicate that anything is actually wrong. Whether the crap I spew to DADebug or the ooooodles of stuff that can suddenly arrive in Reporter’s window. One is running a multitasking operating system with background services and such. Is it really a surprise that a lot is happening under the bonnet?

and Acorn documented it as one approach in the PRM.

Here’s an interesting one – which is more efficient, calling *Pointer or doing it via OS_Byte 106 or the OS_Word? I’m inclined to suggest the SWI call as a part of me imagines that all the command does is call the SWI…

It bugged me… https://gitlab.riscosopen.org/RiscOS/Sources/Desktop/Wimp/-/blob/master/s/Wimp01#L6258 (⚠️ huge source)