2013-04-09, 11:16
I'm honestly not really familiar with XBMC code, but I'll just bring this up, as I'd really love to have this feature and have done some research in that area currently. I'd be happy to help and provide more information if somebody wants to have a shot at this. If you tell me: Do it yourself! I could really use some technical info and some pointers on where to look and what to change... anyway. Here goes:
==== Expand boblight support ====
* ''Summary'': Ambilight via boblight works really well in XBMC when watching movies, "expanding" the screen and adding to the overall experience. But it works ONLY when watching videos. It would be nice to have that feature for picture slideshows or music vizualization too.
* ''How to achieve this'': As I currently understand the technical side the rendered video data is scaled to a smaller image and then grabbed by the boblight plugin. This only works in video mode, naturally, and runs on the CPU. It would be necessary to render all XBMC visuals NOT to the OpenGL screen/backbuffer, but to a FBO/framebuffer and then downsample that framebuffer to another one that already has the size needed for boblight. The boblight plugin could then instruct XBMC to grab the downsampled framebuffer data when it is needed.
* ''Benefits'': Boblight support would work in ALL screen modes, in XBMC menus etc. Also the amibilight colors would resemble the SCREEN content, not the video content as it currently is. Downsampling the image would possibly use GPU resources, freeing up the CPU for other tasks.
* ''What does it touch in XBMC'': That I'm not sure of. Instructing XBMC to render to an FBO should be simple, blitting/downsampling before swapping the buffers too, reading the downsampled buffer too. All-in-all I don't expect changes in too many places and few lines of code. It could be necessary to re-create the buffers whne switching resolutions...
Hardware-requirements might go up, because two new buffers are needed: One screen-sized color buffer and one smaller color buffer for downsampling (~8MB GPU memory needed for a Full-HD 32bit color buffer). The feature could be TOGGLEABLE though and is barely needed on mobile platforms, thus the impact should be really low. Frame times have been measured to go up in the 1-4 millisecond-area when tested on platforms like Core i3, i5 (Ubuntu and Windows) and on the Raspberry Pi. See here.
* ''Requirements'': I have prepared a sort of testbed on my blog here using CMake and C++. That should get you started.
I'm happy to answer questions. Drop me an email, my contact can be found here or in the blog.
Best regards and thanks for XBMC btw!
Bim
==== Expand boblight support ====
* ''Summary'': Ambilight via boblight works really well in XBMC when watching movies, "expanding" the screen and adding to the overall experience. But it works ONLY when watching videos. It would be nice to have that feature for picture slideshows or music vizualization too.
* ''How to achieve this'': As I currently understand the technical side the rendered video data is scaled to a smaller image and then grabbed by the boblight plugin. This only works in video mode, naturally, and runs on the CPU. It would be necessary to render all XBMC visuals NOT to the OpenGL screen/backbuffer, but to a FBO/framebuffer and then downsample that framebuffer to another one that already has the size needed for boblight. The boblight plugin could then instruct XBMC to grab the downsampled framebuffer data when it is needed.
* ''Benefits'': Boblight support would work in ALL screen modes, in XBMC menus etc. Also the amibilight colors would resemble the SCREEN content, not the video content as it currently is. Downsampling the image would possibly use GPU resources, freeing up the CPU for other tasks.
* ''What does it touch in XBMC'': That I'm not sure of. Instructing XBMC to render to an FBO should be simple, blitting/downsampling before swapping the buffers too, reading the downsampled buffer too. All-in-all I don't expect changes in too many places and few lines of code. It could be necessary to re-create the buffers whne switching resolutions...
Hardware-requirements might go up, because two new buffers are needed: One screen-sized color buffer and one smaller color buffer for downsampling (~8MB GPU memory needed for a Full-HD 32bit color buffer). The feature could be TOGGLEABLE though and is barely needed on mobile platforms, thus the impact should be really low. Frame times have been measured to go up in the 1-4 millisecond-area when tested on platforms like Core i3, i5 (Ubuntu and Windows) and on the Raspberry Pi. See here.
* ''Requirements'': I have prepared a sort of testbed on my blog here using CMake and C++. That should get you started.
I'm happy to answer questions. Drop me an email, my contact can be found here or in the blog.
Best regards and thanks for XBMC btw!
Bim