KWin does not generate window shadows for VLC

[Duncan]

Nikos Chantziaras posted on Wed, 28 Jul 2010 21:57:18 +0300 as excerpted:

> When using VLC with a skin, KWin doesn't drop a shadow under the window.
>   VLC bypasses the window manager it seems, so even though it's actually
> a (frameless) window, it's not handled as such.  Is there a way around
> that?

I had hoped someone who uses VLC would reply, but I see no replies so far, 
so perhaps this more general reply based on experience with other media 
clients and with kwin will help.

Can you setup a window-specific config for it?

Either from kcontrol (mis-labeled system-settings, but it's NOT system 
settings, in general, it's kde specific user settings, system settings 
would affect other users, and be effective running under gnome, xfce, at 
the text console, etc, not just kde, and not just the single user, as 
settings here generally do), or as I usually do, from the window menu of 
any convenient window with one, choose configure window behavior, then at 
the bottom left of the resulting dialog, choose window specific.  On the 
left, choose new, which pops open a sub-dialog.  Click detect window 
properties, which changes the pointer to cross-hairs, and click on the VLC 
window.

That should get you a third popup with information about the VLC window 
you clicked on.  Assuming the information looks sane, you can select which 
parts of it kwin should use to recognize the window, and hit OK.

That should populate the first two tabs, window, and window extra, back on 
the second dialog.  You can make further changes to them (perhaps changing 
exact match to substring match for the window title, if you're matching 
it, for instance, and setting an appropriate description, possibly simply 
"VLC"), then move on, to the actual settings kwin can control on the last 
three tabs.

There doesn't seem to be a direct option controlling shadows, but given 
that you said about the VLC window, tt'd be interesting to see what 
checking "no border" (preferences tab), force, but leaving the right 
checkbox UNCHECKED, would do.  No-border, forced, but unchecked on the 
right, should force a border to be displayed.  

Also, on the workarounds tab, try playing with the window type, and the 
ignore and strictly obey geometry options.  Geometry doesn't sound like 
what you're trying to do, exactly, but it's possible that setting those 
options appropriately will allow kwin to control the window and thus for 
the shadow to apply as well.  And I've never quite figured out what the 
window type options are supposed to do, or if they even work, which is why 
I say play with them a bit, and see if you can get it to work as desired.  
(FWIW, I did experiment with window shadows back when the composite based 
effects first came out, in the kde3 era, and again on kde4 after I got my 
new, better, graphics card, but the shadow effect was simply not to my 
liking, so I don't use it.  Thus another reason I'm saying play with these 
options, as I don't know that they'll work, but I know enough about how 
the others work that they can definitely be eliminated as controlling 
factors.)

FWIW, on the one app I was trying to get to do what I wanted (in that 
case, obey the minimum size, also on the workarounds tab, it was ignoring 
it at first, so it /was/ geometry), I had to set both ignore requested 
geometry (forced, checked) and strictly obey geometry (forced, unchecked), 
in ordered to get it to do what I wanted.  Setting just one would continue 
to work on the window I was experimenting with once I'd got it working, 
but wouldn't work on a new window.  For that, I had to set both, in 
ordered to get it working again.

Meanwhile, what sort of video playback display are you using, and on what 
hardware?

On older hardware, overlay was the most efficient, and often the only way 
to get video to play without glitches and with as few frame-skips as 
possible.  However, it works by effectively rendering the video to a 
different part of graphics memory, then mapping that into the display 
framebuffer at the appropriate place as it draws the display.  Thus, the 
actual video area wasn't part of what the window manager touched at all, 
it completely bypassed the normal window system, and effects such as 
shadow and translucency normally won't work at all in an overlay.  
However, in windowed (that is, not full-screen) playback, most players 
have a normal window around the actual video playback area, and the normal 
window manager has normal control over it, including shadow and 
translucency effects.  But if VLC actually uses overlay for the entire 
app...

On newer hardware, OpenGL playback is an option similar to overlay, but 
implemented using OpenGL instead.  In fact, some drivers (including the 
freedomware Radeon driver I use on my main machine) use OpenGL textures to 
emulate the old overlay feature as well on newer hardware, which often has 
only very basic unaccelerated actual 2D (if it's not entirely emulated on 
the 3D hardware) and may not support hardware overlay at all, so the OpenGL 
texture overlay implementation is fastest and may in fact be the only way 
of implementing it.  On these devices, therefore, overlay actually ends up 
being OpenGL, anyway.

But OpenGL playback mode is at least in theory a bit more flexible than 
hardware overlay mode.  As I understand it (tho here my understanding is 
at its limit and may be incorrect), while overlay completely hardware 
bypassed the normal window management system, etc, OpenGL mode at least in 
theory allows the two systems to work together, so effects such as 
shadows, etc, should be possible.  HOWEVER, actual implementation tends to 
fall behind the theory, and it may not be possible simply because the 
window manager and/or graphics driver hasn't implemented the appropriate 
functionality.  There's also likely to be additional bugs in that area, so 
even where implemented, there may be additional artifacting, and/or 
instability that make it undesirable to actually use in practice.  As for 
options controlling such, other than simply choosing OpenGL playback mode 
or not, I haven't a clue, and all I could suggest would be to play around 
with it if you've got options that look related, and see what happens.

BTW, there's actually several variants of OpenGL playback mode, 
implementing various optimizations possible on various hardware.  Again, 
this is something to experiment with, if the options are exposed to you to 
do so.

The third video playback mode is "surface".  This renders the video 
directly to the normal framebuffer, where it can be controlled by the 
normal window manager, effects and all.  On old and slow hardware, this 
tended to be too slow to be workable, tho occasionally it was the only 
option, and video playback was simply crappy on that hardware.  On newer 
hardware, it's generally workable, but it's more CPU intensive than the 
other modes.  Of course, "more CPU intensive" is relative, and on good 
hardware, it may be only a few percent, thus unnoticeable under normal 
circumstances.

So if VLC has the option, surface mode playback is very likely to let kwin 
do its thing with translucency and shadows, etc, but depending on your 
hardware, CPU usage and/or quality of playback may be unacceptable.  The 
other two alternatives, some variant of OpenGL, or overlay (which in turn 
may be implemented as an OpenGL variant by your graphics driver), should 
use less CPU, but you'll likely lose some kwin control and effects as a 
tradeoff.  Which of the two, OpenGL or overlay, is more efficient, depends 
on your hardware.

Finally, what other players have you tried?  Just putting a word in for 
smplayer, with its many features found lacking in kde's default 
dragonplayer, or the built-in player kparts in dolphin/gwenview/konqueror.  
As I said I've never tried VLC, tho I've been thinking of trying it, so 
can't say how it compares, but smplayer has features like single-frame-
advance that other players lack, which I really enjoy, so that's why I use 
it.  The caveat is that due to the general patented codec situation, many 
binary distributions either don't ship the mplayer backend, or ship it in 
crippled form.  However, the full version is generally available from 
unofficial repositories, and user-compiled-source distributions like 
Gentoo, which I use, don't have the problem in the first place, so getting 
an un-crippled mplayer isn't generally a big issue.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.