Granite based apps cause massive slowdown in maximized mode on intel GPU

Bug #1458612 reported by LeetMiniWheat
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Files
Invalid
Undecided
Unassigned
Granite
New
Undecided
Unassigned
Terminal
New
Undecided
Unassigned

Bug Description

1. What you expected to happen

apps such as terminal, files, etc should render fast in maximized mode like they do in normal mode.

2. What actually happened

apps render extremely slow when in fullscreen or maximized mode. they render fast when ALMOST maximized but not fully maximized, thus I don't believe it's an issue of slow GPU unable to keep up.

3. If possible, a minimal series of steps necessary to make it happen, where step 1 is "start the program"

open terminal, do something that scrolls text very fast such as "cat /var/syslog" or "dmesg", then do the same in maximized or fullscreen mode. or open Files with a large directory and scroll down very fast.

Other info:

I'm reporting this against granite because I can't think of any other shared libraries that could cause this. It's not gala because these same apps lag in cinnamon too (using muffin, a fork of mutter). Tested on ElementaryOS and Linux Mint. CSD could somehow be related too but I don't think so, since gnome-terminal with CSD enabled scrolls fast as expected, so does xfce4-terminal, and Nemo.

Hardware this affects:

Intel GPUs (currently on first intel HD graphics with gen1 core i5 (i5 430M)). Possibly later revisions too? using the latest xorg-video-intel from eOS PPA.

Other hardware tested:

Issue does not occur when tested with NVIDIA GeForce 8400m GS on another laptop with nvidia-331 proprietary drivers.

Solutions attempted:

Changed various settings and tested many options for intel i915 xorg driver by creating a /usr/share/X11/xorg.conf.d/20-intel.conf but none helped. currently it contains this:
Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "TearFree" "true"
   Option "Tiling" "true"
   Option "SwapbuffersWait" "true"
   Option "AccelMethod" "sna"
EndSection

Other solutions attempted:

tried various module options, such as disabling power savings in kernel cmdline:
acpi_enforce_resources=lax i915.use_mmio_flip=1 i915.fastboot=1 i915.powersave=0 i915.disable_vtd_wa=1 i915.enable_rc6=0 i915.enable_fbc=0

tested with and without CLUTTER_VBLANK=True

tested with kernel 3.16, 3.19, and 4.0.4 with lts-utopic hardware enablement stack.

Issue still persists across most (all?) eOS apps, regardless of desktop environment it seems. I even tried disabling compositing on fullscreen in cinnamon settings as a test. gala doesn't appear to have this functionality. I haven't tested it in a light WM such as openbox or lightweight compositors such as compton.

description: updated
description: updated
description: updated
Changed in pantheon-files:
status: New → Incomplete
Revision history for this message
Jeremy Wootten (jeremywootten) wrote :

I cannot reproduce this bug in Files 0.2.4 r1980 using the tests you described with Files and Terminal.

Granite version 0.3.1+r889+pkg84~daily~ubuntu0.3.1.1
Gala version 0.2.0~r481+pkg32~ubuntu0.3.1.1
Intel I5-4210M processor
Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)

Please confirm whether you experience this bug in the latest stable version of Files/Granite/Gala.

tags: added: fullscreen slow
Revision history for this message
LeetMiniWheat (white-phoenix) wrote :

Thanks for looking into this, It may take me awhile to be able to test this again since eOS is on another machine now but I'll report back as soon as I can. I have a feeling it's some sort of GPU-specific bug on early intel graphics chips when the app/wm attempts to render in some strange fashion. It only seemed to affect eOS apps that use granite though but it could be other things too.

Revision history for this message
Jeremy Wootten (jeremywootten) wrote :

Marked as invalid as it does not seem to be a specifically Files bug.

Changed in pantheon-files:
status: Incomplete → Invalid
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.