#79 Interface response lag - issue with repaint ?

[Mario De Weerd]

Hi

A Mac User reported that on his machine the user interface reacts in a lagged way. Version 5.72 of the environment is used (the pure java version of course).

After looking in the code, I found this in the Check class:

------------- snippet start -----------------
/** Called by the system to pass events to the check control. */
public void onEvent(Event event)
{
if (event.target != this) return;
switch (event.type)
{
case KeyEvent.ACTION_KEY_PRESS: // guich@550_15
checked = !checked;
repaintNow();
postEvent(new ControlEvent(ControlEvent.PRESSED, this));
break;
case PenEvent.PEN_DOWN:
checked = !checked;
repaint();
PenEvent pe = (PenEvent)event;
if (0 <= pe.x && pe.x < width && 0 <= pe.y && pe.y < height)
postEvent(new ControlEvent(ControlEvent.PRESSED, this));
break;
}
}
------------- snippet end -----------------

I do not under stand the reason for the difference - one says repaint and the other says repaintNow.
Anyway, the problem clearly is with repaint, working perfectly on windows (also the same pure java version).

The comment for repaint (Control class) says:
/** Marks the control for repaint. Important note: when you call repaint, the absolute
* area of the control regarding its parent Window is invalidated (marked
* for repaint); then, the next time a event (a keypress, a timer, a pen event)
* occurs, the screen is updated. If you call repaint and the control isn't
* effectively repainted, you have 2 choices: call Window._doPaint(), or,
* use Control.repaintNow.
*/

From which I assume that other events should result in a control update. I've looked throught the environment code, but I could not find code assuring that a repaint really happens on a Timer event for example.

As the behaviour on Windows, Linux and Mac is different, I suspect a (Super)Waba bug somehow. I leave it up to you to determine that. If you indicate where the repaint is actually supposed to happen, I'll have a look myself at the code.

[Mario De Weerd]

Logged In: YES
user_id=149951
Originator: YES

More info.
I finally found where the regular update is done - in the Window class:
if (topMost.needsPaint) // guich@200b4_18: maybe the current event had poped up a Window.
_doPaint();

I called 'validate' of the mainwindow explitally on regular intervals, but it does not seem to help.

[Mario De Weerd]

Logged In: YES
user_id=149951
Originator: YES

Calling _doPaint on regular time intervals (55ms) in the MainWindow class solves the problem on a Mac machine but introduces flicker for popups.

[Guilherme C. Hazan]

Logged In: YES
user_id=180823
Originator: NO

Hi,

Unfortunately, there are no Macs nearby. Have you tried to change the installed JDK? Or maybe checked the faq, there's an entry about Mac OS there.
regards

guich

[Mario De Weerd]

Logged In: YES
user_id=149951
Originator: YES

I do not have a Mac either.
I've been able to solve the effects of the issue by adding this in my MainWindow's event handling method:

case ControlEvent.TIMER:
if ((topMost==this)&&m_settings.isSolveMacLagProblem() && event.target==this) {
this._doPaint();
}
break;

and of course on startup:

addTimer(this, 55);