InitialPixmapPlacement question


Before doing all sorts of debugging and making logs, I wanted to ask whether there’s a known issue with InitialPixmapPlacement setting.

De default seem to be set to 2, but I am experiencing problems with tabs not appearing when I click them. Sometimes there’s just a delay but other times the tab doesn’t appear at all until I move my mouse. Once I move my mouse into the area not being drawn, it suddenly paints that tab.

When I set InitialPixmapPlacement=0 on X startup (or from a console) this problem dissapears completely but I notice some occasional slowness (which is not too bad).

Is it useful to go through the debugging thing and deliver a log?


Hi pedro_ii,

Which desktop environment are you using? This sounds like the typical race condition that occurs with composite managers that don’t properly synchronize their rendering with the X server. Changing InitialPixmapPlacement likely just perturbs the timing enough to cause the outcome of the race to change.

Thanks Aaron,

Cinnamon 2 on Arch Linux.

Is there anything I can do besides changing that setting to 0? One of the effects is that scrolling in a browser stutters, that sounds like its not a big deal (that’s what I thought initially) but it gets annoying after a while.

I could live with the setting on 2 were it not for the fact that typing is also affected. Text appears lagging behind and sometimes backspacing isn’t shown at all until I move my mouse over the text or start typing something blindly as I can’t see where my cursor is.

I’m not familiar with Cinnamon, but it looks like it’s based on gnome-shell. As far as I know, there are no patches to the gnome-shell / mutter / clutter compositing framework that fix the problem. I would suggest filing a bug in Cinnamon’s bug tracker. You can point them at the Compiz version of the patch for reference:

Thanks for the quick help, apreciated.

Thanks for sharing that patch[1]. I ported it to mutter and while it does fix the issue reported here I’m also seeing some pretty bad side-effects.

Sometimes I get pretty long stalls where nothing on the screen updates and at some points even the mouse pointer stops responding. When this happens, top (running under ssh) shows either the gnome-shell process at 100% cpu usage or the migration kernel threads at 100% cpu usage. Less often, it’s the X server hogging the cpu.

If I attach gdb to gnome-shell when this happens and get a backtrace, I mostly get one of these two traces:

#0  0x00007fb41fb25a8d in poll () from /lib64/
#1  0x00007fb4178f54bd in ?? () from /lib64/
#2  0x00007fb4144d9e58 in ?? () from /lib64/
#3  0x00007fb41441e2ee in ?? () from /lib64/
#4  0x00007fb4178ec822 in ?? () from /lib64/
#5  0x00007fb4178c638e in glXSwapBuffers () from /lib64/
#6  0x00007fb4243227bb in _cogl_winsys_onscreen_swap_buffers_with_damage (onscreen=0x286a3b0, rectangles=<optimized out>, n_rectangles=<optimized out>)
    at winsys/cogl-winsys-glx.c:1968
#7  0x00007fb424317bce in cogl_onscreen_swap_buffers_with_damage (onscreen=<optimized out>, rectangles=<optimized out>, n_rectangles=<optimized out>)
    at ./cogl-onscreen.c:282
#8  0x00007fb424317c79 in cogl_onscreen_swap_buffers (onscreen=<optimized out>) at ./cogl-onscreen.c:310
#9  0x00007fb4249d0332 in clutter_stage_cogl_redraw (stage_window=0x21bb370) at cogl/clutter-stage-cogl.c:657
#10 0x00007fb424a3bea3 in clutter_stage_do_redraw (stage=0x27d8080) at ./clutter-stage.c:1214
#11 _clutter_stage_do_update (stage=0x27d8080) at ./clutter-stage.c:1272
#12 0x00007fb424a21bc8 in master_clock_update_stages (master_clock=0x274ccc0, stages=0x8691500) at ./clutter-master-clock.c:457
#13 clutter_clock_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./clutter-master-clock.c:589
#14 0x00007fb4214452a6 in g_main_context_dispatch () from /lib64/
#15 0x00007fb421445628 in g_main_context_iterate.isra.24 () from /lib64/
#16 0x00007fb421445a3a in g_main_loop_run () from /lib64/
#17 0x00007fb425460be8 in meta_run () at core/main.c:556
#18 0x0000000000402131 in main ()


