Ubuntu

Desktop effects are slow and desktop corruption using mesa 9

Reported by Stefan Freyr on 2012-10-03
182
This bug affects 32 people
Affects Status Importance Assigned to Milestone
KDE Base Workspace
Fix Released
High
Mesa
Won't Fix
High
kde-workspace (Ubuntu)
High
Unassigned
mesa (Ubuntu)
Medium
Unassigned

Bug Description

I have Kubuntu 12.10 set up on a ThinkPad T430.

I'm experiencing both desktop corruption and slow performance of desktop effects. I've tried to downgrade mesa to 8.0.4 and that fixed the problem.

Attached is a video comparing the two. The video does not show the desktop corruption I mention (vertical lines appearing) but I will attach a screenshot of that.

I originally thought this was related to bug 1042211 but they told me to file another report since it seems to be different artifacts that I'm seeing.

Of course I can't say for sure whether the slow performance and the artifacts are due to the same problem but the artifacts seem to appear when the desktop effects are activated. As you can see in the video, mesa 9.0 displays much "jerkier" effects and it seems that when the artifacts come this jerking becomes really bad just before the artifacts appear. Just now I did notice that the artifacts appeared at the mouse pointer when I clicked in a window. The artifacts followed the mouse pointer as I moved it but after clicking a few times they disappeared.

WORKAROUND:
As described in bug 1042211 I downloaded the 8.0.4 version of mesa from https://launchpad.net/ubuntu/+source/mesa/8.0.4-1ubuntu1. This fixed the problem for me.

Since it took a little while for me to figure out how to get the .deb packages from that page, here is how for anyone who wants to try:
1) Go to the above page.
2) Under "Builds" select your architecture
3) This will bring you to a page with all the .deb files for your architecture. I only installed the libgl1-mesa-dri, libgl1-mesa-glx, libglapi-mesa and libglu1-mesa packages.

Please let me know if you need more information.

p.s. I had some problems choosing the package for this bug. It wouldn't let me put it on libgl1-mesa so I put it on libgl1-mesa-dri.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xorg 1:7.7+1ubuntu4
ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4
Uname: Linux 3.5.0-16-generic x86_64
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
Date: Wed Oct 3 15:40:20 2012
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120905)
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: kwin
DistUpgraded: Fresh install
DistroCodename: quantal
DistroRelease: Ubuntu 12.10
DistroVariant: kubuntu
DkmsStatus: virtualbox, 4.1.18, 3.5.0-16-generic, x86_64: installed
ExtraDebuggingInterest: I just need to know a workaround
GraphicsCard:
 Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21f3]
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120905)
MachineType: LENOVO 2347W2U
Package: mesa (not installed)
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-16-generic root=UUID=c8916e6c-a99f-43f1-9d8c-c1daf21fedac ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4
Tags: quantal kubuntu
Uname: Linux 3.5.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 05/25/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: G1ET41WW (1.16 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2347W2U
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG1ET41WW(1.16):bd05/25/2012:svnLENOVO:pn2347W2U:pvrThinkPadT430:rvnLENOVO:rn2347W2U:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2347W2U
dmi.product.version: ThinkPad T430
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.39-0ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.0~git20120917.7cfd42ce-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.0~git20120917.7cfd42ce-0ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.13.0-0ubuntu5
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.99.99~git20120913.8637f772-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.20.9-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.2-0ubuntu2

Stefan Freyr (stefan-freyr) wrote :
Stefan Freyr (stefan-freyr) wrote :

The video doesn't seem to have been uploaded. Here it is.

Stefan Freyr (stefan-freyr) wrote :

and here is a screenshot of the artifacts I'm seeing every once in a while.

Timo Aaltonen (tjaalton) wrote :

please install xdiagnose, and run 'apport-collect 1061073'

affects: xorg (Ubuntu) → mesa (Ubuntu)
Changed in mesa (Ubuntu):
status: New → Incomplete
Stefan Freyr (stefan-freyr) wrote :

Hi and thanks for the reply.

I installed xdiagnose, python-apport and python-launchpadlib but when I run 'apport-collect 1061073' I answer a series of questions but at the end when I press the 'Send' button I get this error:

stefan@atlas-stfs:~$ apport-collect 1061073
dpkg-query: no packages found matching mesa
Traceback (most recent call last):
  File "/usr/share/apport/apport-kde", line 519, in <module>
    sys.exit(UserInterface.run_argv())
  File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 634, in run_argv
    return self.run_update_report()
  File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 554, in run_update_report
    attachment_comment='apport information')
  File "/usr/lib/python2.7/dist-packages/apport/crashdb_impl/launchpad.py", line 358, in update
    report.write_mime(mime, skip_keys=skip_keys)
  File "/usr/lib/python2.7/dist-packages/problem_report.py", line 504, in write_mime
    attach_value = CompressedValue(v, k).gzipvalue
  File "/usr/lib/python2.7/dist-packages/problem_report.py", line 44, in __init__
    self.set_value(value)
  File "/usr/lib/python2.7/dist-packages/problem_report.py", line 50, in set_value
    gzip.GzipFile(self.name, mode='wb', fileobj=out).write(value)
  File "/usr/lib/python2.7/gzip.py", line 131, in __init__
    self._write_gzip_header()
  File "/usr/lib/python2.7/gzip.py", line 176, in _write_gzip_header
    self.fileobj.write(fname + '\000')
