View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000987 | Ecere SDK | gui/gfx-driver:x11 | public | 2013-08-25 05:07 | 2013-08-29 00:07 |
| Reporter | jerome | Assigned To | jerome | ||
| Priority | immediate | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Platform | X11 | ||||
| Product Version | 0.44.08 | ||||
| Target Version | 0.44.09 | ||||
| Summary | 0000987: Visual updates are 1 frame behind | ||||
| Description | Originally noticed that in GNOME, but now it's happening in Ubuntu Saucy/Unity | ||||
| Steps To Reproduce | - Bring up the IDE (it starts up maximized) - Open the ide.epj through File/Recent Projects - Right click on a project and hover over the 'Build' option. Notice that when you hover over the next item, you're always one frame behind. | ||||
| Tags | No tags attached. | ||||
|
|
Reproduced with nVidia driver on laptop with: - Unity - Gnome Classic - Gnome Flashback with Effects Does not seem to happen on Gnome Flashback without Effects Strange thing happens on Gnome Flashback with Effects: clicking on close button in top/left corner turns the title bar gray rather than closing the app |
|
|
Perhaps investigate if there are decoration values differences between Gnome Flashback with vs without effects? We could very well not be at fault for these though, so let's not waste too much time on it. |
|
|
so we're getting sort of this delayed update bug with X11, and I'm trying to determine if it's an nVidia driver bug we're rendering to a pixmap, and then right away doing an XCopyArea to the window... and the frame actually won't show up until the next visual update, and is always one frame behind... <aaronp> How are you rendering to the pixmap? aaronp: Xrender mostly XRenderFillRectangle() and the like <aaronp> hmm, weird. Xrender rendering happens in the same command stream as CopyArea. Are you making the calls using the same Display*? yes for sure. only one Display * <aaronp> This sounds familiar. You said you're not using a composite manager either, right? also it doesn't happen all the time, it's very intermitent aaronp: So I've tested this on Ubuntu Saucy (trying to get stuff ready for the release, quite late :S ) <aaronp> You don't have any Xid error messages in your system log, right? and it happens with Unity, Gnome Classic, Gnome FlashBack , but not with Gnome Flashback (No Effects) <aaronp> Does Gnome Classic use a compositor? <aaronp> It sounds likely that you're running into the classic GL-based compositor race condition, where the compositor reads the window's backing pixmap before the rendering to it has happened. well I believe all the ones with effects suffer from it, and might be using a compositor? I'm guessing it has effects / compositor <drago01> aaronp: gnome classic is gnome-shell with a set of extension enabled by default so yes <aaronp> It's a longstanding issue with GL-based compositors. The tools to fix it were added only fairly recently so I don't think any of them take advantage of them yet. <aaronp> They need to use the new sync fence stuff with GL interop. <aaronp> ESphynx, the compositors are buggy. aaronp: Is there a logged bug? Should we report that? that's sort of a 'major' usability problem <aaronp> OpenGL only guarantees that rendering will reach the destination eventually unless you call glFinish or glXWaitGL, which stalls the CPU until the GL server is done with the rendering, which is obviously suboptimal. <aaronp> The new fence sync stuff allows you to make GL wait for X rendering inside the GL server (i.e. the GPU) rather than waiting on the CPU. aaronp: but we can do this from our X11 app? <aaronp> No, the compositor has to do it. <aaronp> The problem is that your XCopyArea rendering request triggers a Damage event to the compositor, which the server sends immediately after it submits the rendering to the GPU. aaronp: So should be doing anything regarding that wm-sync thing? <aaronp> No. Almost all of the DEs installed with Ubuntu suffer from this thing, how can I ramp up the pressure to fix this? Unless if we select Gnome Flashback (No Effects), which is like going back 10 years in time to GNOME 2.x <aaronp> Well, maybe if you have multiple rendering requests and you want to batch them up into frames, but that still won't guarantee that the compositor race works out the right way. <aaronp> Maybe it'll help by delaying the compositor slightly. I tried some XFlush() , XSync() in there.. .but to no avail, still happens |
|
|
Potentially related bugs filed on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/888666 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861268 |
|
|
Something the compositors / WM should use ? http://fishsoup.net/misc/wm-spec-synchronization.html |
|
|
Bug filed with Compiz https://bugs.launchpad.net/compiz/+bug/1218116 |
|
|
Found Work Around: - Install compizconfig-settings-manager. - Run 'ccsm'. - Goto Utility->Workarounds->Force full screen redraws (buffer swap) on repaint Just like for https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861268 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-08-25 05:07 | jerome | New Issue | |
| 2013-08-25 05:07 | jerome | Status | new => assigned |
| 2013-08-25 05:07 | jerome | Assigned To | => redj |
| 2013-08-25 08:15 | jerome | Note Added: 0001008 | |
| 2013-08-25 08:19 | jerome | Note Added: 0001009 | |
| 2013-08-25 08:25 | jerome | Note Edited: 0001009 | |
| 2013-08-28 20:06 | jerome | Note Added: 0001023 | |
| 2013-08-28 20:13 | jerome | Note Added: 0001024 | |
| 2013-08-28 20:16 | jerome | Note Added: 0001025 | |
| 2013-08-28 23:47 | jerome | Note Added: 0001026 | |
| 2013-08-28 23:47 | jerome | Status | assigned => feedback |
| 2013-08-28 23:47 | jerome | Target Version | 0.44.09 => |
| 2013-08-28 23:48 | jerome | Assigned To | redj => |
| 2013-08-29 00:06 | jerome | Status | feedback => assigned |
| 2013-08-29 00:06 | jerome | Assigned To | => jerome |
| 2013-08-29 00:07 | jerome | Status | assigned => closed |
| 2013-08-29 00:07 | jerome | Note Added: 0001027 | |
| 2013-08-29 00:07 | jerome | Resolution | open => no change required |
| 2013-08-29 00:07 | jerome | Target Version | => 0.44.09 |
