issue-#105 background task processing while mouse tracking

[Zinn]

@Helmut: do you know any details about this issue and its history?

Here there are the history from the old BlackBox mailing list:

Fair background processing

From: Marco Ciot
Date: 12. May 2006 22:37

Hi everybody

Here the changes I have made so far.
As I see they are minimal. For convenience I'm attaching the entire Files.

Remarks:
* The ASSERT 99 in HostPorts.Rider.Input is important to detect Actions calling Input.
* In TextControllers I just removed a very useless dummy call to Input.
* Services actually didn't need any changes as ActionHook.Step already skips cascaded calls.

Main Problem:
So far a Loop on Input would allow a tracking procedure to obtain the required user interaction without worry about the state of the system being changed.

As Actions might very much change the state and typically also will change the state of views or even replace views these Tracking Functions suddenly have to face some reality like "Oh, the view I just had under the mouse pointer is suddenly a different one!"

This is why I earlier said that Input should not be available at all. Instead the Tracking Messages should be handled differently. I am not 100% sure if this is possible in all cases and how big the change will be. But I guess this will be the first change I'll make to BB.

Regards
Marco

Text/Mod/Controllers
Host/Mod/Ports
System/Mod/Services


From: Alexander Iliin
Date: 24. May 2006 03:29

Hello, Marco!

MC> Here the changes I have made so far.
MC> As I see they are minimal. For convenience I'm attaching the entire Files.

MC> Remarks:
MC> * The ASSERT 99 in HostPorts.Rider.Input is important to detect Actions calling Input.
MC> * In TextControllers I just removed a very useless dummy call to Input.

Very useless indeed.

MC> * Services actually didn't need any changes as ActionHook.Step already skips cascaded calls.

For my use I replaced ASSERT with simple IF like here:

IF ~Services.ActionRunning() THEN (* ASSERT was here *)
ticks := Services.Ticks();
Services.actionHook.Step; (* mc:060325 *)
KERNEL32.Sleep(SHORT(MAX(20 - (Services.Ticks() - ticks), 0)));
END;

I did this after I discovered an Action object using Input. It was CpcControlTips.Action polling mouse coordinates in the background. I see no harm in such activity, so I just disabled the recursive call to Services.actionHook.Step and removed KERNEL32.Sleep which is unnecessary when called from an Action. So, this way Action objects may use Input as before, and the main application loop takes advantage of the patch.

MC> Main Problem:
MC> So far a Loop on Input would allow a tracking procedure to obtain the
MC> required user interaction without worry about the state of the system being changed.
MC> As Actions might very much change the state and typically also will change
MC> the state of views or even replace views these Tracking Functions suddenly
MC> have to face some reality like "Oh, the view I just had under the mouse
MC> pointer is suddenly a different one!"

MC> This is why I earlier said that Input should not be available at all.
MC> Instead the Tracking Messages should be handled differently.
MC> I am not 100% sure if this is possible in all cases and how big the change will be.
MC> But I guess this will be the first change I'll make to BB.

The Main Problem you mentioned suggests that changes should be quite big. (I thought of it before you introduced the patch, but I am just not so familiar with the framework to try to fix it.) In fact, a tracking procedure must copy and remember all information about the state of the system being changed, and then verify and update that information after every bit of tracking event. If the state in question was changed from outside the tracking procedure (like from an Action) - a decision must be made if the tracking should be aborted. Maybe some sort of mouse tracker objects need to be incorporated into the framework? Or can it be done using available hooks?

---=====---
Alexander

[Zinn]

Here Marco's changes:

(1) Text/Mod/Controllers
I set in comment the part which Marco deleted in TextController

MODULE TextControllers;

PROCEDURE FilteredPollCursor (c: StdCtrl; f: Views.Frame;
VAR msg: Controllers.PollCursorMsg; VAR done: BOOLEAN
);
VAR filter, focus: Views.View; (* x, y: INTEGER; modifiers: SET; isDown: BOOLEAN; *) fmsg: FilterPollCursorMsg;
BEGIN
FindFilter(c, f, msg.x, msg.y, filter);
IF filter # NIL THEN
(* f.Input(x, y, modifiers, isDown); *)
fmsg.x := msg.x; fmsg.y := msg.y; fmsg.cursor := msg.cursor;
fmsg.controller := c; fmsg.done := FALSE;
focus := NIL;
filter.HandleCtrlMsg(f, fmsg, focus);
IF fmsg.done THEN msg.cursor := fmsg.cursor END;
done := fmsg.done
END
END FilteredPollCursor;


