Some flashes appears when a window is resized

Bug #437378 reported by Matthieu Baerts on 2009-09-26
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Cairo-Dock Core
Medium
Matthieu Baerts
KDE Base
Invalid
Medium
Metacity
New
Medium
metacity (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: metacity

Hello,

I'm part of the Cairo-Dock team. Cairo-Dock is a dock using Cairo/OpenGL backend. It needs a composite support and it works almost well with Metacity. There is just one problem : some flashes appear (often) and the dock is moved quickly when the window used by Cairo-Dock is resized. In fact Cairo-Dock resizes its window when the dock is active.
Can you have a look to this screencast? http://videobin.org/+fx/if.html

It seems that it's an old bug but sorry for that, we have never report this bug here. I have tested on Gnome 2.26 (Jaunty) and 2.28 (Karmic - just before my other computer breaks down :/ ). Mutter is also affected by this bug
This bug is much present now because the resizing is more used.

You can find all informations about the installation of Cairo-Dock there : http://www.cairo-dock.org/ww_page.php?p=Accueil&lang=en#0-Installation
Our project page on launchpad : https://launchpad.net/cairo-dock
Our source code : https://code.launchpad.net/cairo-dock

Thanks for your help and many thanks for your great project!

PS : Bug in Gnome Bugzilla : https://bugzilla.gnome.org/show_bug.cgi?id=596464

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: metacity 1:2.25.144-0ubuntu2.1
ProcEnviron:
 LANG=fr_BE.UTF-8
 SHELL=/bin/bash
SourcePackage: metacity
Uname: Linux 2.6.28-15-generic i686

Matthieu Baerts (matttbe) wrote :
Changed in cairo-dock-core:
assignee: nobody → Matthieu Baerts (matttbe)
importance: Undecided → Medium
status: New → Incomplete
description: updated
Fabounet (fabounet03) on 2009-10-06
Changed in cairo-dock-core:
status: Incomplete → Fix Committed
Matthieu Baerts (matttbe) wrote :

Just to precise that this fix in Cairo-Dock is a workaround !
This bug is still present in Metacity.

Changed in metacity (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Fabounet (fabounet03) on 2009-10-24
Changed in cairo-dock-core:
status: Fix Committed → Fix Released
Changed in metacity:
importance: Unknown → Medium
status: Unknown → New

Version: SVN (using KDE 4.5.4)
OS: Linux

https://bugs.launchpad.net/cairo-dock-core/+bug/697118

Kwin seems to do bad things with cairo dock windows...

All details in cairo-dock bug report.

Reproducible: Always

Matthieu Baerts (matttbe) wrote :

@ Cedric Bellegarde: is it possible to add "kdebase" as new affected project with a link to the KDE bug report?

Matthieu Baerts (matttbe) wrote :

I confirm that I've this bug with Metacity 2.30 too.

Fabounet has given more details:
   > to be more specific, I think the problem comes from the use of the
   > gdk_move_resize function, which resizes and moves the window at the same
   > time.
   > it just calls XMoveResize, and then the WM get the X message and do its job
   > (here, it probably does it in 2 times instead of 1).

Unless there is a specification saying that our behavior is wrong, I do
consider our behavior as valid and don't want to fix what is not broken.

Especially Cairo dock is known for compatibility issues and is not a common
application under Plasma.

The claimed assumption that kwin would set size and position independently if there's a combined configure request is (afaics) wrong, the geometry update is blocked in the configure request until everything's done (position/size/contrainment)

There /might/ rather be a relation to the "dirty texture" issue, however as Martin pointed we've had former reports on "cairodock + qt + opengl = weird issues", therefore

@Cédric
you should figure whether it does also happen with the xrender backend.

Cédric Bellegarde (gnumdk) wrote :

bugs appear with every window manager i test:
- metacity
- openbox
- kwin
- blackbox
- ...

Only working window manager is compiz so i guess bug is in cairo dock and not in window managers...

Here what kwin devs think about it:

"The claimed assumption that kwin would set size and position independently if
there's a combined configure request is (afaics) wrong, the geometry update is
blocked in the configure request until everything's done
(position/size/contrainment)"

And it works with compiz because compiz set size and position independently due to it plugin architecture...

the dock only uses a gdk_move_resize, so the bug would be in GDK, but I
don't think so.
for me, it's the WM's job to correctly handle a move+resize event. if Compiz
can do it, there is obviously a correct way to do it, don't you think so ?

2011/1/5 Bellegarde Cedric <email address hidden>

> bugs appear with every window manager i test:
> - metacity
> - openbox
> - kwin
> - blackbox
> - ...
>
> Only working window manager is compiz so i guess bug is in cairo dock
> and not in window managers...
>
> Here what kwin devs think about it:
>
> "The claimed assumption that kwin would set size and position independently
> if
> there's a combined configure request is (afaics) wrong, the geometry update
> is
> blocked in the configure request until everything's done
> (position/size/contrainment)"
>
> And it works with compiz because compiz set size and position
> independently due to it plugin architecture...
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to Cairo-Dock Core.
> https://bugs.launchpad.net/bugs/437378
>
> Title:
> Some flashes appears when a window is resized
>
> Status in Cairo-Dock : Core:
> Fix Released
> Status in KDE Base Components:
> Unknown
> Status in The Metacity Window Manager:
> New
> Status in “metacity” package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: metacity
>
> Hello,
>
> I'm part of the Cairo-Dock team. Cairo-Dock is a dock using Cairo/OpenGL
> backend. It needs a composite support and it works almost well with
> Metacity. There is just one problem : some flashes appear (often) and the
> dock is moved quickly when the window used by Cairo-Dock is resized. In fact
> Cairo-Dock resizes its window when the dock is active.
> Can you have a look to this screencast? http://videobin.org/+fx/if.html
>
> It seems that it's an old bug but sorry for that, we have never report this
> bug here. I have tested on Gnome 2.26 (Jaunty) and 2.28 (Karmic - just
> before my other computer breaks down :/ ). Mutter is also affected by this
> bug
> This bug is much present now because the resizing is more used.
>
> You can find all informations about the installation of Cairo-Dock there :
> http://www.cairo-dock.org/ww_page.php?p=Accueil&lang=en#0-Installation
> Our project page on launchpad : https://launchpad.net/cairo-dock
> Our source code : https://code.launchpad.net/cairo-dock
>
> Thanks for your help and many thanks for your great project!
>
> PS : Bug in Gnome Bugzilla :
> https://bugzilla.gnome.org/show_bug.cgi?id=596464
>
>
>
> ProblemType: Bug
> Architecture: i386
> DistroRelease: Ubuntu 9.04
> Package: metacity 1:2.25.144-0ubuntu2.1
> ProcEnviron:
> LANG=fr_BE.UTF-8
> SHELL=/bin/bash
> SourcePackage: metacity
> Uname: Linux 2.6.28-15-generic i686
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team<https://launchpad.net/%7Ecairo-dock-team>
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team<https://launchpad.net/%7Ecairo-dock-team>
> More help : https://help.launchpad.net/ListHelp
>

Fabounet (fabounet03) wrote :
Download full text (3.4 KiB)

can sonemone confirm it also occurs with the cairo backend (that's to say
the xrender one), using "cairo-dock -c" ?
thanks !

2011/1/5 Fabrice Rey <email address hidden>

> the dock only uses a gdk_move_resize, so the bug would be in GDK, but I
> don't think so.
> for me, it's the WM's job to correctly handle a move+resize event. if
> Compiz can do it, there is obviously a correct way to do it, don't you think
> so ?
>
> 2011/1/5 Bellegarde Cedric <email address hidden>
>
> bugs appear with every window manager i test:
>> - metacity
>> - openbox
>> - kwin
>> - blackbox
>> - ...
>>
>> Only working window manager is compiz so i guess bug is in cairo dock
>> and not in window managers...
>>
>> Here what kwin devs think about it:
>>
>> "The claimed assumption that kwin would set size and position
>> independently if
>> there's a combined configure request is (afaics) wrong, the geometry
>> update is
>> blocked in the configure request until everything's done
>> (position/size/contrainment)"
>>
>> And it works with compiz because compiz set size and position
>> independently due to it plugin architecture...
>>
>> --
>> You received this bug notification because you are a member of Cairo-
>> Dock Team, which is subscribed to Cairo-Dock Core.
>> https://bugs.launchpad.net/bugs/437378
>>
>> Title:
>> Some flashes appears when a window is resized
>>
>> Status in Cairo-Dock : Core:
>> Fix Released
>> Status in KDE Base Components:
>> Unknown
>> Status in The Metacity Window Manager:
>> New
>> Status in “metacity” package in Ubuntu:
>> Triaged
>>
>> Bug description:
>> Binary package hint: metacity
>>
>> Hello,
>>
>> I'm part of the Cairo-Dock team. Cairo-Dock is a dock using Cairo/OpenGL
>> backend. It needs a composite support and it works almost well with
>> Metacity. There is just one problem : some flashes appear (often) and the
>> dock is moved quickly when the window used by Cairo-Dock is resized. In fact
>> Cairo-Dock resizes its window when the dock is active.
>> Can you have a look to this screencast? http://videobin.org/+fx/if.html
>>
>> It seems that it's an old bug but sorry for that, we have never report
>> this bug here. I have tested on Gnome 2.26 (Jaunty) and 2.28 (Karmic - just
>> before my other computer breaks down :/ ). Mutter is also affected by this
>> bug
>> This bug is much present now because the resizing is more used.
>>
>> You can find all informations about the installation of Cairo-Dock there :
>> http://www.cairo-dock.org/ww_page.php?p=Accueil&lang=en#0-Installation
>> Our project page on launchpad : https://launchpad.net/cairo-dock
>> Our source code : https://code.launchpad.net/cairo-dock
>>
>> Thanks for your help and many thanks for your great project!
>>
>> PS : Bug in Gnome Bugzilla :
>> https://bugzilla.gnome.org/show_bug.cgi?id=596464
>>
>>
>>
>> ProblemType: Bug
>> Architecture: i386
>> DistroRelease: Ubuntu 9.04
>> Package: metacity 1:2.25.144-0ubuntu2.1
>> ProcEnviron:
>> LANG=fr_BE.UTF-8
>> SHELL=/bin/bash
>> SourcePackage: metacity
>> Uname: Linux 2.6.28-15-generic i686
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~cairo-dock-team<https://launchpad.net/...

Read more...

Cédric Bellegarde (gnumdk) wrote :

Can't confirm, cairo-dock is buggy with kwin and cairo... (dock disappear)

"Cairo dock is known for compatibility issues"
if you mean the issue that makes all applications having embedded video invisible when the dock is running, that has been proved to be a bug in Qt and is opened for 2 years. ;-)

apart from that, the dock runs fine in KDE (it just lacks a plug-in to access the KDE's VFS), except the flickering. When a window is configured by the app, (using a gdk_move_resize), shoudln't the WM be aware that it's a move+resize, and not a move followed by a resize ? after all, the XWindowChanges attributes contain both the size and position changes.
Currently, it seems that either
 - the dock's window is redrawn by the WM at its new position before it's resized
 - or (more likely) the WM uses the old window's content to draw the newly resized window.
So you see the window at a wrong position for a short time.

The correct way would be to receive 1 configure event so that the app knows its new size and content, and then 1 expose event so that the app redraws itself, and the WM should not redraw the window with the old content until this is done.

Do you think something like this can be achieved ? or do you see any workaround that could be implemented at the app level ?
Because anyway as it is right now, it can be considered as a bug.

Cédric Bellegarde (gnumdk) wrote :

I'm now quite sure that this bug is in cairo-dock...

If i replace gdk_window_move_resize() with just gdk_window_resize() (so, like this, dock don't move)

Here what happen then when an icon is closed:
- Dock resize itself
- Icon is remove
- Dock move to it original position !

So, this is the last move that do flickering...

With gtk_window_move_resize(), dock move at an invalid position and then go back to good position.

Cédric Bellegarde (gnumdk) wrote :

Same bug on icon creation:

dock move on right and then resize/move on left...

Cédric Bellegarde (gnumdk) wrote :

Same bug on icon creation:

dock move on right and then resize/move on left...

http://adishatz.1s.fr/~gnumdk/cairo-dock/00000157.png

http://adishatz.1s.fr/~gnumdk/cairo-dock/00000184.png

You will see bug on close (without gdk_window_move_resize()):
- 157 => Konsole closing, dock resizing
- 184 => dock have move on left

(In reply to comment #3)
> is opened for 2 years. ;-)
out of personal curiosity: link?

> (using a gdk_move_resize), shoudln't the WM be aware that it's a move+resize,
> and not a move followed by a resize ? after all, the XWindowChanges attributes
> contain both the size and position changes.

Did i recently start talking greece?
I don't know what gdk_move_resize actually does (google doesn't know it bug in related cairo-dock bug reports...) or whether cairo-dock is a managed (request) or unmanged (notify) client, but
   KWin does NOT make two XMoveResizeWindow calls out of one configure request
if the value mask contains ((x||y)&&(w||h))

If there's something "wrong" it has to be in the compositor / the behaviour of the xcomposite/xdamage extension (see my former post) or in OpenGL

Now* i did** install*** cairo-dock, and: "surprise" - NOT using the GL mode doesn't expose this problem at all, while it /is/ present in the GL mode, whether kwin uses the gl or the xrender backend....
-> it's probably in the cairo GL backend and/or a conflict with Qt similar to the one you mentioned above(?)

Then i suspended kwin compositing and launched xcompmgr (on kwin) - the issue apepars w/ or w/o gl in the docker. The glmode however also triggers

error 9: BadDrawable (invalid Pixmap or Window parameter) request 157 minor 1 serial 35709
error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 35710
error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 35711

in xcompmgr

From that time on kwin crashed in XRenderCreatePicture oni the XRender backend :-\
i'm gonna decide whether to blame cairo or xcompmgr later on... ;-P

---
* (what a shame)
** (because feeling forced, for no other reason)
*** (i'd like to state that i do NOT believe in dockers, DO NOT USE DOCKERS! NONE! - cairo dock makes a nice appearance, doesn't carry in a complete gnome desktop, but DO NOT USE DOCKERS, NEVER! =)

Fabounet (fabounet03) wrote :
Download full text (3.6 KiB)

hmm, I think we were talking of a different bug ^^
I was talking about the flickering we get when a window is move_resized
(this is a very brief flicker, and is most probably due to a bad refresh of
the window from the WM, the old window's content being drawn on the larger
window).
It's much harder to get this bug now, because I have reduced the number of
resizing to the minimum (that's why this bug is marked as "fixed" for us).

The bug you're talking about is different: it's clearly a miscalculation of
the icons positions when an icon is being removed, and it last few seconds
(the time the icon is decreasing to 0), and under any WM (Compiz included).
Actually this is a known bug (and it probably has its own bug report
already), so sorry I didn't understand correctly :-)

The flickering in Metacity is still a real bug afaik, but then I don't think
it affects KWin, so I'm going to remove them.

2011/1/5 Bellegarde Cedric <email address hidden>

> Same bug on icon creation:
>
> dock move on right and then resize/move on left...
>
> http://adishatz.1s.fr/~gnumdk/cairo-dock/00000157.png<http://adishatz.1s.fr/%7Egnumdk/cairo-dock/00000157.png>
>
> http://adishatz.1s.fr/~gnumdk/cairo-dock/00000184.png<http://adishatz.1s.fr/%7Egnumdk/cairo-dock/00000184.png>
>
> You will see bug on close (without gdk_window_move_resize()):
> - 157 => Konsole closing, dock resizing
> - 184 => dock have move on left
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to Cairo-Dock Core.
> https://bugs.launchpad.net/bugs/437378
>
> Title:
> Some flashes appears when a window is resized
>
> Status in Cairo-Dock : Core:
> Fix Released
> Status in KDE Base Components:
> Unknown
> Status in The Metacity Window Manager:
> New
> Status in “metacity” package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: metacity
>
> Hello,
>
> I'm part of the Cairo-Dock team. Cairo-Dock is a dock using Cairo/OpenGL
> backend. It needs a composite support and it works almost well with
> Metacity. There is just one problem : some flashes appear (often) and the
> dock is moved quickly when the window used by Cairo-Dock is resized. In fact
> Cairo-Dock resizes its window when the dock is active.
> Can you have a look to this screencast? http://videobin.org/+fx/if.html
>
> It seems that it's an old bug but sorry for that, we have never report this
> bug here. I have tested on Gnome 2.26 (Jaunty) and 2.28 (Karmic - just
> before my other computer breaks down :/ ). Mutter is also affected by this
> bug
> This bug is much present now because the resizing is more used.
>
> You can find all informations about the installation of Cairo-Dock there :
> http://www.cairo-dock.org/ww_page.php?p=Accueil&lang=en#0-Installation
> Our project page on launchpad : https://launchpad.net/cairo-dock
> Our source code : https://code.launchpad.net/cairo-dock
>
> Thanks for your help and many thanks for your great project!
>
> PS : Bug in Gnome Bugzilla :
> https://bugzilla.gnome.org/show_bug.cgi?id=596464
>
>
>
> ProblemType: Bug
> Architecture: i386
> DistroRelease: Ubuntu 9.04
> Package: metacity 1:2.25.144-0ubuntu2.1
> ProcEnviron:
> ...

Read more...

"KWin does NOT make two XMoveResizeWindow calls out of one configure request"
that's what I wanted to be sure.
so there shouldn't be any problem with it the move_resize* (as we have with Metacity).

Now about this bug, it appears that I misunderstood the bug reported by Cedric. It's actually a miscalculation in the position of the icons when one of them is being removed (there is an animation, the icon's size decreases to 0, and in some occasion the calculation is wrong). I'm surprised you didn't notice it in cairo-mode, but as this bug occurs in certain conditions, it's probably just a coincidence.
It's of course independant of the WM, and is different from the flickering I was thinking about (wrong refresh of the window during a move_resize, which is very brief).
So I apologize for taking your time, it's a wrong alert. ^^

About the bug in Qt, it's a serious one, and here is the link (please note that VLC and VirtualBox have included a (dirty) workaround to avoid Qt using an alpha channel in their visual). You can find bug reports here: http://bugreports.qt.nokia.com/browse/QTBUG-5464
http://bugreports.qt.nokia.com/browse/QTBUG-12315
http://bugreports.qt.nokia.com/browse/QTBUG-15092

although it (and its workaround) is very well known, they have just ignored the problem so far...

thanks for your concern and your reactivity !

PS: the KDE panel IS a dock ;-) if panel is for you a dock that doesn't move, then Cairo-Dock can also act like a panel.

* gdk_move_resize is a mere wrapper around XMoveResize.

(In reply to comment #5)
> cairo-mode, but as this bug occurs in certain conditions, it's probably just a
> coincidence.
Framerate/Sync issue?

> So I apologize for taking your time, it's a wrong alert. ^^
Nevermind, since it lead to a fix anyway, it was no waste =)

> About the bug in Qt, it's a serious one
Thanks for the links, i can however
a) not confirm the issue (though also style side ARGB + embeds now work here, X11 thing?)
b) not suggest using XLIB_SKIP_ARGB_VISUALS as a general hack because it will invalidate translucent windows (like cairo-dock, plasma etc.)