#0  0x00007fda4627ec39 in ?? () from /lib64/
#1  0x00007fda4627ec73 in ?? () from /lib64/
#2  0x00007fda42ebcbbc in ?? () from /lib64/
#3  0x00007fda42ebcc6b in ?? () from /lib64/
#4  0x00007fda42eab7a1 in ?? () from /lib64/
#5  0x00007fda42eac75a in ?? () from /lib64/
#6  0x00007fda42ec5f67 in ?? () from /lib64/
#7  0x00007fda42daf67c in ?? () from /lib64/
#8  0x00007fda42e855c2 in ?? () from /lib64/
#9  0x00007fda42e4c8ab in ?? () from /lib64/
#10 0x00007fda42a96a81 in ?? () from /lib64/
#11 0x00007fda42a9731a in ?? () from /lib64/
#12 0x00007fda52c69b16 in _cogl_framebuffer_gl_read_pixels_into_bitmap (framebuffer=0x1be0ba0, x=615, y=1060, source=COGL_READ_PIXELS_COLOR_BUFFER, bitmap=0x6439180, 
    error=0x7fff2842d930) at driver/gl/cogl-framebuffer-gl.c:1463
#13 0x00007fda52ca72a8 in _cogl_framebuffer_read_pixels_into_bitmap (framebuffer=0x1be0ba0, x=615, y=19, source=COGL_READ_PIXELS_COLOR_BUFFER, bitmap=0x6439180, 
    error=0x7fff2842d930) at ./cogl-framebuffer.c:1508
#14 0x00007fda52ca7427 in cogl_framebuffer_read_pixels_into_bitmap (framebuffer=<optimized out>, x=x@entry=615, y=y@entry=19, 
    source=source@entry=COGL_READ_PIXELS_COLOR_BUFFER, bitmap=bitmap@entry=0x6439180) at ./cogl-framebuffer.c:1523
#15 0x00007fda52c782c4 in cogl_read_pixels (x=615, y=19, width=1, height=1, source=COGL_READ_PIXELS_COLOR_BUFFER, format=COGL_PIXEL_FORMAT_RGBA_8888_PRE, 
    pixels=0x7fff2842d9f0 "77777777") at ./cogl.c:336
#16 0x00007fda533ce991 in _clutter_stage_do_pick (stage=stage@entry=0x1bf0060, x=615, y=19, mode=mode@entry=CLUTTER_PICK_REACTIVE) at ./clutter-stage.c:1528
#17 0x00007fda533a702e in _clutter_input_device_update (device=device@entry=0x15c22a0, sequence=sequence@entry=0x0, emit_crossing=emit_crossing@entry=0)
    at ./clutter-input-device.c:899
#18 0x00007fda533b0e75 in _clutter_process_event_details (context=0x1554780, event=0x4599170, stage=0x1bf0060) at ./clutter-main.c:2453
#19 _clutter_process_event (event=event@entry=0x4599170) at ./clutter-main.c:2777
#20 0x00007fda533cb080 in _clutter_stage_process_queued_events (stage=0x1bf0060) at ./clutter-stage.c:1070
#21 0x00007fda533b2b28 in master_clock_process_events (master_clock=0x1b62cc0, stages=<optimized out>) at ./clutter-master-clock.c:366
#22 clutter_clock_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./clutter-master-clock.c:583
#23 0x00007fda4fdd62a6 in g_main_context_dispatch () from /lib64/
#24 0x00007fda4fdd6628 in g_main_context_iterate.isra.24 () from /lib64/
#25 0x00007fda4fdd6a3a in g_main_loop_run () from /lib64/
#26 0x00007fda53df1be8 in meta_run () at core/main.c:556
#27 0x0000000000402131 in main ()

It’s quite likely that I’m doing something wrong but at this point I’m running out of ideas to debug this further, so if you have any insight you can share it’d be great.

[1] BTW, this patch doesn’t seem to be present in compiz’ master branch, why? Do you know of any other compositor making use of this feature?

We found out why the patch wasn’t working: gnome-shell doesn’t redraw only when it gets X damage events, and when we draw one of those frames we can’t insert the fence since it won’t be triggered.

The patch in is now working fine for me.

Hi rtcm,

Thanks for your work on this, it sounds promising. Do you know which version of Mutter it is included with and whetherh Cinnamon is already patched or not?


It’s not included in mutter yet and I don’t know when it will be since I found an issue with it and am waiting for a reply from NVIDIA. See .

I can’t comment on inclusion in cinnamon or any downstream distro.

Thanks again.

Can I see on that bugzilla page when it is solved or will you update here as well when there is a solution?

You can subscribe to the bug in bugzilla. It will definitely be updated when the patches get pushed.