Severe damage artefacts and flickering when using LLVMpipe

Bug #1021104 reported by Daniel van Vugt
156
This bug affects 29 people
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
Critical
Daniel van Vugt
Compiz Core
Triaged
Medium
Unassigned
compiz (Ubuntu)
Fix Released
Critical
Unassigned
Precise
Won't Fix
Medium
Unassigned

Bug Description

There are severe damage artefacts and flickering when using LLVMpipe.

The root cause seems to be that LLVMpipe does not support dynamically switching between rendering methods like compiz does in the opengl plugin:
    glXSwapBuffers
    glXCopySubBufferMESA
    glCopyPixels
LLVMpipe _does_ support any of these rendering methods when used alone, but it doesn't like switching between them dynamically. I've verified they all work perfectly in LLVMpipe so long as you use the same code path on every frame.

It appears that glXSwapBuffers is confusing what the other functions think is the GL_FRONT and GL_BACK buffer. So either it is implemented using a separate GL_FRONT buffer, or glXSwapBuffers is failing to update GL_FRONT and GL_BACK. Not sure yet.

WORKAROUND:
1. CCSM > Workarounds > Force full screen redraws (buffer swap) on repaint = ON
2. Log out and in again.

Tags: llvmpipe

Related branches

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This might be a "feature" and not a bug in LLVMpipe:
http://www.mesa3d.org/osmesa.html