What troubles me is that cairo dock than apparently triggerd ARGB windows for Qt clients? Makes no sense (but to late to investgate now ;-)

> PS: the KDE panel IS a dock ;-) if panel is for you a dock that doesn't move,
> then Cairo-Dock can also act like a panel.

Ok, to be more precise:
"Don't use a docker to put starters or a traskbar into it, not in plasma, nor elsewhere" ;-)

VLC has included "XLIB_SKIP_ARGB_VISUALS=1" directly into their code (and I believe VirtualBox too), because this is the only way right now to prevent Qt from allocating an ARGB visual for a window.
although this can sound crazy, there is no other way (and yet, why the hell a video player would ever need a translucent video frame ?)

of course using XLIB_SKIP_ARGB_VISUALS must be done for each app specifically, not for the session.
it's maybe an X problem, but then why only Qt-based video app ? Gtk windows with an ARGB visual + opengl work fine.

if you can't reproduce it (really ? starting cairo-dock in opengl mode and then opening Skype or Smplayer works ?), maybe there is some hope ^^

(In reply to comment #7)
> VLC has included "XLIB_SKIP_ARGB_VISUALS=1" directly into their code
unlikely (but for the embed) since i still can get the window translucent (bespin/qtcurve/oxygen support such)

> believe VirtualBox too), because this is the only way right now to prevent Qt
> from allocating an ARGB visual for a window.
The more driving question is why cairo/dock/gl causes Qt to do so, because it will trigger the "expensive" path in compositors, break shadows, etc.
This btw. is not changed back after shutting down cairo-dock, all new Qt clients allocate an ARGB window.
-> this should really be fixed/avoided or at least mentioned like "notice that using cairo-dock (in gl mode) will make Qt4 apps be slower" ;-P

