Open Bug 172499 Opened 17 years ago Updated 6 months ago

Need to implement nsIWidget::GetLastInputEventTime(PRUint32& aTime) on GTK+

Categories

(Core :: Widget: Gtk, defect, P5)

x86
Linux
defect

Tracking

()

People

(Reporter: kmcclusk, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

Attachments

(1 file)

this was broken off from bug 165039

To improve interactivity during long page loads we need to implement
nsIWidget::GetLastInputEventTime.

Since it is currently not implemented, Mozilla gets the last user input event
time from the viewmanager. The viewmanager only reports times for mouse and
keyboard events which occur in windows associated with a viewmanager. Other
mouse and keyboard events such as clicking in a window title bar are not
reported so moving a window while loading a long page is sluggish. For embedded
applications, clicking on native menus and interacting with native dialog boxes
is also sluggish because these mouse and keyboard events times are not recorded
in the viewmanager.


NS_IMETHOD GetLastInputEventTime(PRUint32& aTime) = 0;

Description:

Get the last user input event time in milliseconds. If there are any pending
native toolkit input events it returns the current time. All input events are 
included (ie. it is *not* limited to events targeted at this nsIWidget instance.

@param aTime Last user input time in milliseconds. This value can be used to
compare durations but can not be used for determining wall clock time. The value
returned is platform dependent, but is compatible with the expression 
PR_IntervalToMicroseconds(PR_IntervalNow()).
> Other mouse and keyboard events such as clicking in a window title bar are not
> reported so moving a window while loading a long page is sluggish.

Interactive window moving and resizing don't require application
intervention under X11.  It's fair to say that the percieved speed
might suffer, though, if Moz can't respond to the resulting repaints
reasonably quickly (so should expose/repaint requests count as
outstanding 'native toolkit input events'?).

Absolutely expose/repaint events should count, one of the biggest visual
annoyances for Mozilla is the fact that Mozilla windows behave so much
differently than other windows under X, in that there is often a noticeable lag
between the time part of a window is exposed and it is properly painted when
Mozilla is busy.  During even the load of a short page it looks terrible,
anything that could speed up this handling would make Mozilla on X look much
better from an end user perspective.  This may have been only seen as a problem
for Windows on long page loads, but it is noticeable on Linux even for a fairly
simple page.

It may seem trivial to some, but as Linux is just starting to make some very
small inroads into the desktop world, things like this really stand out from
people used to the more aesthetically pleasing experience they are used to.

Even if doing all this extra "unnecessary" painting as these events come up
slows down the actual wall clock page load times I think it is desireable,
because page loads aren't normally done while windows are being moved, and when
they are, the user is concerned with something else other than the waiting for
the page load and render to complete.
This method is used to determine if the parser should interrupt more frequently.
The parser should only interrupt more frequently when the user has moved the
mouse, entered keyboard input, clicked the mouse. 

It must only return User Input events. Not paint/expose events.  If there are
paint starvation issues on Linux they need to be addressed by looking at the
mechanism for PL_Event dispatch on Linux, *not* by interrupting the parser. 
over to a real owner
Assignee: pavlov → blizzard
Component: GFX → GFX: Gtk
QA Contact: petersen → ian
Summary: Need to implement nsIWidget::GetLastInputEventTime(PRUint32& aTime) on Linux → Need to implement nsIWidget::GetLastInputEventTime(PRUint32& aTime) on GTK+
Blocks: 194623
Attached patch wipSplinter Review
Something like this perhaps?
BTW, what would be a good testcase for this bug?
The best testcase is probably putting printfs in the mode-switching stuff in nsHTMLContentSink and seeing what it behaves like, esp in an embedding app when you interact with said embedding app's UI...
Assignee: blizzard → nobody
Component: GFX: Gtk → Widget: Gtk
QA Contact: ian → gtk
You need to log in before you can comment on or make changes to this bug.