164234 - [Jaguar] Scroll region new content painted twice or erratically when scrolling

Status: RESOLVED WONTFIX

(Camino Graveyard :: OS Integration, defect)

Description

[monkeypox37]

I've hesitated a bit about submitting this since it seems to be getting worked
on (or at least the behavior of the last few nightlies has changed for some
reason) but just in case...

1) Load a web page with enough lines to be able to scroll.
2) Open Quartz Debug, turn on only "flash screen updates"
3) Scroll - this seems to initially behave correctly, by which I mean:
   a) region scrolls up or down depending on direction of move - not flashed
   b) new content flashes once
   c) rinse, repeat
4) If it behaves as it should, browse around for a bit, with screen flashing off
if you prefer not being driven insane.
5) Try 2-3 again and you'll probably notice:
   a) the new content region is being flashed twice and/or
   b) sometimes weird bits of the screen will be flashed as well, opening up a
new window and loading www.macnn.com instead of in a new tab gave me this
behavior with the 8-22 build, some earlier builds have done this as a matter of
course.

Oh yeah, one other weird thing... The scrollbar seems to paint twice, once Cocoa
style (optimized to only redraw the bare minimum) and again Carbon style (the
whole thing is flashed - Apple is too busy making chat programs to optimize
Carbon ;).

Comment 1

[Chris Petersen]

Simon,


Is there already a bug reported about this issue ?

Comment 2

[Simon Fraser [no longer active]]

.

Comment 3

[Simon Fraser [no longer active]]

Related to bug 166932?

Comment 4

[Simon Fraser [no longer active]]

Well, at least some of this will be Cocoa's coalescing of dirty rectangles,
particularly on fast scrolling (it will coalesce scrollbar updates with content
updates).

Comment 5

[monkeypox37]

Attachment: A brutally compressed screenshot that sort of shows the Quartz Debug output

Weird - I was just going to say that I didn't see the problem anymore as of
2002102304 - when Chimera crashed. After restarting it I decided to check one
last time before filing the WFM comment and now it's magically back again
(yay!) but this time with just loading the bug report page so maybe it has
something to do with form elements?

You can 'clear' the weird painty regions by turning on the 'autoflush' drawing
checkbox in Quartz Debug for one scroll event.

I captured what it kind of looks like with Grab's timed capture (turning it on
and scrolling when it was about to take a screen - the yellow part on the
screen
isn't the entire yellow area that Quartz Debug was showing but I didn't want to
spend all night trying to get a complete capture

Comment 6

[Simon Fraser [no longer active]]

I'm sure form elements cause a lot of unnecessary drawing.

Comment 7

[Philip Timmermann]

Hmmm... Reading about these "paint twice" issues in form-elements remind me a
lot of what I wrote in bug 148685 about text looking like its being drawn two
times above itself...

Comment 8

[monkeypox37]

Re: similarity of bug 164234 to 148685

These are two different things. This bug is concerned with the region being
drawn by Chimera when scrolling. In 10.2 the graphics card is finally used to
accelerate scrolling - that means it moves the scroll region and then Chimera
should paint in new content only (compared to 10.1.x where the entire scroll
region was repainted). Form elements seem to cause the area that Chimera
repaints to become messed up and so it re-draws parts of the window that don't
need to be done.

FWIW I haven't been following 148685, but if you use Quartz Debug and turn on
the 'Autoflush drawing' and 'Flash screen updates (yellow)' checkboxes it'll
draw the button slowly enough that you can see what's going on.

I'll cross-post this in 148685 in case Phillip doesn't check this one.

Comment 9

[Mike Pinkerton (not reading bugmail)]

*** Bug 160280 has been marked as a duplicate of this bug. ***

Comment 10

[Simon Fraser [no longer active]]

Is this really still an issue?

Comment 11

[Jasper]

Did anyone notice that when running Quartz Debug with "flash screen updates" on,
the google search bar redraws with almost any action inside the HTML view. Even
typing this post flashes the google bar constantly, and when scrolling the page
it also does it.

Could this effect the overall scroll performance?

Comment 12

[monkeypox37]

Re: Simon's query

I just checked it with Build ID: 2003071505 and unfortunately it's still with
us, or at least me.

Re: Jasper's comment

Drawing any extraneous blit in OS X kills performance since drawing to the
screen is more costly than on Windows or whatever.

To summarize what I can remember from this:

1) It doesn't happen when you first start the program, but principally does when
you're using a site that draws form widgets. Just a guess but the way you're
drawing the aqua style form widgets seems to corrupt something (in the backing
store?) and when it comes time to redraw more than just the necessary area gets
passed off to Quartz to redraw.

2) If you turn on the autoflush drawing (if I understand this option, it
bypasses the backing store and draws each bit of data directly to the screen,
this would also mean the backing store would have to be "rebuilt" when turning
it back off) in Quartz Debug and scroll, then turn it off, Camino scrolls
normally again until the buffer or whatever gets corrupted again.

3) It's not critical, everything still draws, but it hurts performance.

A bit of an off-topic aside: the version of Firebird I just downloaded redraws
the entire content region with each scroll move and is still faster than Camino
scrolling this bug page, so fixing this bug might not necessarily make it the
scrolling champ, but it couldn't hurt.

Comment 13

[Jasper]

Prachi is working on the google field bug 213312.

But that still leaves us with the question why Camino is scrolling slower than
Firebird?

Comment 14

[monkeypox37]

Firebird scrolling faster than Camino seems to be a function of the cost of drawing the Aqua style 
form widgets in this case. To be fair to Camino I was using the scroll wheel which doesn't really 
show raw performance (for that use the scrollbar's thumb). The way Firebird handles the scroll 
wheel on the mouse might make it seem faster (by scrolling more aggressively or whatever).

All things being equal, Camino *should* be faster because it doesn't (or shouldn't) draw the entire 
content region like Firebird, but the two programs don't draw the same content.

Comment 15

[Jasper]

As Wincent mentions in Comment #2 of Bug 164733, Camino has "guaranteed
redundant paints (red flashes) whenever youscroll in small increments (eg. by
clicking on scroll arrows, or using a mouse scroll wheel".

I checked this out with the Mozilla.org front page and compared Camino with
Mozilla 1.5a. You would expect both to have the same paint behaviour but they
don't. Mozilla redraws the content very even while Camino is doing really weird
stuff. And as far as I can tell it has nothing to do with the painting of the
Aqua style form widgets since there is only one button in the right top corner,
and camino keeps doing weird stuff even when it's out of sight.

Comment 16

[Mike Pinkerton (not reading bugmail)]

i tested camino in comparison to safari and textedit. both exhibit the exact
same red repaints when the scrollbar is used. 

it appears to me that all cocoa apps have this behavior, it's probably in
appkit's scroll method.