> it's maybe an X problem, but then why only Qt-based video app?
> Gtk windows with an ARGB visual + opengl work fine.
Only embeds have been affected so far and afaics only xv embeds, the opengl sinks on smplayer et al. used to work even then. (at least that was the situation when intentionally allocating ARGB drawables)

... the reason seams to be that cairo(-dock?) feels like it has to set a custom color map on the root window

RGB_DEFAULT_MAP(RGB_COLOR_MAP):
                colormap id #: 0x1400001
                red-max: 255
                red-mult: 65536
                green-max: 255
                green-mult: 256
                blue-max: 255
                blue-mult: 1
                base-pixel: 0
                visual id #: 0x8c

calling "xprop -root -remove RGB_DEFAULT_MAP" sanitizes the Qt behaviour.

-> cairo(-dock?) bug. period. =P

that's an intersting clue, although I have never set a colormap on the root
window ^_^;
but it does on the dock's window.
maybe a bug in gtkgl ? by the way how do you know this is a custom color map
? and who set this ?

2011/1/6 Thomas Lübking <email address hidden>

> https://bugs.kde.org/show_bug.cgi?id=262064
>
>
>
>
>
> --- Comment #9 from Thomas Lübking <thomas luebking gmail com> 2011-01-06
> 17:52:40 ---
> ... the reason seams to be that cairo(-dock?) feels like it has to set a
> custom
> color map on the root window
>
> RGB_DEFAULT_MAP(RGB_COLOR_MAP):
> colormap id #: 0x1400001
> red-max: 255
> red-mult: 65536
> green-max: 255
> green-mult: 256
> blue-max: 255
> blue-mult: 1
> base-pixel: 0
> visual id #: 0x8c
>
> calling "xprop -root -remove RGB_DEFAULT_MAP" sanitizes the Qt behaviour.
>
> -> cairo(-dock?) bug. period. =P
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

