WebCore's text selection improvements

[David Hyatt]

On Oct 1, 2003, at 9:04 AM, Dirk Mueller wrote:

> Why? Are your eyes able to see more than 25 updates / second?
>
> It took us a long time to get this installed in khtml, and I don't see 
> a
> reason why it should get removed again. There are plenty of sites that
> trigger 100% CPU usage by triggering repaints all the time. It might 
> be less
> of an issue for your platform which has a fast painting path, but X 
> servers
> are really slow and we can easily starvate everything by painting full 
> speed.
>
> So what is your intention behind this?
>

With the repaint timer, then rects get united, since you every time a 
repaint is scheduled before the timer has fired, KHTML's repaint 
scheduler will just union the rects.  More importantly in an 
incremental repainting world where multiple synchronous repaints could 
be scheduled at once by layout, you don't want to unite the rects 
unnecessarily.

Since Panther has a faster painting path that does not unite rects, the 
timer will actually get in the way.  I need to stop the uniting of the 
rects that happens at the KHTML level.

That said, we can #ifdef this if you need the timer to stay.  My issue 
isn't so much with the timer per se as with the fact that it unites 
rects.  However, adding a bunch of logic for khtmlview to track 
individual rects, do coalescing etc., isn't really logic we need, since 
Panther does that for us.

dave