Anyway, I really see this as a TK issue.
it could be that it is less noticeable with your particular theme(?) this i don't know, but I highly doubt it has been fixed in Kwin (and i personally do not care enough to go and look) and i know it has not been fixed in compiz (nor will it ever be). So if you are talking about kwin, *maybe* but very unlikely has it actually been fixed, and it has NOT been fixed in compiz (but you didn't make it clear which you were testin?).
Last edited by ninez; 02-08-2013 at 12:21 AM.
Although it doesn't actually matter either way. One of the main reasons for Wayland is proper compositing as opposed to X's compositing as an afterthought. You can't look at something broken with compositing in X and blame it on only one part of the underlying implementation (server side decorations) when most/all of said implementation is suspect to begin with. You may even be right about server-side decorations being an issue (I suspect you're not), but this wouldn't be hard evidence of that.
I’m on the fence about server-side decorations. krh came to the office a few weeks ago to give an internal demo of Wayland, and I asked him about it. His reasoning was that with thing like rotating and scaling windows, it’s too easy to get a seam between the window and its decorations. That’s a perfectly valid answer, and I’m satisfied with it.
If you’re worried about discontinuity between desktop environments and window toolkits, I wouldn’t be. I expect that we’re going to have a libwayland-decorations which paints (or gives us information to paint) window decorations.
QUOTE=hiryu;311620]I've not seen these artifacts across 4 different systems *ever*: my home desktop (nvidia), my personal laptop (nvidia), the family computer (r600g), and my work laptop (intel). I haven't seen these artifacts when I've used compiz in the past either.
I haven't used wobbly windows for years but I recall seeing them on both kwin and compiz. Again, IIRC, it is an inherent issue with server side window border handling.
Last edited by liam; 02-08-2013 at 12:41 AM.
you can also doubt me / think that i am wrong all that you like, but server-side decorations seem to be problematic. I'd (almost) bet money kwin is going to have this problem in Wayland too.
also, 1st search on youtube for kde/wobbly windows shows crappy lines/gaps in kwin + wobbly windows... it's brief, but clearly visible. Start at 25sec into video watch as he moves Dolphin, then lets go of the window - you can clearly see window/decoration separation, it looks like crap. (but in using KDE, i've had it be much more obvious than this, for longer periods of time).
Last edited by ninez; 02-08-2013 at 01:10 AM.
Anyway, as ninez says, around the :27s you can see a blue line appear between the menubar and titlebar in dolphin just after he stops the window movement.
That may not be kwin, however.
First of all I find it hilarious that proper wobbly windows and rotating windows are the arguments for client side decorations.
Those two are hardly important use cases to solve if you ask me, compared to the serious usability problems that will appear if one goes with CSD.
For a proper working CSD each window would need to know as much about its surroundings as the window manager itself does, in order to make sane decisions, and then we are still talking heavy IPC.
On the other hand, since the compositor and window manager are truly one now in wayland with no other layers causing problems I can't imagine it being that hard drawing the decoration and window content to the same buffer before doing the transformations, hence solving the possible wobbly window problem.