Closed Bug 222972 Opened 21 years ago Closed 20 years ago

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


(Camino Graveyard :: OS Integration, defect)

Not set


(Not tracked)



(Reporter: andreas, Assigned: mikepinkerton)





(10 files, 3 obsolete files)

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
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 to see it working
2. upgrade your computer to 10.3
3. log into 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.
Attached file Screenshoot
forgot to mention, tested with latest nightly build of camino and previous releases.
I can't reproduce this always. Common factor seems to be frames. and
also have the same issue, but are not always reproducable.

Mozilla doesn't have this issue.
Attached file 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
It wil redraw but with defects.
Another url that will work for me most of the time:

Perhaps it's a combination of frames and animated gifs?
Note that Bug 224213 is also one of the things that is involved in this bug.
This page make's it too

I often can see it on other pages, which don't use frames, but can use iFrames...
Ever confirmed: true
Target Milestone: --- → Camino0.8
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 ?
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)
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.
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.
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.
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.
Summary: with MacOS 10.3 (Panther), the drawing of the page is totally cluttered up with whitespaces and some areas are blinking. → [panther] drawing of the page is totally cluttered up with whitespaces and some areas are blinking.
I made a very simple 3 frames with animated gifs testcase that will reproduce
the problems.

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.
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.
Attached file New test case (without JavaScript) (obsolete) —
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)
Here is another test case that gets totally screwed up...:

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 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. 

*** Bug 230529 has been marked as a duplicate of this bug. ***
*** Bug 232067 has been marked as a duplicate of this bug. ***
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

smfr, do you have some cycles to dig into this? you've always been better at
these kinds of bugs than me.
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.
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.
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.
Attached file Simpler test case
This is a simpler testcase
Attachment #136928 - Attachment is obsolete: true
(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

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

My guess is that this problem already existed; Panther merely angers it.  ;)
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.
*** Bug 239632 has been marked as a duplicate of this bug. ***
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.
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
Attachment #145324 - Attachment is obsolete: true
Attachment #145325 - Attachment is obsolete: true
*** Bug 240873 has been marked as a duplicate of this bug. ***
Anybody have time to find out when this bug started occuring (i.e. what is the
last nightly that didn't have this bug)?
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.
yes, this does happen in 0.7 release.
This bug only happens on Panther, right? I think it has to do with Cocoa's new
update coalescing.
I'm seeing it when searching for 'menus' on the following Apple documentation page:

  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.
(In reply to comment #17)
> I made a very simple 3 frames with animated gifs testcase that will reproduce
> the problems.
> 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?
I'm seeing something similar: go to, 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.
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.
(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.
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.
Attached patch fixSplinter Review
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

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:

and the NSView section of:
Comment on attachment 147780 [details] [diff] [review]

Requesting that people bang on the patch
Attachment #147780 - Flags: review?
(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.
> If the underlying problem is fixed in 10.3.4's AppKit

I'm not sure that this is an OS bug:
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.

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)
This patch worked great for me as well.
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.
This fix looks good to me, and worked during testing. I didn't see any
differences between the last two patches.
Just built off trunk. Fixes the problem for me. Nice work.
landed on trunk and branch. WAHOO!
Closed: 20 years ago
Resolution: --- → FIXED
Attachment #147780 - Flags: review?
*** Bug 243069 has been marked as a duplicate of this bug. ***
*** Bug 243225 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.