Bug 20236

Weird then that it isn't broken with 97c1cbc70216366e92b9371de608ce94e60aa874 already... Does current Git work with 3175646b10c602d17d5dd37bdace7c1c7ee92b3d reverted?

(In reply to comment #1)
> Weird then that it isn't broken with 97c1cbc70216366e92b9371de608ce94e60aa874
> already... Does current Git work with 3175646b10c602d17d5dd37bdace7c1c7ee92b3d
> reverted?
> 

No, I get corruption with master + above reverted.

> No, I get corruption with master + above reverted.

If I then revert my revert and

git revert b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8

It works OK.

Reiterating on my doubt from comment #1:

When you bisected to find b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 as the culprit, you tried 97c1cbc70216366e92b9371de608ce94e60aa874 and it didn't show the problem?

Could it be the same as bug 16416? Are you using the GTK1 version of seamonkey? Does Option "ExaOptimizeMigration" "off" work around the problem? If it's not the same, please attach a screenshot of the corruption.

Created attachment 23162 [details]
screen 1 showing corruption

(In reply to comment #4)
> Reiterating on my doubt from comment #1:
> 
> When you bisected to find b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 as the
> culprit, you tried 97c1cbc70216366e92b9371de608ce94e60aa874 and it didn't show
> the problem?

I think the final test was the commit after that - so possibly not tested.
I will try later/tomorrow as I will be away fron PC for a while.
 
> Could it be the same as bug 16416?

Doesn't look the same.

> Are you using the GTK1 version of seamonkey?

No.

> Does Option "ExaOptimizeMigration" "off" work around the problem?

Yes.

> If it's not the same, please attach a screenshot of the corruption.

Uploaded a couple - the corruption is not consistent eg. in screen 1 after alt tab to another browser window and browsing around (I can't clear it by just changing away and back) Your and Alex's names were OK but the number 2 was corrupt every where it appeared.

I don't have much installed on this partition to test with, but it seems that only proportional fonts are affected.

The second screen shows a non seamonkey occurance, the t on the metacity menu are corrupt - later in the same session they rendered properly.

Created attachment 23163 [details]
screen 2 matacity menu corruption

I suspect this is a driver coherency issue - does

Option "ExaNoDownloadFromScreen"

or

Option "ExaNoUploadToScreen"

work around the problem? (Without the previous workaround)

(In reply to comment #8)
> I suspect this is a driver coherency issue - does
> 
> Option "ExaNoDownloadFromScreen"

This fixes it.

> Option "ExaNoUploadToScreen"

Does not fix. 

Thinking I had fount the guilty commit I didn't give hardware details in the origional report :-( 

I don't know if it's relavent but this is an AGP card.

As for the other test, I did a

git reset --hard 97c1cbc70216366e92b9371de608ce94e60aa874

Applied b349a764e98f0d8f221190157ffa0904b91beca5 to fix the build

I see no corruption.

(In reply to comment #10)
> As for the other test, I did a
> 
> git reset --hard 97c1cbc70216366e92b9371de608ce94e60aa874

Ugh sorry, I meant to say 736b6fbd2c941b6276066cd1503523edebe7bf3d all along.

(In reply to comment #9)
> > I suspect this is a driver coherency issue - does
> > 
> > Option "ExaNoDownloadFromScreen"
> 
> This fixes it.

[...]

> I don't know if it's relavent but this is an AGP card.

Accelerated DownloadFromScreen is indeed known to be unreliable on some AGP setups, which is why the driver option "AccelDFS" defaults to off. It looks like this logic isn't hooked up for R6/700 yet though.

Anyway I think things are pointing to the driver, reassigning.

(In reply to comment #11)

> Ugh sorry, I meant to say 736b6fbd2c941b6276066cd1503523edebe7bf3d all along.
 
I reset to this and was about to post that there was no corruption when I noticed one char and that's mended it's self now, so it's there but something like 200X less obvious/ takes a lot longer to appear.

FWIW running with this commit is really slow for scrolling/drawing browser pages - I had to treble check I wasn't running with something disabled.

  

(In reply to comment #12)

 
> Anyway I think things are pointing to the driver, reassigning.

OK, but I've been testing with radeonhd - although I did try radeon when I first noticed the problem and it was affected aswell.

 

(In reply to comment #14)
> OK, but I've been testing with radeonhd - although I did try radeon when I
> first noticed the problem and it was affected aswell.

Feel free to reassign (with the 'Reassign bug to default assignee and QA contact, and add Default CC of selected component' radio button selected) or file another bug against the radeonhd driver.

(In reply to comment #15)

> Feel free to reassign (with the 'Reassign bug to default assignee and QA
> contact, and add Default CC of selected component' radio button selected) or
> file another bug against the radeonhd driver.
> 

I'll leave it as radeon for now - I've tested the latest and it's the same.

I rechecked that reverting b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 really does fix it and it does - I accept it may be luck, but two days and I didn't see any font corruption.

After lots of trying I only found one other case of a transparent png over a repeating .jpg that I could get to corrupt and I had to scroll the page really fast so it couldn't keep up to get that to happen and it was minor and cleared quickly.

Running with ExaNoDownloadFromScreen off seemed quite slow in some circumstances.

 

(In reply to comment #16)

> Running with ExaNoDownloadFromScreen off seemed quite slow in some
> circumstances.

I don't know if this is relevant, but while testing for another bug - 20436, it was found that 
Option "BusType" "PCIE"
fixed it.

It does not fix this one though - if anything it makes it twice as bad.

I've disabled gart transfers on r6xx/r7xx AGP cards:
c0e2513ab128ddd5be0ed626d9e31777a98983ef

(In reply to comment #18)
> I've disabled gart transfers on r6xx/r7xx AGP cards:
> c0e2513ab128ddd5be0ed626d9e31777a98983ef
> 

This fixes it for ati, but the similar patch for radeonhd does not fix the same
issue with that driver.

(In reply to comment #19)
> This fixes it for ati, but the similar patch for radeonhd does not fix the same
> issue with that driver.
> 

fixed now.

(In reply to comment #18)
> I've disabled gart transfers on r6xx/r7xx AGP cards:
> c0e2513ab128ddd5be0ed626d9e31777a98983ef
> 

I've noticed that although this fixes the issues with ati some web pages with seamonkey take far too long to render and scroll very poorly (smooth scroll is off).

An example page is 
http://redbutton.svn.sourceforge.net/viewvc/redbutton/redbutton-browser/trunk/

I can scroll OK as fast as I can go with the mouse wheel, but as soon as I use the scroll bar to get to the bottom quickly it pauses and takes a while to render, then pause again, renders ... until I get to the bottom.

Switching metacity work spaces to (and from partially) is also very slow.
At 1024x768 it takes a second to render the screen and a further second for the contents of the previous workspace to be cleared. At high res it's 3+3 seconds and  when switching away from that workspace it still delays the metacity graphic that shows which workspace you are on from being cleared.

These issues do not happen if I use xorg vesa driver (which FWIW currently doesn't manage to set up mtrr for me).

Top shows CPU being eaten by Xorg, oprofile shows libc memcopy.

Are you still seeing the font corruption? If not, please resolve this report as fixed and track other issues in other reports, be it existing ones or new ones.