issue-#107 views freezing
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#107 views freezing
I will be busy with documentation and icon. Can someone prepare the test? We need to make very complex view, which restore is hard for machine so it will take a half of a second to redraw it. Then you need to open it with this a bugfixed BB and with regular one and see does BB hanging up or not.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#107 views freezing
Benchmarking is still required.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#107 views freezing
What exactly is this test supposed to show?
Updating a view is the same no matter if it is done with a menu open or not
and it is always done in a delayed form, i.e. it calls Restore only once even when
Views.Update(v, ...) or Windows.dir.Update(NIL) is called twice.
If you look at ObxCubes, for example, you see that it explicitly requests an
update in Action.Do. It does it by means of sending a Msg = RECORD (Models.Message)... END
handled in HandleModelMsg and that is where Views.Update is called for that particular view.
The consequence is that Restore will be called, not immediately but delayed,
after handling the timer tick event and only if Windows.dir.Update(NIL) has been called.
It does not matter how often you call Windows.dir.Update(NIL) and this is important
because as far as I understand it, without an open menu it will now be called twice.
This is complicated stuff and I am only at the beginning of understanding it.
The good news is that luowy's fix works well and does not lead to multiple calls of Restore.
- Josef
Updating a view is the same no matter if it is done with a menu open or not
and it is always done in a delayed form, i.e. it calls Restore only once even when
Views.Update(v, ...) or Windows.dir.Update(NIL) is called twice.
If you look at ObxCubes, for example, you see that it explicitly requests an
update in Action.Do. It does it by means of sending a Msg = RECORD (Models.Message)... END
handled in HandleModelMsg and that is where Views.Update is called for that particular view.
The consequence is that Restore will be called, not immediately but delayed,
after handling the timer tick event and only if Windows.dir.Update(NIL) has been called.
It does not matter how often you call Windows.dir.Update(NIL) and this is important
because as far as I understand it, without an open menu it will now be called twice.
This is complicated stuff and I am only at the beginning of understanding it.
The good news is that luowy's fix works well and does not lead to multiple calls of Restore.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#107 views freezing
So if there is no side effects we can vote for this.
I checked with this simple module, that is does not leading to unnecessary updates.
I checked with this simple module, that is does not leading to unnecessary updates.
Code: Select all
MODULE TestFix;
IMPORT Views, Services, Log;
TYPE
Test = POINTER TO RECORD (Views.View) END;
Action = POINTER TO RECORD (Services.Action) END;
VAR
v: Test;
PROCEDURE (v: Test) Restore (f: Views.Frame; l, t, r, b: INTEGER);
BEGIN
Log.String("test"); Log.Ln;
END Restore;
PROCEDURE (a: Action) Do;
BEGIN
Views.Update(v, FALSE);
Services.DoLater(a, Services.Ticks() + Services.resolution)
END Do;
PROCEDURE Open*;
VAR a: Action;
BEGIN
NEW(v);
Views.OpenView(v);
NEW(a);
Services.DoLater(a, Services.now)
END Open;
END TestFix.Open
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#107 views freezing
Excellent minimal test.
Shows the same result as ObxCubes in my tests.
For me this fix looks fine.
- Josef
Shows the same result as ObxCubes in my tests.
For me this fix looks fine.
- Josef