222972 - [panther] drawing of the page is totally cluttered up with whitespaces and some areas are blinking.

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect)

Description

[Andreas Fink]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030901 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030901 Camino/0.7+

go to http://www.swisstalk.ch
register, log in.

you will see a chat. If you do the same on MacOS 10.3 Build 7B85 (release
version from last saturday), the page is totally screwed up. Everything is at
the right place but some areas are not visible (white) and some areas are
blinking (which never did before) I have a screenshoot to share.

This is probably related to hardware acceleration now used in 10.3 which was not
in 10.2.8.

I was reproducing this problem on my PowerBook G4 17".
system profile report available.

Reproducible: Always

Steps to Reproduce:
1. log in to www.swisstalk.ch to see it working
2. upgrade your computer to 10.3
3. log into www.swisstalk.ch to see it not working.

Actual Results:  
white spaces are displayed in some areas
some areas blink which they shouldnt


Expected Results:  
display as before.

probably hardware accelleration related.

Comment 1

[Andreas Fink]

Attachment: Screenshoot

Comment 2

[Andreas Fink]

Attachment: system profiler report (as text gzipped)

Comment 3

[Andreas Fink]

forgot to mention, tested with latest nightly build of camino and previous releases.

Comment 4

[Jasper]

I can't reproduce this always. Common factor seems to be frames. Spymac.com and
also Railheaddesign.com have the same issue, but are not always reproducable.

Mozilla doesn't have this issue.

Comment 5

[Jasper]

Attachment: spymac frame redraw issue.

Comment 6

[Andreas Fink]

Attachment: reproducable test case

expand this stuff it archive. open the file "Swisstalk - Lifestyle und
Entertainment!.html". You will get two errors that two sub url's could not be
loaded (doesnt matter really) then the chat window should draw. if it draws ok,
click on some other window (in my case ICQ) and click back on the Camino
window.
It wil redraw but with defects.

Comment 7

[Jasper]

Another url that will work for me most of the time:
http://nl.secondhandmac.com/

Perhaps it's a combination of frames and animated gifs?

Comment 8

[Jasper]

Note that Bug 224213 is also one of the things that is involved in this bug.

Comment 9

[Martin Ler]

This page make's it too
http://xchat.centrum.cz/~guest~/modchat?op=roomframe&rid=3016497&menuaction=whoinroom

I often can see it on other pages, which don't use frames, but can use iFrames...

Comment 10

[S Woodside]

a discussion and som pix: http://forums.macrumors.com/archive/topic/45141-1.html

Comment 11

[Chris Petersen]

This sounds very similar to the problem that Mike has identified. These pages
have either a frameset or iframes (or a combination of the two).  Mike is this
basically a duplicate of 24213 ?

Comment 12

[Mike Pinkerton (not reading bugmail)]

similar, but i'm not yet convinced something else isn't going on here. it looks
slightly different, but probably the same root cause (coordinate bugs in
NSQDView introduced in panther)

Comment 13

[Chris Cogdon]

Attachment: Corrupted slashdot homepage.

Since 10.3, slashdot has been OCCASIONALLY corrupted. A 'refresh' often solves
the problem, and it's not exactly reproducable. I suspect it has something to
do with the rotating banner ads, where some ads cause the corruption, and some
do not. Unfortuantely, its hard to capture the information since a 'view
Source' will actually reload the page from the server rather than showing the
source of the currently loaded page, meaning you get a different ad.

Not sure if this is similiar to the bug listed here... will re-submit if a fix
is made to this bug, but doesn't fix Slashdot.

Comment 14

[Chris Cogdon]

Attachment: Corrupt Slashdot Homepage #2

And, here's the same page with the scrollbar moved slightly to the right,
demonstrating that the text has been 'pushed out' rather than overwritten.

Comment 15

[Mike Pinkerton (not reading bugmail)]

can someone give me a further reduced testcase? the swisstalk example is a good
one, but it's far from minimal to repro the problem. it would be nice to know
what the minimal html is to get this to happen.

Comment 16

[Mike Pinkerton (not reading bugmail)]

i commented out image blitting and it is still reproduceable. it looks like it's
trying to repaint frames in the wrong place, but i can't prove that. again, this
is where a simplified testcase would come in very handy.

Comment 17

[Jasper]

I made a very simple 3 frames with animated gifs testcase that will reproduce
the problems.

http://www.jasperhauser.nl/camino/bla/bug222972/

without the animinated gifs the paint errors only occur when some kind of
selection and frame switching (attention) is done. But with the animated gifs
all hell goes loose.

Comment 18