tags: added: llvmpipe
removed: llvm
Changed in compiz:
status: Triaged → In Progress
Changed in compiz:
status: In Progress → Fix Committed
Changed in compiz (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Revision history for this message
Rocko (rockorequin) wrote :

Is a fix likely soon?

Revision history for this message
Björn Michaelsen (bjoern-michaelsen) wrote :

for the situation in virtualbox setting full redraws on swap certainly helps, but it does not solve this completely: there is still ~one frame per second showing something that look like a old/wrong fullscreen buffer.

Revision history for this message
Björn Michaelsen (bjoern-michaelsen) wrote :

Hmmm, the one wrong buffer per second in #3 seems only to be there during the session in which the setting changed. Seems to be ok after that (though slow).

Revision history for this message
Alberto Mardegan (mardy) wrote :

If you experience flickering after enabling the workaround described at the end of the bug description (bug #1040484), restarting the session should fix that.

description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (7.9 KiB)

This bug was fixed in the package compiz - 1:0.9.8+bzr3319-0ubuntu1

---------------
compiz (1:0.9.8+bzr3319-0ubuntu1) quantal-proposed; urgency=low

  [ Didier Roche ]
  * debian/patches/ubuntu-config.patch:
    - refresh with latest trunk
  * debian/*docs:
    - remove the TODO copy now removed upstream
  * debian/compiz-plugins.install:
    - install stackswitch, trip plugins
  * debian/rules, debian/control:
    - remove the compiz gnome-control-center key sedding through metacity.
      Compiz now directly ships them.
    - we do not need metacity-common anymore as a build-dep then
  * debian/compiz-gnome.migrations, debian/control:
    - build-dep on dh-migrations and ship gconf -> gsettings migration file

  [ Matthieu Baerts (matttbe) ]
  * Update apport hook for python3 ; thanks to Edward Donovan (LP: #1013171)

  [ Timo Jyrinki ]
  * New upstream snapshot.
    - Fix Compiz crash in movementWindowOnScreen (LP: #1015151)
    - Start window decorator when decor plugin starts (LP: #1014461)
    - Fixed: Crash in compiz::wall::movementWindowOnScreen (LP: #1015151)
    - Don't waste memory leaving /bin/sh running (LP: #1015422)
    - Add reliable detection of the compiz bin directory (LP: #1015898)
    - Check if the window would actually paint before painting the shadow,
      since it is possible that another plugin could be inhibiting paint of
      the dock window. (LP: #1012956)
    - Don't insert the window into the server list above the window it was
      created above. (LP: #1008020) (LP: #886605)
    - makes compiz enhanced zoom and show mouse plugins considerably
      smoother to use (LP: #930783)
    - Don't set decoration contexts on undecorated windows, since that
      might be read later and code will assume the window is decorated when
      it isn't. (LP: #1015593)
    - Fix potentially unterminated string leading to an uninitialized memory
      read (LP: #1018302)
    - Lift the 31/32 character restriction on key names that was causing so
      many warnings. It's now 1024 characters according to glib. (LP: #1018730)
    - Don't print the result of BUILD_DEB. It prevents ccsm et al from
      installing. (LP: #1018916)
    - Use the XDamage extension more efficiently (the way it was designed to be
      used). This dramatically reduces CPU usage, reduces wakeups, and
      increases frame rates. It also solves at least one observed performance
      bug (LP: #1007299) and probably several more.
    - Do the initial work to get libcompizconfig under test. (LP: #990690)
    - Add support for initiating window picker in other than nomal mode. For
      now added only the additional 'All windows' picker (LP: #933776)
      (LP: #955035)
    - Fixes (LP: #1018602) : An invalid read when using g_variant_iter_loop.
    - Don't allow unbinds of textures kept around for animations in any case,
      not just resizing. (LP: #1016366)
    - Wait for the server to finish processing requests before doing a bind
      (LP: #1016367)
    - Using the next/previous bindings the wall plugin didn't calculate
      correctly the next workspace when it reaches the begin or the end of a
      row of workspaces, so it didn't jump to the n...

Read more...

Changed in compiz (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Rocko (rockorequin) wrote :

It is more usable with 1:0.9.8+bzr3319-0ubuntu1, albeit rather slow.

But the mouse polling doesn't seem to work very well. As I move the mouse around, it sometimes vanishes completely, and sometimes jumps over to the left or top left of the screen. If I'm moving a window at the time, the window vanishes or jumps over to the left or top left as well. With 'force complete redraw on initial damage' turned on, the glitch happens much more frequently. Is this related to the compiz/llvmpipe interaction or is this a separate bug?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Rocko: new bug please.

Revision history for this message
Rocko (rockorequin) wrote :

OK, reported as bug #1041063.

Changed in compiz:
status: Fix Committed → Fix Released
Changed in compiz-core:
status: New → Confirmed
Revision history for this message
Bartosz Kosiorek (gang65) wrote :

Is it possible to deliver artefacts damage fixes also on Precise Pangolin 12.04?

Changed in compiz (Ubuntu):
milestone: none → precise-updates
milestone: precise-updates → none
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think it would be possible. So I've linked this bug to future milestone: compiz-core 0.9.7.10

Changed in compiz-core:
milestone: none → 0.9.7.10
status: Confirmed → Triaged
importance: Undecided → Medium
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Compiz] [Bug 1021104] Re: Severe damage artefacts and flickering when using LLVMpipe

On Mon, 10 Sep 2012, Bartosz Kosiorek wrote:

> Is it possible to deliver artefacts damage fixes also on Precise
> Pangolin 12.04?
>

Precise doesn't use LLVMpipe, so this bug isn't applicable there.

> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/1021104
>
> Title:
> Severe damage artefacts and flickering when using LLVMpipe
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz/+bug/1021104/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Precise (Mesa) does fall back to LLVMpipe for VIA graphics users (xserver-xorg-video-openchrome). See bug 927538.

Revision history for this message
mikhail-777 (wpr-oxym) wrote :

A uploaded video to launchpad as you asked: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1071482
I see here status "Fix Released". Please tell me in which release of what it is fixed?

Btw, my bug is other: my bug is about working compiz+utity_3d only by root. Yes, it tries to use llvmpipe and fails (because of it), but it failed also when is forced to use normal way (Mesa DRI Intel(R) G33 x86/MMX/SSE2, if llvmpipe library is forced removed from the system) and again fails only for non-root users.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz (Ubuntu Precise):
status: New → Confirmed
Changed in compiz (Ubuntu Precise):
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in compiz-core:
milestone: 0.9.7.10 → 0.9.7.12
Changed in compiz-core:
milestone: 0.9.7.12 → 0.9.7.14
Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in compiz (Ubuntu Precise):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.