(2)Host/Mod/Ports
MODULE HostPorts;
contributors = "Oberon microsystems, Marco Ciot, Alexander Iljin"
- 20060325, mc, Rider.Input changed for the benefit of background task response.

Original:
PROCEDURE (rd: Rider) Input* (OUT x, y: INTEGER; OUT modifiers: SET; OUT isDown: BOOLEAN);
VAR msg: WinApi.MSG; wnd, mw: WinApi.HANDLE; pt: WinApi.POINT; res: INTEGER; set: SET;
BEGIN
WinApi.Sleep(1);
wnd := rd.port.wnd; mw := WinApi.GetCapture();

Marco's change
PROCEDURE (rd: Rider) Input* (OUT x, y: INTEGER; OUT modifiers: SET; OUT isDown: BOOLEAN);
VAR msg: WinApi.Message; wnd, mw: WinApi.Handle; pt: WinApi.Point; res: INTEGER; set: SET;
ticks: LONGINT;
BEGIN
ASSERT(~Services.ActionRunning(), 99);
ticks := Services.Ticks();
Services.actionHook.Step; (* mc:060325 *)
KERNEL32.Sleep(SHORT(MAX(20 - (Services.Ticks() - ticks), 0)));
wnd := rd.port.wnd; mw := WinApi.GetCapture();


(3) System/Mod/Services
MODULE Services;
- 20060325, mc, ActionRunning added

