View Issue Details

IDProjectCategoryView StatusLast Update
0000987Ecere SDKgui/gfx-driver:x11public2013-08-29 00:07
Reporterjerome Assigned Tojerome  
PriorityimmediateSeveritymajorReproducibilityhave not tried
Status closedResolutionno change required 
Product Version0.44.08 
Target Version0.44.09 
Summary0000987: Visual updates are 1 frame behind
DescriptionOriginally 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.
TagsNo tags attached.



2013-08-25 08:15

administrator   ~0001008

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


2013-08-25 08:19

administrator   ~0001009

Last edited: 2013-08-25 08:25

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.


2013-08-28 20:06

administrator   ~0001023

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


2013-08-28 20:13

administrator   ~0001024

Potentially related bugs filed on Ubuntu:


2013-08-28 20:16

administrator   ~0001025

Something the compositors / WM should use ?


2013-08-28 23:47

administrator   ~0001026

Bug filed with Compiz


2013-08-29 00:07

administrator   ~0001027

Found Work Around:

- Install compizconfig-settings-manager.
- Run 'ccsm'.
- Goto Utility->Workarounds->Force full screen redraws (buffer swap) on repaint

Just like for

Issue History

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