Re: [Plasma Media Center] some advice request
Am Freitag 04 Juni 2010, 23:47:07 schrieb Aaron J. Seigo: another approach might be to make it a kwin plugin, and have the video window rendered beneath the PMC window using a compositing plugin. this plugin would need to know what the video window is and what the PMC window is (can be done using XAtoms specific to the plugin) and then render the video window under the PMC window and not using the normal rendering. one of the KWin people might be able to help guide us here in how best to make that happen, and the plugin could probably ship with PMC itself. this would tie PMC to kwin, but it would also mean that it would work just great non-fullscreen and without any window management hacks in PMC itself. I think that this could work, but I want to point out two things: 1. Texture from pixmap is quite heavy with some drivers. CPU usage for kwin increases to approx. 20 % when watching a video on my system. I often turn compositing off when watching fullscreen movies and don't need effects. Depending on the hardware PMC is targeting this could become a problem. On the other hand it's likely that we need compositing as we might want to have nice alpha-blended overlay controls in own windows, etc. etc. Also we have to tweak kwin so that the effect enforces that the fullscreen video window is not unredirected. Something I wanted to add for a long time... 2. The effect should live in kwin source directory because the KWin Effects API does not provide a stable ABI. If the PMC effects live in another source tree and PMC is released together with PMC I don't see a problem - except that the effect is not magically updated by kwin devs. If it's released seperately we have to find a solution. Maybe that would be an excuse to start to think about providing a stable ABI ;-) (Although I already have ideas how to break ABI as soon as 4.6 development starts) signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Fri, Jun 4, 2010 at 11:47 PM, Aaron J. Seigo ase...@kde.org wrote: On June 4, 2010, Alessandro Diaferia wrote: At the very beginning we had the idea to put a plain VideoWidget behind the transparent-made containment (really, the Plasma::View) but IIRC this is not possible as long as there is a window registered as desktop in the WM. the PMC (plasma media center) window isn't a desktop window, so this isn't an issue. PMC is a stays on top, fullscreen window. the video just needs to be stack beneath it without any other windows in between. (really, a job for the window manager, but for now we'll have to manage that on our own ... it also means that PMC will not work non-full screen very well since the geometry of the windows would need to be sync'd.) this, btw, is exactly what LinuxMCE does. A problem with this approach is that with some crappy video drivers (for sure intel drivers at least until a certain point don't know the situation nowdays) the portion of a video rendered below an argb window is a nice solid blue rectangle, so won't be usabe at all. that said, for having something quickly demo-able i still think it's the better way (and just f... the bad video drivers) I would really love to have the video in canvas in the future, but really doesn't seem doable right now, besides small thumbnail previews :/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Saturday 05 June 2010 11:21:24 Marco Martin wrote: A problem with this approach is that with some crappy video drivers (for sure intel drivers at least And considering that HTPCs are currently most likely Atom-based (hence Intel GMA 500 / Poulsbo), your point is even more valid. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Sat, Jun 5, 2010 at 6:01 AM, Markus kamika...@web.de wrote: On Saturday 05 June 2010 11:21:24 Marco Martin wrote: A problem with this approach is that with some crappy video drivers (for sure intel drivers at least And considering that HTPCs are currently most likely Atom-based (hence Intel GMA 500 / Poulsbo), your point is even more valid. That assumption is flawed since you can't watch Hulu on an Atom w/o terrible frame drops and tearing. Chris ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Saturday 05 June 2010 16:41:15 Christopher Blauvelt wrote: That assumption is flawed since you can't watch Hulu on an Atom w/o terrible frame drops and tearing. Doesn't Hulu use Flash? Flash's suckiness on X11 platforms and Mac OS X is well-known. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Sat, Jun 5, 2010 at 10:58 AM, Markus kamika...@web.de wrote: Doesn't Hulu use Flash? Flash's suckiness on X11 platforms and Mac OS X is well-known. Well, until they fix it, it is was it is. Also I think an Atom processor would be hard pressed to decode and display 1080p video files without some serious help from the GPU. PMC has a long way to go before we can use something like VDPAU. Chris ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Saturday 05 June 2010 18:34:51 Christopher Blauvelt wrote: PMC has a long way to go before we can use something like VDPAU. Isn't that something a Phonon/QtMultimedia back-end has to take care of and not Plasma? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Sat, Jun 5, 2010 at 1:20 PM, Markus kamika...@web.de wrote: On Saturday 05 June 2010 18:34:51 Christopher Blauvelt wrote: PMC has a long way to go before we can use something like VDPAU. Isn't that something a Phonon/QtMultimedia back-end has to take care of and not Plasma? Likely, but I'm sure there will be some issues along the way even if Qt does implement VDPAU support or whatever the Intel/ATI equivalent is. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Saturday 05 June 2010 19:50:45 Christopher Blauvelt wrote: On Sat, Jun 5, 2010 at 1:20 PM, Markus kamika...@web.de wrote: On Saturday 05 June 2010 18:34:51 Christopher Blauvelt wrote: PMC has a long way to go before we can use something like VDPAU. Isn't that something a Phonon/QtMultimedia back-end has to take care of and not Plasma? Likely, but I'm sure there will be some issues along the way even if Qt does implement VDPAU support I don't understand. Why would Qt need to implement it when back-ends handle the decoding? (Phonon back-end = VLC. QtMultimedia back-end = GStreamer.) or whatever the Intel/ATI equivalent is. There is only one proper API and that's VA-API -- a freedesktop.org standard with back-ends for all common GPUs. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
There is only one proper API and that's VA-API -- a freedesktop.orgstandard with back-ends for all common GPUs. Wow, that sounds almost religious. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Saturday 05 June 2010 21:53:37 Christopher Blauvelt wrote: Wow, that sounds almost religious. So instead of answering my question, you insult me? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Sat, Jun 5, 2010 at 4:11 PM, Markus kamika...@web.de wrote: On Saturday 05 June 2010 21:53:37 Christopher Blauvelt wrote: Wow, that sounds almost religious. So instead of answering my question, you insult me? I wouldn't call that an insult. Either way we've hijacked this thread by going off on a tangent. To answer your question. If we want to get VDPAU (VA-API) support in a QGV I'm sure Qt will have to get involved somehow. Whether they do or don't doesn't really matter because it's not coming out until Qt 4.8, we need a solution in the interim, and that solution likely won't support GPU assisted decoding which precludes the use of an Atom processor for decoding 1080p video. Chris ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Plasma Media Center] some advice request
Hello everybody. As some of you may already know I'm currently trying to guide the Plasma Media Center project and I'm quite happy with the results we are achieving. The project is still highly work in progress and therefore we have issues here and there i'd like to point out in this mail. The first *big* issue we have is Phonon; and this is a relevant one since our business are Media resources. Phonon::VideoWidget inside a QGW sucks great and currently we also have that white-skin people are rendered blue (yeah, like Avatar). I already mentioned the aim is to show the video full screen and having it embedded inside a QGW is way ugly as it is rendered badly. I did some investigation and found out that probably QtMultimedia will help us fix this. Unfortunately QtMultimedia won't be shipped until Qt 4.8 and so a decision in this direction has to be taken. At the very beginning we had the idea to put a plain VideoWidget behind the transparent-made containment (really, the Plasma::View) but IIRC this is not possible as long as there is a window registered as desktop in the WM. The second idea was to continuously ask the VideoWidget for snapshot()s and directly paint them over the QGW. I tried this but it is really really bad performing. One more test was done trying to redirect the painting, specifically doing it with grabWidget. But this seems not to be possible as the Phonon::VideoWidget is not a pure QWidget. grabWindow is not possible as the window should be hidden. Please correct me if I'm wrong and point out some advice. Also, no way i should try to already make use of QtMultimedia in place of Phonon for the QGraphics* stuff? The second aim we have is to allow different kind of inputs to be used for the Media Center interaction. Me and Sebas were investigating wiimote capabilities and later Sebas pointed out this project [0]. It seems to me really well done with a good level of abstraction for the wii controllers. I already contacted the author in order to have more info about that but unfortunately he still didn't reply. My concern about this regards how making the input handling enough general to be extended via wiimote plugins and stuff like that. For example, currently the browsing applet handles keyEvents in order to move the selection indicator. How should I handle such events in order to allow further extension via other kind of input devices? Any hint for me? I'd like such points to be discussed before we reach akademy so that I'll introduce our approaches in such aspects. Thank you for your time. P.S.: Also, shall I CC some other ML that might be interested in this? If so, can you suggest which ones? [0] http://gitorious.org/wiimotedev -- Alessandro Diaferia KDE Developer KDE e.V. member ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On June 4, 2010, Alessandro Diaferia wrote: At the very beginning we had the idea to put a plain VideoWidget behind the transparent-made containment (really, the Plasma::View) but IIRC this is not possible as long as there is a window registered as desktop in the WM. the PMC (plasma media center) window isn't a desktop window, so this isn't an issue. PMC is a stays on top, fullscreen window. the video just needs to be stack beneath it without any other windows in between. (really, a job for the window manager, but for now we'll have to manage that on our own ... it also means that PMC will not work non-full screen very well since the geometry of the windows would need to be sync'd.) this, btw, is exactly what LinuxMCE does. another approach might be to make it a kwin plugin, and have the video window rendered beneath the PMC window using a compositing plugin. this plugin would need to know what the video window is and what the PMC window is (can be done using XAtoms specific to the plugin) and then render the video window under the PMC window and not using the normal rendering. one of the KWin people might be able to help guide us here in how best to make that happen, and the plugin could probably ship with PMC itself. this would tie PMC to kwin, but it would also mean that it would work just great non-fullscreen and without any window management hacks in PMC itself. CC'ing the kwin list to see what they think of that. How should I handle such events in order to allow further extension via other kind of input devices? Any hint for me? QGesture may be of help here. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
On Fri, Jun 4, 2010 at 3:51 PM, Alessandro Diaferia alediafe...@gmail.com wrote: How should I handle such events in order to allow further extension via other kind of input devices? Any hint for me? I think the ideal solution would be for the KDE shortcut system to be changed to a pluggable system where people can write backend plug-ins to provide support for additional input sources. This would allow the existing shortcut system to directly use buttons from other input devices as shortcuts. So joystick buttons, bluetooth device buttons, mouse buttons, remote control buttons, the wii remote, and so on could be used as shortcuts for anything in KDE as long as long as someone write a backend. They wouldn't have to be buttons, either, voice commands could be used as well. This would mean all of KDE would benefit from any additional input device plugins someone created for his or her own needs, instead of what we have now where if it isn't a keyboard every part of KDE has its own independent implementation (like plasma's handling of mouse button combos) or there needs to be a separate application mapping buttons presses to either keyboard combos or dbus (like kremotecontrol). KDE's lack of integration of non-keyboard input devices (particularly mice) is a long-standing issue, and I think a general solution is better than the piecemeal approach we have now. See here for a longer explanation: https://bugs.kde.org/show_bug.cgi?id=171295 -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
