It won't write anything to the framebuffer though. As long as you do not create an actual window (only use QOffscreenSurface, not QWindow) and do not call swapBuffers() there will be nothing written out. How and when the EGL implementation opens the framebuffer is not under Qt's or the application's control.
Best regards, Laszlo ________________________________ From: development-bounces+laszlo.agocs=theqtcompany....@qt-project.org <development-bounces+laszlo.agocs=theqtcompany....@qt-project.org> on behalf of Paul Knopf <theonlylawisl...@gmail.com> Sent: Thursday, April 23, 2015 3:38 PM To: Sean Harmer Cc: development@qt-project.org Subject: Re: [Development] Qt 'minimal' platform no rendering alpha/opacity. Sean, I took a look at the example, and this all looks good. However, I think my platform will still grab a handle to the framebuffer. I will be using an i.MX6 device, and the configuration would use the following EGLFS hook. https://github.com/qtproject/qtbase/blob/befe1e37e28db95a79622d628a338feaa8eee77b/src/plugins/platforms/eglfs/deviceintegration/eglfs_viv/qeglfsvivintegration.cpp QEglFSVivIntegration::platformInit(), it looks it still opens the framebuffer, even if we plan on doing only off-screen rendering. The problem is that, I need to open/close/manage the linux framebuffer myself, which is the whole point of doing offscreen rendering. Maybe I can create a custom EGLFS hook, based off of viv, but return a dummy size, and do no initialization. If I am doing strictly off-screen rendering, can I be sure that "QEglFSVivIntegration::platformDisplay()", "QEglFSVivIntegration::createNativeWindow()", and "QEglFSVivIntegration::destroyNativeWindow()" will never be called? On Mon, Apr 20, 2015 at 5:03 AM, Sean Harmer <sean.har...@kdab.com<mailto:sean.har...@kdab.com>> wrote: On 20/04/2015 08:25, Paul Knopf wrote: Thanks a lot! This worked. I now have a valid alpha component that I can send to my hard vendors API for FPGA video overlay. With this said, I would REALLY like to support OpenGL (for Qt Quick 2/qml). Here is an image<http://i.imgur.com/hhlcbb9.jpg> of what I am trying to essentially do. What are your thoughts implementing this in Qt? Here is what I need my monitor output to be. The original buffer: size w / h : [R G B A][R G B A][R G B A][...] The output i want: size (w*.25) / (h*.25): [R G B][A R G][B A R][G B A][...] My thoughts are to Render OpenGL off screen (not using framebuffer), then have a thread that periodically captures the output (RGBA) and sends it my linux framebuffer. My output doesn't need high FPS. I understand that sending the extra alpha will increase the size of my resolution by 25%.. The FPGA component/board will identify itself as having a resolution of 1350 (1080 * .25) so that it can internally translate to 1080 with an alpha channel. Does the EGLFS support off-screen rendering? Maybe then, I could create 1080 opengl context off-screen, and then output it, including alpha, to the 1350 framebuffer. OpenGL supports offscreen rendering as long as the QPA supports OpenGL. * Create a QOffscreenSurface * Create a QOpenGLContext * Create a suitable Framebuffer Object with a colour texture attachment and most likely a depth and stencil attachment. * Bind the FBO as the GL_BUFFER (both read and write binding points) * Draw stuff * Read back the texture attached to the FBO as needed If you are wanting to use this approach to render Qt Quick 2 content, then take a look at the QQuickRenderControl class and accompanying example that ships with Qt. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com<mailto:sean.har...@kdab.com> | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090<tel:%2B46-563-540090>, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Thanks! ~Paul
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