Marco's change
PROCEDURE ActionRunning* (): BOOLEAN;
BEGIN
RETURN (candidates # NIL) & (trapCnt = Kernel.trapCount)
END ActionRunning;

[Zinn]

I checked them all again and my conclusion is:

(1) in Host/Mod/Ports.odc adding the line
Services.actionHook.Step;
Windows.dir.Update(NIL);
before
WinApi.Sleep(1);

(2) and in Host/Mod/Windows.odc after
Services.actionHook.Step;
append the line
Windows.dir.Update(NIL);

is enough and everything works well.
Helmut

[Zinn]

Supplement:
Should we add "The ASSERT 99 in HostPorts.Rider.Input is important to detect Actions calling Input." ?
- Helmut

[luowy]

I cannot see any delay when moving a control on a form.
The sleep is very short and it would be surprising if it can be observed
no matter if it is at the top or at the bottom.

back to 2008,dell M70,one cpu 2.0G,1G RAM,80GHDD, WinXP,the delay is obvious.

[Josef Templ]

here is a log of my conversation with Marco, should be read from bottom to top.
Overall, Marco does not really recommend this change for our release.

- Josef

Dear Josef
Yes, I am indeed experiencing a hell lot of side effects. Some of them very much wanted, though! Fact is that I can not afford interrupting the background processing but very much need user interaction, too. But fact also is that there are unwanted effects - which I guess - you would rather want to avoid in your release.

Yes I am updating windows during most kinds of mouse interactions (all in a single thread, nota bene). But you need to know that my branch of BlackBox - I call it BB 2.0 contains tons of changes and experimental concepts in actually all areas of the system. While I can easily use all of 1.6 compatible source code, documents and binaries, practically none of my stuff will work on the "older" versions of BlackBox.

I doubt, it's an advantage to integrate the change of HostPorts.Rider.Input as you describe it using the Preferences Settings. You will thus create a fork in the client software, anyway!
lm

2016-02-23 10:43 GMT+01:00 Josef Templ <josef.templ@gmail.com>:
Hi Marco,

I am asking because the BlackBox Framework Center (http://forum.blackboxframework.org/index.php) is currently working on a new BlackBox release 1.7. In the course of preparing this release we are looking at a list of previous changes collected at various places and thereby we detected this HostPorts.Rider.Input change.

The interesting point is that in BlackBox 1.6 there is a change list entry in the HostPorts header but there is no according change in the implementation of Input.
So our assumption is that this change has been removed again later by Oberon microsystems but we don't know why. Since calling actions while mouse tracking could potentially have side effects that interact in a destructive way with the mouse tracking loop this may have been the reason for removing it but we don't know exactly.

Did you ever experience any such side effects from any actions?
Would you recommend to include calling he background tasks in HostPorts.Rider.Input as part of the upcoming release 1.7?
Alternatively, we could also add an option like 'actions while mouse tracking' under Edit->Preferences.
Are you also updating all the windows as part of mouse tracking?
I mean, for example ObxCube stops rotating even when calling background tasks because the view update is delayed until the end of the mouse tracking loop. This could of course also have side effects and it may affect the responsiveness of mouse tracking.

- Josef


2016-02-22 13:23 GMT+01:00 Marco Ciot <marco@ciot.org>:
Hey Josef
I have my own branch of BlackBox in which the change is very much there, still.
The change was the first one in a long row of many changes, I made in order to make BlackBox support almost real time tasks.
According to me, the official BlackBox never reliably allowed for anything close to real time. (You can prove this with simple mouse tracking in texts or menus, leading to busy loops...)
Why in particular are you asking?
lm



2016-02-22 10:03 GMT+01:00 Josef Templ <josef.templ@gmail.com>:
Dear Marco,

at the BlackBox Framework Center we are currently looking at an old
change list entry for module HostPorts.
"20060325, mc, Rider.Input changed for the benefit of background task response."

Our understanding is that in 2006 a change has been introduced that
calls actions while mouse tracking. This change must have been removed
later because in BlackBox 1.6 there is no such feature.

Do you remember anything about this change and its history?
Why has it been removed later?

Any comment would be very much appreciated.

Thanks

- Josef

[Ivan Denisov]

Anyway HostWindows patch can be discussed.
http://forum.blackboxframework.org/view ... f=40&t=394


To help servers developers we can write some note in the BlackBox manual: "Services priority and speed". Anyway Services now runs to slow for server needs.

This is easy to check:

Code: Select all

MODULE ToolsServTest;

	IMPORT Log, Services;

	TYPE
		Action = POINTER TO RECORD (Services.Action) END;

	VAR
		time, sum: LONGINT;
		n: INTEGER;

	PROCEDURE (a: Action) Do;
	BEGIN
		IF n < 100 THEN
			sum := sum + (Services.Ticks() - time);
			time := Services.Ticks();
			INC(n);
			Services.DoLater(a, Services.now)
		ELSE
			Log.Real(sum / 100); Log.Ln
		END;
	END Do;

	PROCEDURE Test*;
	VAR a: Action;
	BEGIN
		n := 0;
		sum := 0;
		NEW(a);
		time := Services.Ticks();
		Services.DoLater(a, Services.now)
	END Test;


END ToolsServTest.

^ ToolsServTest.Test

it returns 49 ms. This is huge time for any good server app. HostMenus.Loop should be modified for server.

[Ivan Denisov]

Josef, did understand you message right way, that we will not adopt this feature? According some moderation tradition I will put this topic to rejected features for archiving and maybe further discussion.

[Josef Templ]

Sorry, I didn't have much time recently.

As a compromise I could imagine to introduce an Edit->Preferences option that
switches this background task processing on or off with the default being off.
This would then be 100% compatible with the current version and it would avoid any
possibility of a side-effect due to background task processing.
For server operation this option could be switched on but with the
potential danger of some unwanted side effects. In case of server operation the
server administrator has to live with this compromise because there is no other
solution.

(As an alternative we could also introduce a hook in Input that can be
installed by the server application and that will do the background processing.)

- Josef

[Ivan Denisov]

Implementing Hook in Host subsystem will be strange, because it is the place for the realization, not for abstraction.

Growing Preferences is not the good option, however this will allow to make more easier debugging in the Beta stage. So I will vote for such option.

Previously I had thought that better to make some documentation for Host modification. Now I understand that we did not make good testing to suggest such solutions. The only way to make such testing is to include this option now and to evaluate this in Beta.