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

RESOLVED FIXED in Camino0.8

Status

--
critical
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: andreas, Assigned: mikepinkerton)

Tracking

unspecified
Camino0.8
PowerPC
Mac OS X

Details

(URL)

Attachments

(10 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 133698 [details]
Screenshoot
(Reporter)

Comment 2

15 years ago
Created attachment 133699 [details]
system profiler report (as text gzipped)
(Reporter)

Comment 3

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

Comment 4

15 years ago
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

15 years ago
Created attachment 134356 [details]
spymac frame redraw issue.
(Reporter)

Comment 6

15 years ago
Created attachment 134384 [details]
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

15 years ago
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

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

Comment 9

15 years ago
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...
(Assignee)

Updated

15 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino0.8

Comment 11

15 years ago
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 ?
(Assignee)

Comment 12

15 years ago
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

15 years ago
Created attachment 136310 [details]
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

15 years ago
Created attachment 136311 [details]
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.
(Assignee)

Comment 15

15 years ago
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.
(Assignee)

Comment 16

15 years ago
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.
(Assignee)

Updated

15 years ago
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.

Comment 17

15 years ago
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.
(Assignee)

Comment 18

15 years ago
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

15 years ago
Created attachment 136928 [details]
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

15 years ago
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. 

(Assignee)

Comment 21

15 years ago
*** Bug 230529 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

15 years ago
*** Bug 232067 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

15 years ago
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.
(Assignee)

Comment 24

15 years ago
Created attachment 142041 [details]
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

15 years ago
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

15 years ago
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

15 years ago
Created attachment 142146 [details]
Simpler test case

This is a simpler testcase
Attachment #136928 - Attachment is obsolete: true

Comment 28

15 years ago
Created attachment 145324 [details]
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

15 years ago
Created attachment 145325 [details]
testcase to reproduce the shearing on Jaguar

Comment 30

15 years ago
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.
(Assignee)

Comment 31

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

Comment 32

15 years ago
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

15 years ago
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.

Updated

15 years ago
Attachment #145324 - Attachment is obsolete: true

Updated

15 years ago
Attachment #145325 - Attachment is obsolete: true
(Assignee)

Comment 34

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

Comment 35

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

Comment 36

15 years ago
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.
(Assignee)

Comment 37

15 years ago
yes, this does happen in 0.7 release.

Comment 38

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

Comment 39

15 years ago
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

15 years ago
(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

15 years ago
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

15 years ago
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

15 years ago
(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

15 years ago
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

15 years ago
Created attachment 147780 [details] [diff] [review]
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

15 years ago
Comment on attachment 147780 [details] [diff] [review]
fix

Requesting that people bang on the patch
Attachment #147780 - Flags: review?

Comment 47

15 years ago
(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

15 years ago
> 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

15 years ago
This patch worked great for me as well.

Comment 50

15 years ago
Created attachment 147835 [details] [diff] [review]
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

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

Comment 52

15 years ago
Just built off trunk. Fixes the problem for me. Nice work.
(Assignee)

Comment 53

15 years ago
landed on trunk and branch. WAHOO!
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Attachment #147780 - Flags: review?

Comment 54

15 years ago
*** Bug 243069 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 55

15 years ago
*** 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.