[DOGFOOD] Problem with mouse event queue

RESOLVED INVALID

Status

()

P3
normal
RESOLVED INVALID
19 years ago
16 years ago

People

(Reporter: jim_nance, Assigned: blizzard)

Tracking

({verifyme})

Trunk
x86
Linux
verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-])

(Reporter)

Description

19 years ago
Here is a problem I am having with the GTK version of mozilla.  It happens under
Solaris and Linux and has been going on for a long time.

If you have a long document (tinderbox is a good example), and you scroll it
with the right hand scroll bar, mozilla seems to queue up all the mouse events
and process them sequentially.  Since it takes a long time to redraw a long
document, mouse events can accumulate faster than they can be processed, leading
to an interesting effect where mozilla keeps scrolling for several seconds after
the mouse has stopped moving.  It would be nice if the code would try to discard
these intermediate scrolling events.

If its not clear what I am talking about, I can try to give more details.  Just
let me know.
(Reporter)

Comment 1

19 years ago
This problem seems to have gotten much worse since I submitted the bug report.
It is very noticable when I try to view slashdot or www.redhat.com today
(Reporter)

Updated

19 years ago
Summary: Problem with mouse event queue → [DOGFOOD] Problem with mouse event queue
(Reporter)

Comment 2

19 years ago
Talked with blizzard on IRC and realized I need to clarify my report.
Its not the slowness I have a problem with.  Its the fact that the
page continues to "bounce" after the mouse stops moving, or that the
page can be moving in the opposite direction that the mouse is moving.

This is most noticable on large pages with mozilla expanded to the full
hight of the display.
(Reporter)

Comment 3

19 years ago
alecf did some work that may help or even fix this bug.  I dont know
the details.

Comment 4

19 years ago
This is a part of a significant performance problem on Linux.  The problem is
that keyboard events (such as efforts to scroll via the scroll bar) are not
coallesced, and each is acted up individually.  This allows the browser to fall
progressively further and further behind (until the user stops putting in
events... and then they are eventually all processed).  It can also been seen in
email when you click on the down arrow in the scroll bar to the right of the
subject line top-pane.  If you click 20 times rapidly, you can then sit and
watch as each click is processed (in fact, you'll get combinations of click and
double click events, totalling about 30 scroll-downs).

This is clearly a very important element of percieved performance.  I *think*
(from when I've tried using linux) that awareness of this performance problem
caused me to work around it, and be cautious about "clicking off into the
distance" before waiting for a response.  This should certainly be fixed soon
(it will help make Unix etc. much more responsive and user friendly), but it
does not IMO stop a developer from using the product.

For that reason, I'm putting down PDT-.  If you feel that even with an awareness
of this problem, you can't work around it (i.e., use care), then please supply a
scenario and we'll give that some reconsideration.

Again, this should be fixed for a beta on Linux, given performance targets that
have been disucssed.

Thanks,

Jim
Whiteboard: [PDT-]

Comment 5

19 years ago
Pav and I just added code to throw away all mouse motion events in the X queue
whenever a motion event comes in (except the last one, which we process). This
ought to speed up stuff a bit. Web pages do in fact scroll faster, and the
thread pane in mail is a bit faster.

I think the work is now left to fixing the scrollbar to not send so many scroll
events.
(Assignee)

Comment 6

19 years ago
Make sure that the events that you are throwing out don't include the enter /
leave events.

Comment 7

19 years ago
interesting. we're only throwing out motion events, but could those have
enter/exit? look at
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsGtkEventHandler.cpp#935

Yup, looks like we're not checking, and I can see a problem if I mouse from a
html button into a text field very quickly, button doesn't seem to loose the
:hover pseudo-style, so it stays highlighted... but if mouse motion events don't
include enter/exit information, then that's probably a different bug.

The fix should be fairly simple, are there any other types of events we should
be watching for?
(Assignee)

Comment 8

19 years ago
Uhh...yeah.  I'd have to look through the xlib reference ( which I don't have
here ) to make sure.  I'd back that out until you get it right.  People will
start filing bugs on that.
(Reporter)

Updated

19 years ago
Blocks: 23305
(Assignee)

Comment 9

19 years ago
Pavlov has been working on this.  It seems to be paint related.  We're reducing
the overhead of the calls and things are getting better.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID

Updated

19 years ago
Keywords: verifyme
(Assignee)

Comment 10

19 years ago
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
Status: RESOLVED → NEW
(Assignee)

Comment 11

19 years ago
bustage from my reassign
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago

Comment 12

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 13

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

Comment 15

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Updated

17 years ago
QA Contact: madhur → rakeshmishra

Updated

16 years ago
QA Contact: rakeshmishra → trix
You need to log in before you can comment on or make changes to this bug.