TypeError: 'unicode' does not have the buffer interface

tags: added: apport-collected
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Stefan Freyr (stefan-freyr) wrote :

Ok, I solved it by following the instructions in bug 1030483.

stefan (weigi) wrote :

i see the same behavior (slowness, artifacts). moreover, when using "kwin_gles" instead of "kwin" the screen does not seem to be re-drawn correctly. for example, invoking the "run command interface" starts to show it but does not finish the animation. the result is that you type but don't see what you type.
finally, turning off "use opengl 2 shaders" in the effects-config doesn't change anything either (neither for "kwin_gles" nor "kwin").

i hope this helps in some way to narrow down the issue.

Stefan Freyr (stefan-freyr) wrote :

Why is this still incomplete?

Robert Hooker (sarvatt) on 2012-10-17
Changed in mesa (Ubuntu):
status: Incomplete → Confirmed
Launchpad Janitor (janitor) wrote :

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

Changed in kde-workspace (Ubuntu):
status: New → Confirmed
Robert Hooker (sarvatt) wrote :

Can you try a few of these downgrades and report back on if they are working or not?

First, kde-workspace downgrade to 4.9.0, it was updated to 4.9.2 in the same timeframe as final mesa 9.0 and was a pretty large change from a glance.
https://launchpad.net/ubuntu/quantal/+source/kde-workspace/4:4.9.0-0ubuntu4

If that doesn't work, upgrade it back to kde-workspace 4.9.2, then try downgrading to each of these snapshots of mesa 9.0 and see if they are any better so we can narrow down where the problem was introduced.
https://launchpad.net/ubuntu/quantal/+source/mesa/9.0~git20121004.b2048c5e-0ubuntu1
https://launchpad.net/ubuntu/quantal/+source/mesa/9.0~git20120917.7cfd42ce-0ubuntu3
https://launchpad.net/ubuntu/quantal/+source/mesa/9.0~git20120903.e1673d20.is.git20120821.c1114c61-0ubuntu1

Rich Sezov (sezovr) wrote :

I've gotten this problem to mostly go away (see my post here: http://www.kubuntuforums.net/showthread.php?60502-Screen-artifacts-Intel-video) by changing Qt Graphics System to Render in System Settings -> Desktop Effects.

Stefan Freyr (stefan-freyr) wrote :

That doesn't solve the problem... it just bypasses it. Besides, using XRender disables most of the desktop effect goodies.

Stefan Freyr (stefan-freyr) wrote :

Ok, so this doesn't seem to be that simple really.

First of all, mostly for my own referencing in the future let me describe what I did exactly.

To upgrade kde-workspace:

1) Downloaded all of the .deb files from the link above with the following command:
wget -r -A.deb --no-directories https://launchpad.net/ubuntu/+source/kde-workspace/4:4.9.0-0ubuntu4/+build/3762859

2) Ran the following script to install only the packages that are already installed on my system:
pl= ; for a in *.deb ; do p=$(dpkg-deb --info $a | sed -n 's/Package: \(\S*\)/\1/p') ; i=$(dpkg -s $p 2>/dev/null |grep Status) ; pl="$pl $a" ; done ; sudo dpkg -i $pl

