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.
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
Summary: Problem with mouse event queue → [DOGFOOD] Problem with mouse event queue
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.
alecf did some work that may help or even fix this bug. I dont know the details.
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
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.
Make sure that the events that you are throwing out don't include the enter / leave events.
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?
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.
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
Please ignore the spam. Changing address.
Assignee: blizzard → blizzard
Status: RESOLVED → NEW
bustage from my reassign
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Mass update: changing qacontact to email@example.com
QA Contact: janc → ckritzer
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
QA contact updated
QA Contact: gerardok → madhur
You need to log in before you can comment on or make changes to this bug.