(In reply to comment #10)
> I have never set a colormap on the root window ^_^;
you shouldn't anyway.

> but it does on the dock's window.
that would be the proper approach.

> maybe a bug in gtkgl?
maybe. in some base of cairo-dock for sure.

> by the way how do you know this is a custom color map? and who set this ?
Jedi abilities. I "sensed" it would be sth. like this...
ok, i just used my cheap & ordinary human brain.

"sth." in cairo-dock must change "sth." with global and persistant impact, "let's just check the root window... hmmmm, RGB_DEFAULT_MAP looks unfamiliar but i know that colormaps are related to ARGB windows - let's just remove it"
-> all new undecorated clients get shadowed again, therefore are not ARGB
-> that's it. Ensured the culprit by logging into a "failsafe" session, checked root properties (no colormap), launched cairo-dock (yes colormap), concluded:

YOUR FAULT ;-)

well you're more familiar with the dark side of X than me ^^
anyway it's not yet "my fault" ;-)
doing furher investigation, I've found that the colormap is set when I call the function gdk_x11_gl_config_new_from_visualid (which gets an opengl config from an ARGB visual, which is then used to give opengl abilities to the GTK windows of the dock).
I'm going to dig into gdkgl to see if I can undestand why it happens.

I still don't see why this should be a problem for Qt apps though (although I do agree that it sounds weird to change the root colormap).