This resulted in some errors. The full output is here (http://paste.ubuntu.com/1285546/) but in short the errors were some missing dependencies that I could get around by installing the packages needed (a bit weird though why the dependency changed but that's a different conversation).

But after installing the needed packages, I'm getting a version conflict for kde-workspace-data. It turns out that there is no 4.9.0 package for that for some reason and kde-workspace-bin cannot be installed because of that. Can anyone tell me where I could get my hands on kde-workspace-data_4.9.0-0ubuntu4_amd64.deb?

Rich Sezov (sezovr) wrote :

I left OpenGL enabled, and only changed the Qt Graphics Subsystem. All my desktop goodies are in place, so far.

Stefan Freyr (stefan-freyr) wrote :

Ahh.. so you mean you changed that from "Native" to "Raster"? (not Render)

Rich Sezov (sezovr) wrote :

Just so you know, I'm not trying to take away from the real (and hard) work you're doing on this issue: it is a bug, plain and simple, and it needs to be fixed. I'm just offering a workaround for those of us who may have installed the beta on our main machines, since we were so close to the release. :-)

My effects are still slow, but the glitchy windows aren't preventing me from getting work done anymore. Very much looking forward to the proper resolution of this issue, and I wish I knew more about KDE development so that I could be of help. Thanks for your efforts!

Rich Sezov (sezovr) wrote :

Did I say Render (yes I did)? Yes, I meant Raster. That seems to have at least gotten rid of the screen corruption, though the effects are still slow.

Stefan Freyr (stefan-freyr) wrote :

Ok so I managed to get through my dependency woes. I figured out that there are two packages that are architecture agnostic and those .deb files are only on the i386 files so I got the kde-workspace and kde-workspace-data .deb files from there and all is now good.

So now I have kde-workspace 4.9.0 and mesa 9.0 installed and I can verify that the desktop effects are still very slow. I haven't seen the rendering artifacts (the white lines as in the screenshot attached to this bug) however but those appear sporadically so I can't say for sure that they're gone or whether they just haven't appeared for me.

I will take a look at downgrading mesa step by step next. Will report back.

Stefan Freyr (stefan-freyr) wrote :

I installed Mesa 9.0 20120903 from https://launchpad.net/ubuntu/quantal/+source/mesa/9.0~git20120903.e1673d20.is.git20120821.c1114c61-0ubuntu1 and I experience the same slowness and artifacts on that.

So I won't try the other git snapshots since the bug was clearly introduced before 03.09.2012.

Stefan Freyr (stefan-freyr) wrote :

There is a bug report on this in the KDE bug tracker as well:
https://bugs.kde.org/show_bug.cgi?id=308385

Changed in kdebase-workspace:
importance: Unknown → High
status: Unknown → New
Changed in mesa:
importance: Unknown → High
status: Unknown → Confirmed
68 comments hidden view all 148 comments

(In reply to comment #16)
> Unfortunately, I can't seem to reproduce this: I also have KDE 4.9.2 and
> Mesa 9.0, but it appears to work fine for me.

My knowledge about mesa and opengl is very limited so sorry about my terminology.

To reproduce this bug you must use kwin_gles (http://blog.martin-graesslin.com/blog/2011/07/running-kwin-with-opengl-es-2-0/).
Using gentoo try set USE flags "gles -opengl" at kwin package.
With kwin default (i think it is call backend) opengl everything is ok.

Like I said in https://bugs.freedesktop.org/show_bug.cgi?id=55856 this not happen in mesa-9.0_pre20120918.

Until friday I'm not able to bisect mesa to find a commit that cause regression.
If nobody bisect mesa I will try.

Created attachment 69265
Bisect log (Kayden)

I managed to reproduce this after all.

Steps to reproduce:
1. Enable KWin's "Show FPS" counter plugin.
2. Configure the "Present Windows" effect to one of the screen corners.
3. Mash that repeatedly and watch the FPS counter.

On HD 4000, a good version of Mesa results in perhaps ~55-60 FPS. Bad Mesa can be as low as 17 FPS, often mid-30s.

I also went ahead and bisected it (the log is attached).

e943e5c291c5f4c017f9f5a483f1940313333fc3 is the first bad commit
commit e943e5c291c5f4c017f9f5a483f1940313333fc3
Author: Chad Versace <email address hidden>
Date: Thu Aug 2 17:13:17 2012 -0700

    intel: Advertise multisample DRI2 configs on gen >= 6

    This turns on window system MSAA.

So in other words, it looks like KDE is using multisampling now, whereas it didn't before. Our implementation of that may not be optimal, and may have bugs, but it will always be far slower than single sampling.

My next question would be: how can one disable the use of MSAA in KWin or Plasma? I don't see an option for that, but I would be really surprised if there wasn't one...

> intel: Advertise multisample DRI2 configs on gen >= 6

i can reproduce this bug on Gen4 (Lenovo T61).

>Author: Chad Versace <email address hidden>
>Date: Thu Aug 2 17:13:17 2012 -0700

strange because on my system with mesa-9.0_pre20120918 everything is ok (3 times downgrade mesa to be sure on my system)

wojtek, your issue with GLES is also reproducible on nouveau and radeon drivers. Your issue is not duplicate of this bug.

(In reply to comment #19)
> e943e5c291c5f4c017f9f5a483f1940313333fc3 is the first bad commit
> commit e943e5c291c5f4c017f9f5a483f1940313333fc3
> Author: Chad Versace <email address hidden>
> Date: Thu Aug 2 17:13:17 2012 -0700
>
> intel: Advertise multisample DRI2 configs on gen >= 6
>
> This turns on window system MSAA.
>
> So in other words, it looks like KDE is using multisampling now, whereas it
> didn't before. Our implementation of that may not be optimal, and may have
> bugs, but it will always be far slower than single sampling.
>
> My next question would be: how can one disable the use of MSAA in KWin or
> Plasma? I don't see an option for that, but I would be really surprised if
> there wasn't one...

The algorithm that chooses the FBConfig doesn't check the values of GLX_SAMPLES and GLX_SAMPLE_BUFFERS, so I guess it ends up picking an MSAA config purely by accident. That's something we'll have to fix in KWin.

But unfortunately that also means that there is no way to enable or disable the use of MSAA right now.

Ouch. Well...in that case, I'm not sure what to do on the Mesa side...perhaps a point release of KWin could fix this?

For what it's worth, KWin from git master has the slowdown with the GLX backend, but appears to work well with the EGL backend. I imagine that's because it uses eglChooseConfig, and doesn't request any samples, so Mesa gives it a proper non-MSAA config. It's just with GLX, where KWin rolls its own algorithm, that there's a problem.

> The algorithm that chooses the FBConfig doesn't check the values of
> GLX_SAMPLES and GLX_SAMPLE_BUFFERS, so I guess it ends up picking an MSAA
> config purely by accident. That's something we'll have to fix in KWin.
>
> But unfortunately that also means that there is no way to enable or disable
> the use of MSAA right now.

Usually implementations choose the first config that matches its main criteria (just alpha, red, green, and blue for basic apps)

Are the MSAA configs at the top of the list?

The spec. has ordering rules for each attribute and the order for EGL_SAMPLES is accending...

I've pushed a patch to KWin that should fix the problem. The patch is in both master and the 4.9 branch, so you should see it in 4.9.3. That release will be tagged on Thursday.

@Rune: The GLX backend in KWin uses glXGetFBConfigs(), so the ordering rules in the spec don't apply here. I've thought about rewriting that code to use glXChooseFBConfig(), but I'm reluctant to touch working code without a good reason. This bug might be enough of a reason to do that though.

(In reply to comment #25)
> I've pushed a patch to KWin that should fix the problem. The patch is in
> both master and the 4.9 branch, so you should see it in 4.9.3. That release
> will be tagged on Thursday.

Thanks Fredrik! Based on that, I'm closing this as RESOLVED/NOTOURBUG.

> @Rune: The GLX backend in KWin uses glXGetFBConfigs(), so the ordering rules
> in the spec don't apply here. I've thought about rewriting that code to use
> glXChooseFBConfig(), but I'm reluctant to touch working code without a good
> reason. This bug might be enough of a reason to do that though.

@Rune: Feel free to double check by running glxinfo, but I believe the ordering is correct: multisample configs are always sorted later, as required.

Using glXChooseFBConfig() does seem like a good idea...could guard against future problems (though I don't know what), and should simplify the code a fair bit. Also, KWin's EGL backend uses eglChooseConfig() and it never had this problem. That would also make the GLX and EGL backends more similar.

Thanks again.

2 comments hidden view all 148 comments

Just to be clear. I was talking about the non-gles version of Kwin when testing. Don't know if a bug report should be created specifically for the MSAA bug which seems to be what caused the screen corruption as well as slowdown in kwin standard OpenGL.

The slowdown gone, but I have screen freeze issue now. Like, the screen is not always updated and if you click somewhere you think nothing happened but if you minimize and restore window, you see that click worked.

2 comments hidden view all 148 comments

Okay, Arch Linux has now put out...

kdebase-workspace 4.9.2-6

Which I guess has this patch applied. My system is now all up-to-date and there are no more Artifacts or slow down. However, the Tarring line is still there.

For me, this fixes slowdown which I wrote in the first message. There is 2 other bugs: screen corruption with gles and incorrect screen repainting with gl. And I don't know if it's MESA or KDE bugs.

Changed in mesa:
status: Confirmed → Won't Fix
Changed in kde-workspace (Ubuntu):
importance: Undecided → High
8 comments hidden view all 148 comments

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

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

6 comments hidden view all 148 comments
Alex Slepoy (alexz75) wrote :

Looks like possible workaround, at least I've no artifacts now on my Lenovo T430S :
1. Add ppa https://launchpad.net/~oibaf/+archive/graphics-drivers/
2. apt-get upgrade
3. Removing /etc/X11/xorg.conf if exists
:)

11 comments hidden view all 148 comments

(In reply to comment #21)
> wojtek, your issue with GLES is also reproducible on nouveau and radeon
> drivers. Your issue is not duplicate of this bug.

git bisect bad
e1cb50b15dbb75d1ba0fe184d05be7d302b058ee is the first bad commit
commit e1cb50b15dbb75d1ba0fe184d05be7d302b058ee
Author: Robert Bragg <email address hidden>
Date: Tue Sep 18 16:10:03 2012 +0100

    SwapBuffersRegionNOK: invert rectangles on y axis

    The EGL_NOK_swap_region2 spec states that the rectangles are specified
    with a bottom-left origin within a surface coordinate space also with a
    bottom left origin, so this patch ensures the rectangles are flipped
    before passing them on to dri2_copy_region.

    Fixes piglit's egl-nok-swap-region test.

    Tested-by: Matt Turner <email address hidden>
    (cherry picked from commit 0a523a8820e8a2549ac1c7887eb1892b228af44b)

this commit introduced regression on my system (kwin_gles)
I'll reopen https://bugs.freedesktop.org/show_bug.cgi?id=55856

3 comments hidden view all 148 comments
6 comments hidden view all 148 comments
Robert Hooker (sarvatt) on 2012-11-07
Changed in mesa (Ubuntu):
assignee: nobody → Robert Hooker (sarvatt)
importance: Undecided → Medium
milestone: none → precise-updates
Robert Hooker (sarvatt) on 2012-11-07
Changed in mesa (Ubuntu):
milestone: precise-updates → quantal-updates
Rich Sezov (sezovr) wrote :

@sarvatt: Does this mean there's an update now in Quantal? Because I (temporarily) went back to Precise to avoid this issue.

Thiago Martins (tcmartins) wrote :

@Sezov: Well, 4.9.3 packages should be right around the corner (I'd give it a week). It's supposed to be fixed in 4.9.3.

Thiago Martins (tcmartins) wrote :

Heh, I spoke too soob, 4.9.3 packages are out on the kubuntu-ppa. I just installed it along with mesa9 and kwin is compositing with opengl at 60 fps with no artifacts.

3 comments hidden view all 148 comments
Augie DeHainaut (augied) wrote :

4.9.3 from the kubuntu-ppa seems to fix things for me too. Thanks everyone.

Robert Hooker (sarvatt) wrote :

Yeah it's fixed in kwin 4.9.3, which was uploaded to raring recently. It'll be SRUed to quantal "very soon now". The mesa task I targetted is for another issue with the screen not updating that'll be fixed in mesa 9.0.1

Stefan Freyr (stefan-freyr) wrote :

I confirm.

Upgrading to KDE 4.9.3 fixed the slow FPS and the artifacts I was experiencing.

9 comments hidden view all 148 comments

Thanks Robert!
Can you backport this so it gets included in the next 9.0.1 release?

7 comments hidden view all 148 comments

The slowdown is gone for me except in fullscreen HD videos (either VLC or flash - 720p+). I am quite sure this is a KWin bug because I tried downgrading to Mesa 8.0.4 (which was working fine before) and I experienced the same issues. So it is something in the 4.9.2 -> 4.9.3 transition (perhaps even the above patch).

I also noticed that low resolution videos (480p) play smoothly, as well as the HD videos but only when not viewed fullscreen.

Mesa: 9.0
KDE: 4.9.3
Linux: 3.6.6
Intel Driver: 2.20.12
Intel HD Graphics 4000

(In reply to comment #37)

> I also noticed that low resolution videos (480p) play smoothly, as well as
> the HD videos but only when not viewed fullscreen.

"kcmshell4 kwincompositing", last tab. is "suspend compositing for fullscreen windows" checked? Do they play faster if you suspend compositing altogether?

(In reply to comment #38)
> (In reply to comment #37)
>
> > I also noticed that low resolution videos (480p) play smoothly, as well as
> > the HD videos but only when not viewed fullscreen.
>
> "kcmshell4 kwincompositing", last tab. is "suspend compositing for
> fullscreen windows" checked? Do they play faster if you suspend compositing
> altogether?

It is not checked, with KDE 4.9.2 + Mesa 8.0.4 it worked fine unchecked.

Checking it and/or disabling effects altogether caused VLC to play smoothly fullscreen.

Flash remained unaffected either way (it doesn't simply slow down, it fails to expand the video fullscreen and freezes the video).

Iff at all, rather
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=9364f5a7579567f5ebcf537eccf6147416e0e7e0
or maybe
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=55a2f19c8a41d9b3d13d69d7769999daf5730414

- Can you check reverting the commits?

- Sure the intel driver (xf86-video-intel) / flash / vlc/libav didn't change between "works" and "works not"?

This:
"Flash remained unaffected either way (it doesn't simply slow down, it fails to expand the video fullscreen and freezes the video)."
Smells suspicious, since with suspended compositing, kwin is actually out of game here.

- I tried reverting the commits each alone and together and the result is that the first commit introduced the VLC slowdown.

- Checking my logs, there was a google-chrome update along with KDE 4.9.3. It could be that the flash issues are totally unrelated (I am using the built-in flash player).

Just for reference:
Reverting commit 1+2: VLC is OK, Flash freezes
Reverting commit 1: VLC is OK, Flash freezes
Reverting commit 2: VLC is slow, Flash freezes

Suspending the effects for fullscreen windows stops the VLC slowdown but when another window pops up (e.g. KMix's volume indicator) it becomes sluggish again. Suspending the effects altogether produces no slowdown at all.

Yep, I can confirm that the flash issue is unrelated. External flash (11.2) works fine, please ignore the issue. Chrome 23 ships flash 11.5.

kwriteconfig --file kwinrc --group Compositing -- key GLStrictBinding true
qdbus org.kde.kwin /KWin reconfigure
then toggle compositing off / on (shift+alt+f12)

Completely suspend compositing in that case will however likely still get you the best overall performance.

@Fredrik:
the commit is not commented - what was the reason behind this (possibly related to a special driver version?)

Bryce Harrington (bryce) on 2012-11-13
Changed in mesa (Ubuntu):
status: Confirmed → Triaged
status: Triaged → In Progress

Just updated xf86-video-intel to 2.20.13 and get lags with mplayer -vo gl fullscreen without suspending compositing for fullscreen windows. It happens only with SNA. Everything is fine with UXA.

1 comments hidden view all 148 comments

(In reply to comment #43)
> @Fredrik:
> the commit is not commented - what was the reason behind this (possibly
> related to a special driver version?)

With DRI2 drivers there is no need to rebind the window pixmap to the texture every time the window is damaged. The texture and the pixmap reference the same memory buffer.

This commit has no effect on the GLES backend however, since it always enables loose binding unconditionally.

@Konstantinos: are you actually running kwin_gles?

No, standard OpenGL.

Robert Hooker (sarvatt) on 2012-12-10
Changed in kde-workspace (Ubuntu):
status: Confirmed → Fix Released
Robert Hooker (sarvatt) on 2013-04-10
Changed in mesa (Ubuntu):
assignee: Robert Hooker (sarvatt) → nobody
status: In Progress → Triaged

The original bug is fixed with commit in comment #29, thus closing.

Regarding the video slowdown / other issues regarding non-strict binding, please check whether this is still an issue (see comment #43 and set it "false" instead of "true") and file a new bug in case.

Thanks everyone.

Changed in kdebase-workspace:
status: New → Fix Released
Oibaf (oibaf) on 2013-07-25
Changed in mesa (Ubuntu):
status: Triaged → Invalid
Tommy_CZ (t-kijas) wrote :

I can confirm it in KDE4.8.5, Ubuntu 12.04 and latest saucy-enablement-stack (xorg).
I had to downgrade mesa to original precise version.

Displaying first 40 and last 40 comments. View all 148 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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