17919 - plevent queue priority is now too low

Status: VERIFIED FIXED

(Core :: XUL, defect, P2)

Description

[Colin Blake]

I entered the following into n.p.m.unix today. Now that I understand what's
going on, I think its worthy of a bug report. Its certainly a blocker for
M11 on OpenVMS.

-----------------------

I'm seeing a strange timing problem on OpenVMS that hopefully someone
will recognize.

Whatever the problem is, it started with the M11 code (M10 worked just
fine). The M11 code I have is a few days old now; I pulled it last
Thursday/Friday. Here's what's happening.

I start apprunner and the window comes up but the contents aren't
displayed. Nothing is displayed UNTIL I move the mouse, then it
displays. Same is true when I click on a link. The page appears to
download but it doesn't display until I wiggle the mouse.

I've put some debugging in and I can see that when its "stuck," there's
about 40-50 events on the event queue, but the main gtk loop isn't
waiting on the event queue fd. I'm not sure what is running but I can
see select getting called about 10 times a second, but like I said, the
event queue fd is not in the fd set.

What is gtk (or whatever) doing that's preventing the usual gtk idle
loop from running (which would select on the event queue fd and see all
the work its got to do)?

And why does generating a X event (mouse or key) give things a nudge and
get everything moving again?

Does any of this sound familiar to anyone?

Colin.

-------------

Here's what I've found out.

The event queue entry is sat in GTK's internal queue with a priority of 200.
It never gets to run because there's always a element in the queue with a
priority of 120 that keeps pre-empting it. The 120 (GTK_PRIORITY_REDRAW)
element is put there by gtk_widget_queue_draw_data when it calls
gtk_idle_add_priority.

I believe this used to work in M10 because edit 1.54 in
widget/src/gtk/nsAppShell.cpp (made on October 21) LOWERED the priority of
the event queue. The checkin comment for 1.54 is "fixed up prioritization of
the plevent queue so that it's lower than the normal priority".

So something (the continual redrawing of the animated "loading" graphic?) is
causing the event queue to never get serviced. How come no-one else is
seeing this? Perhaps my graphics sub-system is slower than most and so
exposes this problem?

HELP!!!

Comment 1

[Peter Trudelle]

reassigning to pavlov as p2 for m11

Comment 2

[Colin Blake]

Data Point:
In widget/src/gtk/nsAppShell.cpp I changed G_PRIORITY_DEFAULT_IDLE to
G_PRIORITY_HIGH_IDLE (200 to 100) and now everything loads and displays
just fine. No mouse wiggling needed.

Comment 3

[Stuart Parmenter]

G_PRIORITY_HIGH_IDLE is too high.  need something lesser

Comment 4

[Colin Blake]

But if I use something higher than HIGH_IDLE (100), then the event queue
doesn't get serviced because something running at 120 (GTK_PRIORITY_REDRAW)
keeps pre-empting it.

Comment 5

[Colin Blake]

The other day, I tried removing my fix so that I was using
G_PRIORITY_DEFAULT_IDLE again. It appeared to work OK. I was busy with getting
M11 ready so I didn't really have time to test it too much. But it certainly
appears possible that something else has changed and I no longer need this fix.

I will do some real testing once I get my M12 tree running and post the results
back here.

Comment 6

[Peter Trudelle]

Mass-moving non-PDT+ bugs to M13

Comment 7

[Colin Blake]

My M12 code appears to be running just fine WITHOUT having to adjust the event
queue priority. My guess would be that the problem I was seeing was caused by
something else, timing related, that got fixed. The timing related nature of the
bug is what probably caused it to only appear on my platform, and is also why
dinking with the event queue priority made it go away.

Feel free to close this bug.

Comment 8

[Colin Blake]

Pav, if you close this, I'll mark it as verified.