[Mike Pinkerton (not reading bugmail)]

turning off AA does not fix this bug, therefore it is different from the other
bug in panther. the testpages jasper provided show whitespace even when image
blitting has been disabled. something else is blitting out that space.

Comment 19

[Mina]

Attachment: New test case (without JavaScript)

The attached test case shows that it has nothing to do with JavaScript. The
problem seems to be caused by background images of body or table cells.

In the file top.html of this test case, if you suppress the background image of
the table, the problem goes away. Same thing if you suppress the background
image of the body of file left.html.

Experiments done using build ID 2003120503 (v0.7+) with a fresh (empty)
profile.

Comment 20

[L. Perone]

Here is another test case that gets totally screwed up...:
http://www.kids-hotline.de/

Notes on this example:

- after the preload-frameset has loaded (which is okay), the top frame is
screwed up (only a part of it has its background color), and surfing into the
forums ("Forenberatung") screws up the left frame. White areas appear...

- The rendering flaws seem do almost always disappear when resizing the window.

- They also disappeared, some times, when loading that page on a new window
after it had already been loaded once. Loading it under one of its alias
domains, for example http://www.kidshotline.de/ reproduces the problem, so it
seems also related to caching somehow.

Always reproducible, until now.
Tested with several nighties after panther appeared, the latest one used for
testing was: 2003-12-05. 

Comment 21

[Mike Pinkerton (not reading bugmail)]

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

Comment 22

[Mike Pinkerton (not reading bugmail)]

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

Comment 23

[Mike Pinkerton (not reading bugmail)]

i've done some digging to try to figure out what's going on, but i'm still lost.

what appears to be happening is that our erasing of rects in the testcase are
inconsistent. Sometimes we perform extra redraws that cause us to do more work
and erase the chunks of the iframe, other times it draws just fine. It's also
inconsistent in how it messes up, with extra erases tossed in for good measure
(usually only the first time).

The only thing that I can see from a little instrumenting is that our
invalidates are sometimes out of order with the drawing. I can see why that
might cause us to draw more than once, but not to draw in completely the wrong
place.

smfr, do you have some cycles to dig into this? you've always been better at
these kinds of bugs than me.

Comment 24

[Mike Pinkerton (not reading bugmail)]

Attachment: good&bad results of simple instrumentation

simplistic instrumentation of gfx and widget where we erase, draw, and
invalidate. shows results for when the page works and when it doesn't. seems
that hitting reload over and over is enough to see both good and bad cases.

Comment 25

[Simon Fraser [no longer active]]

Since this bug doesn't happen if you turn off the page background images, my guess is that it has 
something to do with the image tiling code.

Comment 26

[Simon Fraser [no longer active]]

Actually, it's not the image tiling code. I think the images tweak this because when they load, they 
cause an invalidate to happen. I think the two invalidates for different frames are are causing a 
coalesced update covering the union of the tiled areas. On handling this, we erase some areas to white, 
but fail to redraw the parts that weren't explicitly invalidated.

Comment 27

[Simon Fraser [no longer active]]

Attachment: Simpler test case

This is a simpler testcase

Comment 28

[Jon C. Thomason]

Attachment: screen shot showing Panther-style shearing in Jaguar

(In reply to comment #12)
> i'm not yet convinced something else isn't going on here.
> it looks slightly different, but probably the same root cause
> (coordinate bugs in NSQDView introduced in panther)

I'm not convinced that this is specific to Panther.  I suspect the answer will
be found closer to the bugs in which one tab's content is allowed to bleed
through into another.  For instance QuickTime (bug 156583) or the unsinkable
blinking caret.

I have a reproducible test case for 10.2.8, nightly build 2004040108, which
shows the same shearing/scrambling behavior I see so often on Panther.	(If
this is the wrong bug for that symptom, please point me in the right
direction.)

I first noticed it this morning, trying to read Slashdot in one tab, while in
another tab loading a photo gallery from a site that was being Slashdotted.  It
looked as if I was using Panther, but I wasn't.

1) Open a Camino window with two tabs
2) In the first tab, begin loading an image slowly
3) In the second tab, load Mozillazine or something
4) Scroll around -- use arrow keys, scrollbar, whatever
5) Watch for sections of the page to be jumbled around

Screen shot attached.  Test case (requiring PHP, to do throttled loading) to
follow.

My guess is that this problem already existed; Panther merely angers it.  ;)

Comment 29

[Jon C. Thomason]

Attachment: testcase to reproduce the shearing on Jaguar

Comment 30

[Jon C. Thomason]

