Version: SVN (using Devel) OS: Linux When expanding the bottom panel a white block will appear for a wile then the display will be as it should. Happens when composting is enabled and also if not for slower graphics cards when disabled I am running 270.xx series Nvidia drivers on a 9500gt card, and the white only shows when composting enabled. The original poster on this forum threads sees it with composting both on and off http://forum.kde.org/viewtopic.php?f=67&t=95008&p=195685#p195685 running KDE 4.6.3 Reproducible: Always Steps to Reproduce: expand panel Actual Results: white space Expected Results: no white space
> The original poster on this forum threads sees it with composting both on and off -> unlikely a kwin issue. I assume it does as well for konsole? (if the resize effect -fast texture scaling- is NOT enabled, oc) I also assume it goes away if you run konsole as "konsole --notransparency --nofork"?
not seeing same issue expanding konsole or any tested plasmoids (tested just a few) desktop effect "resize window" is not enabled
I'm the original poster.. I've just tried to run 'konsole --notransparency --nofork' and the white effect doesn't show while it does on normal konsole Desktop effect "resize windows" is not enabled.
i'm now a little confused about who's who here ;-) (though i am myself, that's for sure) @nicolas: what you see is an between the NVIDIA driver and ARGB windows, introduced as regression on some 270.x - there's nothing we can do. Be aware that it will cause longer timeouts the xrender backend and (occasionally) REALLY LOOOONG ones on the GL backend. It's probably somehow related to the lousy 32bit pixmap allocation - but there's no way to check unless you're nvidia. @bill try "konsole --force-transparency --nofork" to ensure you've got an ARGB konsole window (it's afaik not used if the konsole instance was launched w/o active compositing) - alternatively you can try the ARGB features of Bespin, QtCurve or the Oxygen fork to get some ARGB window Plasmoids (NOT panels) are rendered inside the desktop and thus not related to this at all.
I'm sorry.. I must have explained who i am incorrectly.. I'm the person who asked for help in the forum thread: http://forum.kde.org/viewtopic.php?f=67&t=95008&p=195685#p195685 I own an Intel GM45 card and use the i915 kernel module. It's a problem in the drivers right? Thanks for your help :)
> It's a problem in the drivers right? Basically yes, there's apparently an issue with ARGB windows. What worries me is that it happens with intel AND nvidia. That's pretty unlikely. Do you observe similar issues (white flashes or extreme slow resizing) with eg. cairo-clock (ie. sth. with an ARGB window that does NOT use Qt)
Hi, The same bug happens in another computer with an NVidia FX 5200 running the 173 driver in kubuntu 10.04. I have tried running avant window navigator but failed to see anything similar. I will keep trying with another ARBG apps. Thanks
The Pc with the nvidia fx 5200 runs kubuntu 11.04, i'm sorry. I have tried cairo dock and didn't see any similar problem. Is there any other ARBG app I could try?
First off: DO NOT USE CAIRO DOCK Ok, not in this context ;-) gdk has the uncool attitude to manipulate the colortable of the root window, what impacts all windows. (Qt honors it and will make every new window an ARGB client) Do "xprop -root | grep COLOR" to check whether your root is polluted, it will print "RGB_DEFAULT_MAP(RGB_COLOR_MAP):" then do "xprop -root -remove RGB_DEFAULT_MAP" to get rid of this - every application started /after/ this call is no longer affected. You're likely observing a Qt related ARGB issue then and it's unlikely related to the WM/Compositor. (you could check compiz on this side) Please check "konsole --force-transparency --nofork --style cde" to rule out that it's the UI style.
Hi, I ran "xprop -root | grep COLOR" and it didn't show anything even with cairo-dock running nor after closing it. But anyways I ran "xprop -root -remove RGB_DEFAULT_MAP". I tried running "konsole --force-transparency --nofork --style cde" and it didn't fix the problem... Not even compiz did. So.. it's a bug in Qt right?
Running cairo-dock with the cairo backend? ("cairo-dock -c"), it only occurs with the GL backend ("cairo-dock -o") and Ubuntu might have patched it. Btw: how did you resize cairo-dock? The animation you can see (fish-eye) does not actually trigger a resize of the window but is completely internal. (visual effect) And yes: if it's there with compiz & kwin and nvidia & intel (and ultimately only with Qt applications) it's likely a Qt issue :-S
Ohh.. then I didn't even resize it... the only thing I can think of is changing the icons size but it resizes quickly enough for the white blocks to possibly appear. I was running it with the opengl backend. is there any other ARBG app I could test? Thank you very much!
http://packages.ubuntu.com/natty/cairo-clock You can resize it using alt+rmb.
I when I resize it no problem shows however I don't know if I'm using the opengl backend.. I googled I bit and found "export GTKCAIRO_BACKEND=gl" but i'm not sure if it's the right way to do it since it seems a little faster but it might be a placebo. However it doesn't show any white block. Excuse me for my noobiness.. thank you..
The cairo backend doesn't matter. The critical aspect is the ARGB feature. Seems like a conflict between Qt's ARGB implementation and the driver then. @bill p. how's the state at your side? Can you confirm that the issue does NOT occur resizing konsole in explicit ARGB mode but only with plasma panels? Can you check whether it occurs with compiz as well (xcompmgr is likely sufficient as well. double check with kwin's xrender backend in this case)
@Thomas Lübking Using Oxygen if I open Konsole with "konsole --force-transparency --nofork" I have no problems resizing it. Using QtCurve no problem resizing Konsole Compiz doesn't want to run on openSuse 11.4 Using Xrender no problems resizing Konsol
You're likely experiencing a different issue then. Since you cannot test compiuz: What about kwin/xrender or xcompmgr + resizing a plasma panel?
Xrender - expanding panel causes white block xcompmgr - no idea how to start, "xcompmgr --replace" just displays help
xcompmgr is NOT a window manager but just a compositor. simply suspend kwin compositing (or eg. start openbox) and run "xcompmgr" - you're now compositing ;-) "xcompmgr -cFfI 0.1 -O 0.08 -r 16 -l -19 &" will show nicer results, though ;-)
no white using xcompmgr, just disabled composting and ran it from Konsole
Can you please as a final check (to circle the issue) try the - plasma panel with KWin GL compositing AND BLUR EFFECT DISABLED - plasma panel with KWin XRender compositing? (if it's not the blur effect) Thanks, sorry for the work.
Blur effect - is not used by me Xrender - expanding panel causes white block
@Thomas Lübking Ok, I'll report it in the Qt bug tracker... Would "Resizing ARBG windows causes white blocks to appear" be a good description? Or am I not understading the problem correctly? Thanks
sounds good to me (of course I have no idea regarding ARBG windows)
personally I doubt that this is a Qt issue. Qt has a very good testing and I really doubt they introduced such a regression in a minor release. Furthermore I doubt that the experienced issue with Intel is the same as with NVIDIA and I rather think that this are two different issues and caused by something else. Most likely drivers. I cannot remember any Qt regression, but could present a very long list of regressions in various drivers.
to clarify (please correct me!) ------------------------------ Nicolas: - has an issue with Qt powered ARGB windows * on a legacy nvidia chip as well as * on an intel chip, whether on * compiz or * kwin compositing OR * NO COMPOSITING AT ALL * regardless of the UI style - can so far NOT confirm the issue with a cairo (or otherwise?) powered ARGB client. Bill: has an issue with - only plasma panels with - only kwin compositing, - regardless of the backend - regardless of the blur filter If this is true, i think we indeed face at least two different bugs here a) Nicolas seems to encounter an issue specific to Qt ARGB clients only. Whether this is a regression or an ever present issue has actually not been said. b) Bill's issue is weird to me - to say the least ;-) It might be related to any (3rd party?) effect plugin (-> just uncheck the all, see what happens) There's only ONE THING on top that I CAN still THINK OF and that's the GRAPHICSSYSTEM. -> Can either of you please try: konsole --force-transparency --nofork --graphicssystem native konsole --force-transparency --nofork --graphicssystem opengl konsole --force-transparency --nofork --graphicssystem raster and check whether this has any impact?
Created attachment 60021 [details] konsole opened with "konsole --force-transparency --nofork --graphicssystem opengl"
(In reply to comment #27) > Created an attachment (id=60021) [details] > konsole opened with "konsole --force-transparency --nofork --graphicssystem > opengl" "konsole --force-transparency --nofork --graphicssystem opengl" opened konsole with no menu bar, no tabs and just a solid grey window) see pic in prvious post other 2 options made no affect, expanding panel cause white block to display
The OpenGL backend is wonky, so nothing to worry about. > other 2 options made no affect, expanding panel cause white block to display Just to make that clear: running konsole in ARGB mode is supposed to expose similar white blocks on konsole, when resizing konsole. NOT to fix or impact the panel at all!
konsole --force-transparency --nofork --graphicssystem opengl causes BLACK blocks to appear. It fills the log with "Created Window Surface FBO QSize(434, 722) with samples 1 " messages or similar when resizing. The other two graphics systems cause white blocks to appear. konsole --notransparency --nofork --graphicssystem opengl makes the whole window to be a black block. konsole --notransparency --nofork --graphicssystem native or raster fixes the problem
I just tried the Glassified theme for Plasma and the white blocks problem is not present.. I'm sorry not to test it earlier.