thanks again for your help !

(In reply to comment #12)
> anyway it's not yet "my fault" ;-)
yes it is - you use the wrong toolkit ;-P

> I still don't see why this should be a problem for Qt apps though
X11 is "flat" ie, a "window" is actually only a random X drawable (window type) that's parented by the root window.
Back then, this was no different from the root window children internal structure (ie, "every button was an own X11 drawable" (this has been changed for poor performance on esp. local session)
In other words (and shortened): all windows are part of one mega window (what effectively makes X11 MDI by design - ewww =) and every X drawable inherits settings of the root window - this includes the colormap.
Now, whether X11 or XEmbed are supposed to work across drawables with different colormaps or xv should support ARGB windows or if this is (has been) a bug in Qt, X11 or the drivers - I frankly don't know.
Maybe the Qt window constructor should just ignore/reset colormaps not explicitly set - I don't know either (in fact, I don't know a lot...)

However a client should just not change the "default" colormap, because several other clients may simply not expect this internally (gtk (1.x) -for one- didn't like that at all. Qt cannot apply stylesheets to at least the "window" in ARGB mode, what some applications might rely one, etc....)

Until you figured why gdk does so or gdk gets fixed, you could call

Display *dpy = XOpenDisplay (0);
XDeleteProperty ( dpy, RootWindow (dpy, DefaultScreen (dpy)), XInternAtom ( dpy, "RGB_DEFAULT_MAP", 0) ); // there're probably gdk hooks for the rootwindow/the display - use them.

afterwards - but that's oc only a workaround.

Changed in kdebase:
status: Unknown → Invalid
Changed in kdebase:
importance: Unknown → Medium
Cédric Bellegarde (gnumdk) wrote :

Always here ...

Other gdk dock (awn) do not have this kind of flickering with Kde

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

To post a comment you must log in.
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.