Sorry for the spam -- I'm new here.  :}  I forgot to mention that I was unable
to reproduce the problem in Mozilla (2004040105) or Firefox (20040401).

Mike sees something specific in NSQuickDrawView that bothers him.  But I wonder
if maybe Camino is supposed to be doing something more to wrap the use of those
display ports for thread-safety or whatever -- even prior to Panther.

Comment 31

[Mike Pinkerton (not reading bugmail)]

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

Comment 32

[Greg K.]

I, too, have seen either this problem in Jaguar, or something similar. It
happens when some loading activity is still ongoing. For example, if you’ve
clicked a link but the server hasn't yet responded, and you can still scroll the
original page.

I also just noticed it by scrolling a page while another tab was waiting for a
server response.

Comment 33

[Stuart Morgan]

Comments 28-30 and comment 32 are all bug 203349, and (probably) not at all
related to this bug.

Jon, please re-post your screenshot and testcase there, so we can find them from
there.

Comment 34

[Mike Pinkerton (not reading bugmail)]

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

Comment 35

[Josh Aas]

Anybody have time to find out when this bug started occuring (i.e. what is the
last nightly that didn't have this bug)?

Comment 36

[Mike Pinkerton (not reading bugmail)]

i would assume, since it's my understanding that this happens in 0.7 as well,
that it's been around for a loooong time.

Comment 37

[Mike Pinkerton (not reading bugmail)]

yes, this does happen in 0.7 release.

Comment 38

[Simon Fraser [no longer active]]

This bug only happens on Panther, right? I think it has to do with Cocoa's new
update coalescing.

Comment 39

[Jim Witte]

I'm seeing it when searching for 'menus' on the following Apple documentation page:

http://developer.apple.com/documentation/Cocoa/Conceptual/MenuList/index.html

  The same thing happens when I view local file-based docs as well.

  The problem only shows up when the find command "crosses frames", and seems to
have something to do with the rectangle defined by the location of the previous
find, the location of the next fine, and perhaps a mouse-click location - I'm
not sure.

  Also, after playing with the bug for a while (20 times or so), it got to a
point where after reloading the page (this time from Apple's site), the
scroll-bar on the left frame would disappear (and sometimes other parts of the
page as well) until I resized the window.  But I can't get that to repeat (after
playing with the 'find' bug-invocation 4 times, so I don't know if it's truely
repeatable, or whether it was just a fluke.

Comment 40

[Jim Witte]

(In reply to comment #17)
> I made a very simple 3 frames with animated gifs testcase that will reproduce
> the problems.
> 
> http://www.jasperhauser.nl/camino/bla/bug222972/
> 
> without the animinated gifs the paint errors only occur when some kind of
> selection and frame switching (attention) is done. But with the animated gifs
> all hell goes loose.

This seems to have in common with the case I found (conmment #39) the fact that
the mis-erawing is restricted to the rectangle formed by certain points (the
animated gifs in his examples the positions of the "finds" in mine).  I would
guess that in my case, the redraw of the hilighted text triggers it.  But it's
odd that it *only* seems to occur when frames are involved, and when a redraw
seems to "cross" from one frame into another.

  Are different frames drawn as different NSQDView's - could that have something
to do with it?

Comment 41

[Stuart Lamble]

I'm seeing something similar: go to http://www.bricklink.com/, click on "Buy",
click on any store, click on any item, you'll almost certainly see this problem
occur. However, if I edit user.js to add the line:

  user_pref("image.animation_mode", "none");

the problem disappears, never to return (until I change animation_mode to either
"once" or "normal"). Don't know if flash (or other annoyances, such as blinking
text) will trigger the problem.

Comment 42

[Jasper]

While your observation will indeed cut back the severity of the cluttering of
many pages it's no garenty it will not happen. Adding thos pref certainly is
something I coulod recommend people to use who go crazy about this bug.

As I said when I maid my test case (comment #17) the worst cases are always
trigerd by animated gifs. The cases where this isn't the case, where only frames
and text create it are rare but do exist.

Comment 43

[Al Goldis]

(In reply to comment #42)
> As I said when I maid my test case (comment #17) the worst cases are always
> trigerd by animated gifs. The cases where this isn't the case, where only frames
> and text create it are rare but do exist.

In general, I suppose it is rare but it doesn't seem so to me because I have a
site with no animations just frames where I actually need to get work done and
it happens every single time I try to use it.  This bug has been absolutely
killing me since I installed Panther.

In this case the problem seems to be triggered or exacerbated by multiple frames
loading data independently while others are drawing.  At any rate, it might help
you to troubleshoot because it's virtually 100% reproducible. 

The problem is the site in question is passworded so I can't just give you a
link.  However, if it will help get this bug squashed, I can supply an id and
password, or possibly even get a temporary account created for you.

Comment 44

[Jasper]

Your observation is correct. In situations where multiple frames are loading and
one or some are slower then the others the rendering of the last loaded frame
trigers the mis rendering. It's as if the older painted frames are just forgoten
and not repainted while they should be.

Comment 45

[Stuart Morgan]

Attachment: fix

A fix... on the off-chance that anyone is interested ;)

This patches our redraws to use the new Panther API for bypassing coalesced
updates (on Panther only). Fixes Jasper's test case, and I'm not seeing
problems on other pages mentioned here. Needs to be banged on more, since I've
done fairly little testing, but I see no reason for this to cause any
regressions.

Hopefully, this also makes us faster. However, I'm not sure what kind of
overhead there is to calling the gecko redraw function more often, so I guess
in theory it could be slower. Someone who knows more of the graphics code might
be able to say?

Also, we can get a bigger speed boost by adding:
- (BOOL)wantsDefaultClipping {
    return NO;
}
but only if the gecko redraw code is guaranteed not to leave the rect it's
given. Again I defer to someone more gecko-knowledgeable. If we can do it
though, it would be great to get the extra speed.

For more info on what I'm doing, see:
http://developer.apple.com/documentation/Cocoa/Conceptual/DrawViews/Tasks/OptimizingDrawing.html

and the NSView section of:
http://developer.apple.com/documentation/ReleaseNotes/Cocoa/AppKit.html

Comment 46

[Stuart Morgan]

Comment on attachment 147780 [details] [diff] [review]
fix

Requesting that people bang on the patch

Comment 47

[Jon C. Thomason]

(In reply to comment #46)
> (From update of attachment 147780 [details] [diff] [review])
> Requesting that people bang on the patch

The patch worked nicely for me, fixing the issues shown in comment #17
and comment #41, running on a 17" iMac with 10.3.3.

Sharp workaround!  If the underlying problem is fixed in 10.3.4's AppKit,
I'd suggest checking both lower and upper bound versions.  I would expect
it impacts performance, so should only be used when needed for correctness.

You're right about comment #33, BTW.  :}  This patch doesn't help bug 203349.

Comment 48

[Stuart Morgan]

> If the underlying problem is fixed in 10.3.4's AppKit

I'm not sure that this is an OS bug:
[speculation]
I suspect that the badness is coming from this:
  "To guarantee compatible drawing behavior for existing view classes,
  AppKit by default enforces clipping to the area that needs drawing.
  On Jaguar and earlier, clipping was enforced more loosely to the
  NSRect parameter of -drawRect:"
I think we might be somehow making an explicit call to
invalidate/validate/erase/something the aRect parameter of drawRect, then the
clipping is preventing us from re-drawing in the areas of that rect that should
never have been touched in the first place. If so, then the true fix would be
finding and fixing/removing whatever call is doing the erasing.

On the other hand, it might be a bug that the OS is even allowing us to erase
the entire rect within the context of a drawRect call that should be enforcing
clipping; I suppose it depends on how we are doing it.
[/speculation]

Performance-wise, we are probably gaining in terms of not drawing as much, but
losing in terms of checking all the elements n times (against n rects) rather
than once. Probably what we really want to do to optimize speed is use
needsToDrawRect and traverse the whole view/widget tree once (as described in
the optimization doc), but not having dug into the actual drawing code I have no
idea how feasible that would be (i.e., how much of that is internal to Gecko and
not exposed to us)

Comment 49

[Isaac Finnegan]

This patch worked great for me as well.

Comment 50

[Stuart Morgan]

Attachment: same but ignoring clipping

For the slightly more adventurous: requests that the OS not do any clipping.
Should be faster, but might have drawing problems. In preliminary tests it
seemed fine, but I'm curious to see if it holds up to more rigorous tests (lots
of frames, animations, plugins, etc.).

It would also be nice if someone (pinkerton?) could to speed comparisons
between the two patches; if the improvement is noticable, it would be worth
finding out if we can really really on Gecko to clip for us.

Comment 51

[Simon Fraser [no longer active]]

This fix looks good to me, and worked during testing. I didn't see any
differences between the last two patches.

Comment 52

[Josh Aas]

Just built off trunk. Fixes the problem for me. Nice work.

Comment 53

[Mike Pinkerton (not reading bugmail)]

landed on trunk and branch. WAHOO!

Comment 54

[Greg K.]

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

Comment 55

[Mike Pinkerton (not reading bugmail)]

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