User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 CPU AMD 1.6+ download file http://www.mysql.com/get/Downloads/Manual/manual.tar.gz/from/http://mysql.mirror.ok.ee/ unpack, open manual.html situation: started mozilla, file opened. RAM: 512MB OS: windows 2k Physical Memory (K) Available: ~358880 CPU Usage: ~0% moving mouse pointer over opened document makes: mouse lag and 100% cpu usage. This bug was in previos version of mozilla, and ocures on every large html document. Reproducible: Always Steps to Reproduce: 1.download file http://www.mysql.com/get/Downloads/Manual/manual.tar.gz/from/http://mysql.mirror.ok.ee/ 2.unpack 3.open manual.html 4. move mouse around document, watch cpu usage (minimized Windows Task Manager) Actual Results: CPU Usage: 100% Expected Results: Dont eat all cpu when browsing a big html page. theme: Orbit 3+1 1.5 MiK You can use mysql documentation manual.html file which is about 3MB size.

The problem is that we have to figure out where to fire the mouseout/mouseover events.... Profile shows: Total hit count: 1757 Count %Total Function Name 1047 59.6 nsContainerFrame::GetFrameForPointUsing 214 12.2 nsBlockFrame::GetFrameForPoint 211 12.0 nsRect::Contains 110 6.3 nsFrame::GetFrameForPoint There is a minor optimization that can be made in nsContainerFrame::GetFrameForPointUsing by breking out of the while loop if we find a hit. I think that will lead to incorrect behavior, though, and it doesn't help when people are mousing over the background of a container with lots of kids (but not over any of the kids). I don't believe there's any way we can map a position to a frame faster than O(N) in the number of children we have.... That said, while I do see the CPU meter hovering around 70-100% as I move the mouse I see no mouse lag (p3-733 Linux).

trying: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040219 the same thing. On Windows 2000 with cpu 1,6+ AMD i can clear see that mouse pointer doesn't goes fast as I move mouse. And after mouse move stop, mouse pointer stil moves over screen. It's funny. CPU 1.6+AMD isn't enouth to handle/repaint mouse move :-) It was cool time with 486.... ech.... Why do you think this isn't solvable faster as O(n)? O this this can be solved O(log(n)). Use binary tree. dive page into subareas. You can map object into some subarea. If this subarea contain no object which want's receive mouse event. Check that. If subarea has many objects divide ito smalers subarea. You can chose use rectangular, or polygon another other form of subarea. Rectangular is faster to calculate. But then some objects goes into more that one subarea. and so on...

> Why do you think this isn't solvable faster as O(n)? Because the layout objects are stored as a linked list. I didn't say it's not solvable in general, just that _we_ can't solve it in the current layout architecture. In any case, your proposal is hard to implement in the presence of z-index (this is probably the thing that kills it), and doesn't improve things very much on 99.9% of pages.

Ok, this is a bug This bug can't be solvable in current layout architecture. This bug must be fixed near future. This is true?

We don't need to worry about quadtrees and stuff, because I'm pretty confident that the problem is mainly about finding the right lines in large nsBlockFrames. In particular, can't we make nsBlockFrame::GetFrameForPoint to iterate through the lines, scanning the frames within a line only if the point is inside the line's combinedArea? I bet that would speed things up a lot. Actually I'm sure this would work because that's how nsBlockFrame::Paint works. If we were really cool we would keep a bit in each nsBlockFrame, and set it to true if we detect that the sequence of 'line->combinedArea.y's is nondecreasing and the sequence of 'line->combinedArea.YMost's is nondecreasing. We would also cache somewhere a pointer to the most recently accessed line. Then we can quickly find the complete set of line(s) for a given point by starting at the cached pointer and searching forwards or backwards. I remember at one time thinking this could speed up painting on large pages too.

So it turns out bug 51938 is about exactly this issue. *** This bug has been marked as a duplicate of 51938 ***