Created attachment 34607 [details]
screenshot

A screenshot of the chromium preferences dialog demonstrating the effect of this bug.

When I switched from one tab of the dialog to another, the image of the contents of the old tab remained in place. After waving my mouse over the window a bit, some parts of the user interface of the new tab popped up (probably since highlighting them forced a redraw). However, the image of the old UI remained drawn in the background; the result is that the user sees a crazy mixture of the contents of two tabs.

Created attachment 34608 [details]
Xorg.0.log

This does not seem to be restricted to GM45 as I am seeing this behaviour even on my 915GM.

945GM is also affected.

The bug is still present in the latest mesa 7.8.1 release.

Bugs #27421 and #27425 look like they are related to this one. I tested a similar patch as suggested in #27425 comment 4 to call intel_update_renderbuffers() unconditionally in intelSetTexBuffer2(). This helps somewhat, at least windows are update and scrolling text works, but this surely is not the right fix for the bug if I understand the commit messages properly.

downgraded mesa to 7.7.1
downgraded intel to 2.10

xorg = 1.8

issue still present. does this point to an xorg bug?

(In reply to comment #6)
> Bugs #27421 and #27425 look like they are related to this one. I tested a
> similar patch as suggested in #27425 comment 4 to call
> intel_update_renderbuffers() unconditionally in intelSetTexBuffer2(). This
> helps somewhat, at least windows are update and scrolling text works, but this
> surely is not the right fix for the bug if I understand the commit messages
> properly.

When you say "helps somewhat" do you mean that there are still redraw problems or what are you referring to?  The patch in #27425 is almost right, but if you see corruption even with that applied, can you try the patch in #27767, comment 1.

Sorry I am a bit confused, what exactly is the right patch to test? When you say #27425 comment 4 is almost right, is there better patch available?

(In reply to comment #8)
> (In reply to comment #6)
> > Bugs #27421 and #27425 look like they are related to this one. I tested a
> > similar patch as suggested in #27425 comment 4 to call
> > intel_update_renderbuffers() unconditionally in intelSetTexBuffer2(). This
> > helps somewhat, at least windows are update and scrolling text works, but this
> > surely is not the right fix for the bug if I understand the commit messages
> > properly.
> 
> When you say "helps somewhat" do you mean that there are still redraw problems
> or what are you referring to?  The patch in #27425 is almost right, but if you
> see corruption even with that applied, can you try the patch in #27767, comment
> 1.

doing that makes it untestable. everything LAGS!!,

going to test the oter patch on mesa and report back.

my previous statement that the issue was in xorg seems somewhat flawed.

it appeared there, and now im with mesa 7.8 and intel 2.11 but with xorg 1.7. it is still present here too.

(In reply to comment #8)
> (In reply to comment #6)
> > Bugs #27421 and #27425 look like they are related to this one. I tested a
> > similar patch as suggested in #27425 comment 4 to call
> > intel_update_renderbuffers() unconditionally in intelSetTexBuffer2(). This
> > helps somewhat, at least windows are update and scrolling text works, but this
> > surely is not the right fix for the bug if I understand the commit messages
> > properly.
> 
> When you say "helps somewhat" do you mean that there are still redraw problems
> or what are you referring to?  The patch in #27425 is almost right, but if you
> see corruption even with that applied, can you try the patch in #27767, comment
> 1.

tried to apply the patch in #27425 comment 4, but the source onf 7.8.1 is quite different, i cannot apply the patch (and it seems like a variation of that patch has already been applied, but im not that sure).

this is what ive got in the source:

    if (!intelObj)
       return;
 
    if (dPriv->lastStamp != dPriv->dri2.stamp)
       intel_update_renderbuffers(pDRICtx, dPriv);
 
    rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);

    /* If the region isn't set, then intel_update_renderbuffers was unable

Created attachment 35342 [details] [review]
unconditionally update renderbuffers

This patch applies cleanly on top of Mesa-7.8.1 and there is no more window corruption like in the screenshot above

(In reply to comment #8)
> (In reply to comment #6)
> > Bugs #27421 and #27425 look like they are related to this one. I tested a
> > similar patch as suggested in #27425 comment 4 to call
> > intel_update_renderbuffers() unconditionally in intelSetTexBuffer2(). This
> > helps somewhat, at least windows are update and scrolling text works, but this
> > surely is not the right fix for the bug if I understand the commit messages
> > properly.
> 
> When you say "helps somewhat" do you mean that there are still redraw problems
> or what are you referring to?  The patch in #27425 is almost right, but if you
> see corruption even with that applied, can you try the patch in #27767, comment
> 1.

I say somewhat as I am also seeing some text corruption in xterm it I type very quickly even after applying the above patch. I'll attach a screenshot. Window corruption in gtk as in the screenshot above is gone.

Created attachment 35343 [details]
snapshot of character corruption

This is what happens when I type. The corruption disappears as soon as I switch windows or do anything that requires a repaint of the window.

(In reply to comment #8)
> The patch in #27425 is almost right, but if you see corruption even with that 
> applied, can you try the patch in #27767, comment 1.

unfortunately the patch in bug 27767 comment 1 does not apply on xorg-server-1.8.0, which is what I used to test my patch in comment 12. The commit 1da1f33f mentioned in bug 27767 had not been backported to server-1.8-branch until after the 1.8.0 release.

The corruptions in individual windows as seen in the screenshot indeed disappear with the patch from comment 12 applied to mesa.

But now there are situations when the hole screen does not update. When this happens and I try to move a window, I now that the window was moved because the mouse cursor changes reflect the actual position of the window (for example on hyperlinks). But the screen does not update and the window is still displayed in its old position.

Changing the virtual desktop then triggers a screen update. I can also confirm the xterm problem.

I tried the patches from bug #27767 with the latest git checkout of the server, but they don't help with this problem.

Hi !

I think I have the same problem of screen corruption.

I solved it using "indirect rendering" with compiz fusion icon.
Did you tried that ?

Starting compiz with --inderect-rendering makes no difference. In fact the problem seems not to be specific to compiz, it also happens with kwin and compositing enabled. kwin without desktop effects is fine.

(In reply to comment #18)
> Starting compiz with --inderect-rendering makes no difference. In fact the
> problem seems not to be specific to compiz, it also happens with kwin and
> compositing enabled. kwin without desktop effects is fine.

I do not see any problem in kwin (not even the xterm problem) with compositing enabled after using the mesa patch from comment 12. Compiz Window movement is also fine.

You are right. The window movement bug is probably unrelated to this bug. I encountered it with xorg-server-1.8.0 and cannot reproduce it with xorg-server-1.7.6 right now. I will test 1.8.0 once again later.

So the patch from comment #12 indeed fixes this bug.

Well, apart from the xterm corruptions of course... but it is a great improvement.

Fix pushed to mesa master, closing bug.

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