Re: [Development] QtCS: OpenGL session notes
On 07/02/2012 02:57 PM, ext Keith Gardner wrote: Why don't you make an OpenGL middleware driver? Then your application will always be an OpenGL application and the middleware driver will take all of the OpenGL calls in place of the system's driver and do the translation there? The middleware driver will then contain the ANGLE code and the application will be none the wiser. Well, whichever way it's done requires proxying all the OpenGL calls somehow, if we wish to support both ANGLE and native OpenGL with QtGui. Sounds like a fairly big task though. For now, Qt on Windows will have to be configured to either support ANGLE or the native OpenGL driver, not both at the same time. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 06/28/2012 01:46 PM, Storm-Olsen Marius (Nokia-MP/Austin) wrote: On 28/06/2012 01:59, ext Samuel Rødal wrote: On 06/27/2012 06:30 PM, ext marius.storm-ol...@nokia.com wrote: In theory we could even support both options in the windows platform plugin, and choose either depending on what the QSurfaceFormat asks for. OpenGL ES 2 via ANGLE, and desktop OpenGL 2 and above via the native OpenGL drivers. Are you sure that would be possible? The ANGLE project is about translating OpenGL calls to DirectX, so it might be hard to support both at the same time? Or do you mean that we would have two different plugins, where we link ANGLE to just one of them? Well, I guess it's not possible to link against the ANGLE OpenGL library and native OpenGL libraries at the same time, so maybe this wouldn't work out in practice, unless we do a lot of runtime resolving magic... Not talking about using different plugins, since QtGui itself nedes to link against OpenGL. If so, where you planning on mixed usage (OpenGL ES2 and OpenGL 2 usage at the same time)? Nope, just for an application to be able to explicitly use desktop OpenGL if so desired. At best we could hope to support using OpenGL ES 2 for one QWindow and desktop OpenGL for another, but definitely not mixing the two within the same context. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
Why don't you make an OpenGL middleware driver? Then your application will always be an OpenGL application and the middleware driver will take all of the OpenGL calls in place of the system's driver and do the translation there? The middleware driver will then contain the ANGLE code and the application will be none the wiser. -Original Message- From: development-bounces+kgardner=zebraimaging@qt-project.org [mailto:development-bounces+kgardner=zebraimaging@qt-project.org] On Behalf Of Samuel Rødal Sent: Monday, July 02, 2012 5:11 AM To: Storm-Olsen Marius (Nokia-MP/Austin) Cc: development@qt-project.org Subject: Re: [Development] QtCS: OpenGL session notes On 06/28/2012 01:46 PM, Storm-Olsen Marius (Nokia-MP/Austin) wrote: On 28/06/2012 01:59, ext Samuel Rødal wrote: On 06/27/2012 06:30 PM, ext marius.storm-ol...@nokia.com wrote: In theory we could even support both options in the windows platform plugin, and choose either depending on what the QSurfaceFormat asks for. OpenGL ES 2 via ANGLE, and desktop OpenGL 2 and above via the native OpenGL drivers. Are you sure that would be possible? The ANGLE project is about translating OpenGL calls to DirectX, so it might be hard to support both at the same time? Or do you mean that we would have two different plugins, where we link ANGLE to just one of them? Well, I guess it's not possible to link against the ANGLE OpenGL library and native OpenGL libraries at the same time, so maybe this wouldn't work out in practice, unless we do a lot of runtime resolving magic... Not talking about using different plugins, since QtGui itself nedes to link against OpenGL. If so, where you planning on mixed usage (OpenGL ES2 and OpenGL 2 usage at the same time)? Nope, just for an application to be able to explicitly use desktop OpenGL if so desired. At best we could hope to support using OpenGL ES 2 for one QWindow and desktop OpenGL for another, but definitely not mixing the two within the same context. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 06/27/2012 06:30 PM, ext marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. How will this effort affect this usage? This effort is about enabling QGLWidget / QWindow applications using raw OpenGL or the low level OpenGL enablers in QtGui to get access to newer OpenGL versions. The QML scene graph will still be using OpenGL ES 2. In theory we could even support both options in the windows platform plugin, and choose either depending on what the QSurfaceFormat asks for. OpenGL ES 2 via ANGLE, and desktop OpenGL 2 and above via the native OpenGL drivers. Will we actively contribute to the ANGLE project, to ensure it's usable when we extend our use of OpenGL? It would be bad for end users if they rely on ANGLE and we change the OpenGL backend to use functionality not covered by ANGLE in the next version, making migration to the next version of Qt impossible. What is the timeline for OpenGL 3+ support, and when is OpenGL ES 3 scheduled for release? QML scene graph will keep using OpenGL ES 2 for the foreseeable future, although we can potentially use extensions when available. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. How will this effort affect this usage? Will we actively contribute to the ANGLE project, to ensure it's usable when we extend our use of OpenGL? It would be bad for end users if they rely on ANGLE and we change the OpenGL backend to use functionality not covered by ANGLE in the next version, making migration to the next version of Qt impossible. What is the timeline for OpenGL 3+ support, and when is OpenGL ES 3 scheduled for release? -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 27/06/2012 12:14, ext Sean Harmer wrote: On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. You mean for embedded flavours of Windows right? OpenGL 3+ works fine on desktop windows - although getting hold of a Core Profile context on Windows via Qt was broken last time I tried it (but that was some months ago). No, I don't mean for embedded alone. Desktop OpenGL drivers are also of quite varying quality, and the DirectX drivers are usually better. Not to mention that with Windows 8 you might have a hard time getting access to the OpenGL APIs, depending on which system you are on and how integrated you want to be. No WGL/EGL support for Metro applications afaik, see http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c77de65a-1fbb-491f-9f6b-0c4a7b452ec2 and http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861db02-dce8-4f61-9969-b8a7a7cd55c7 (Yes, non-Metro apps can use OpenGL just fine, although reports have come back that currently the OpenGL drivers are lagging behind the DirectX ones.) No OpenGL for Windows 8 RT (ARM) version either, which should also be a target. How will this effort affect this usage? The same way it will affect those platforms that only support OpenGL ES2 I guess - they just won't use the new features/capabilities. Ok, so ifdef out the extensions completely when we compile with the ANGLE library? Will we actively contribute to the ANGLE project, to ensure it's usable when we extend our use of OpenGL? It would be bad for end users if they rely on ANGLE and we change the OpenGL backend to use functionality not covered by ANGLE in the next version, making migration to the next version of Qt impossible. What is the timeline for OpenGL 3+ support, and when is OpenGL ES 3 scheduled for release? It is possible to use OpenGL 3 (or even 4) on the desktop right now just that Qt does not yet wrap the new features. OpenGL ES 3 is scheduled for release soon which translates to probably sometime this year. It is supposed to reduce the delta between desktop OpenGL and OpenGL ES. Good to know, thanks. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On Wednesday 27 June 2012 17:46:32 marius.storm-ol...@nokia.com wrote: On 27/06/2012 12:14, ext Sean Harmer wrote: On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. You mean for embedded flavours of Windows right? OpenGL 3+ works fine on desktop windows - although getting hold of a Core Profile context on Windows via Qt was broken last time I tried it (but that was some months ago). No, I don't mean for embedded alone. Desktop OpenGL drivers are also of quite varying quality, and the DirectX drivers are usually better. I only have access to nVidia boards at present so can't comment on the other manufacturer's driver quality/completeness. Not to mention that with Windows 8 you might have a hard time getting access to the OpenGL APIs, depending on which system you are on and how integrated you want to be. No WGL/EGL support for Metro applications afaik, see http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c 77de65a-1fbb-491f-9f6b-0c4a7b452ec2 and http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861d b02-dce8-4f61-9969-b8a7a7cd55c7 (Yes, non-Metro apps can use OpenGL just fine, although reports have come back that currently the OpenGL drivers are lagging behind the DirectX ones.) No OpenGL for Windows 8 RT (ARM) version either, which should also be a target. Hmmm, I've not played with Win 8 at all yet. No OpenGL on Metro style apps of Win8 Arm is indeed a PITA. Thanks for the info. Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
To use Qml on Win8 Metro, we must have a directX backend (with or without angle .. but it seems that for now angle is directX9 only and Metro need DX11), and to be able to use qt5 qml for digital signage on low end hardware ( in that case qt5 qml is just perfect...) we need to have hardware accelerated video decoding (dxva) on Windows .. so it need to have a way to bridge qml video to angle directx surface to have access to dxva 2012/6/27 Sean Harmer sean.har...@kdab.com On Wednesday 27 June 2012 17:46:32 marius.storm-ol...@nokia.com wrote: On 27/06/2012 12:14, ext Sean Harmer wrote: On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. You mean for embedded flavours of Windows right? OpenGL 3+ works fine on desktop windows - although getting hold of a Core Profile context on Windows via Qt was broken last time I tried it (but that was some months ago). No, I don't mean for embedded alone. Desktop OpenGL drivers are also of quite varying quality, and the DirectX drivers are usually better. I only have access to nVidia boards at present so can't comment on the other manufacturer's driver quality/completeness. Not to mention that with Windows 8 you might have a hard time getting access to the OpenGL APIs, depending on which system you are on and how integrated you want to be. No WGL/EGL support for Metro applications afaik, see http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c 77de65a-1fbb-491f-9f6b-0c4a7b452ec2 and http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861d b02-dce8-4f61-9969-b8a7a7cd55c7 (Yes, non-Metro apps can use OpenGL just fine, although reports have come back that currently the OpenGL drivers are lagging behind the DirectX ones.) No OpenGL for Windows 8 RT (ARM) version either, which should also be a target. Hmmm, I've not played with Win 8 at all yet. No OpenGL on Metro style apps of Win8 Arm is indeed a PITA. Thanks for the info. Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
- simple imperative GLES2 painter suited for Canvas 2D etc, lose all the poorly / unnecessary performing features of QPainter - QPainterV2 API, reduced QPaintEngine API - learn from Skia - improved API that discourages slow use cases This is far outside my knowledge area, but i am very curious to know what kind of things can be learned from skia. I know skia is the render engine for chrome and that's all i know about it. The lines left above highlights the general problem... The QPainter API is very feature rich and opens up for a number of use patterns that are less than ideal for performance. I was not in the session, so some other points might have been raised there, but this topic has been raised before in the oslo graphics team. If we were to strip down the QPainter API into a useful but bare minimum, then we might as well go for an API that is well adopted by now, and the natural candidate for that would be the HTML Canvas2D API. Then again, we also know that in terms of hardware accelerated graphics, imperative APIs are not really the way to go. Typical 2D graphics drawing consists of many tiny bits and pieces here and there and the overhead of every draw call in the driver outweighs the benefit of using hardware accelerated APIs in the first place. This is why QPainter on OpenGL is better than QPainter on raster in only select usecases. Personally, I am convinced that scene graphs are the right way to accelerate graphics as it opens up for reordering and batching which in the end results in optimal use of the graphics driver and thus also the hardware. It might be better to spend the effort making convenience APIs for the scene graph rather than trying to reimplement skia with Qt API. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
Hi, Is there anybody knows how to enable OpenGL (or OpenGL ES) as QPainter's backend? I learned from some document there's an existing OpenGL/GLES backend in QPainter. Thanks, Joe Yu -Original Message- From: development-bounces+joe.yu=arm@qt-project.org [mailto:development-bounces+joe.yu=arm@qt-project.org] On Behalf Of gunnar.sle...@nokia.com Sent: 2012年6月26日 PM 03:06 To: mark...@gmail.com Cc: development@qt-project.org Subject: Re: [Development] QtCS: OpenGL session notes - simple imperative GLES2 painter suited for Canvas 2D etc, lose all the poorly / unnecessary performing features of QPainter - QPainterV2 API, reduced QPaintEngine API - learn from Skia - improved API that discourages slow use cases This is far outside my knowledge area, but i am very curious to know what kind of things can be learned from skia. I know skia is the render engine for chrome and that's all i know about it. The lines left above highlights the general problem... The QPainter API is very feature rich and opens up for a number of use patterns that are less than ideal for performance. I was not in the session, so some other points might have been raised there, but this topic has been raised before in the oslo graphics team. If we were to strip down the QPainter API into a useful but bare minimum, then we might as well go for an API that is well adopted by now, and the natural candidate for that would be the HTML Canvas2D API. Then again, we also know that in terms of hardware accelerated graphics, imperative APIs are not really the way to go. Typical 2D graphics drawing consists of many tiny bits and pieces here and there and the overhead of every draw call in the driver outweighs the benefit of using hardware accelerated APIs in the first place. This is why QPainter on OpenGL is better than QPainter on raster in only select usecases. Personally, I am convinced that scene graphs are the right way to accelerate graphics as it opens up for reordering and batching which in the end results in optimal use of the graphics driver and thus also the hardware. It might be better to spend the effort making convenience APIs for the scene graph rather than trying to reimplement skia with Qt API. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 06/26/2012 09:29 AM, ext Joe Yu wrote: Hi, Is there anybody knows how to enable OpenGL (or OpenGL ES) as QPainter's backend? I learned from some document there's an existing OpenGL/GLES backend in QPainter. Thanks, Joe Yu You'll get the OpenGL backend as long as you're painting on a QGLWidget or using a QGraphicsView that has a QGLWidget set as its viewport. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On Monday 25 June 2012 11:44:09 Girish Ramakrishnan wrote: Hi, OpenGL session notes (pasted from http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtOpenGL) so you can comment inline. Sorry I could not attend this year but the QtCS clashed with my family vacation. Thanks to Samuel for leading the session and taking the notes! Girish Future plans - Desktop OpenGL 3+ support, ES 3 support I have started work on this (desktop for now until ES 3 is released). The general idea is to make it as simple as possible to get up and running with OpenGL and Qt without having to resort to manually resolving entry points or trying to mix in GLEW or similar. I have written a small parser for the OpenGL spec files. The idea is to use the parsed information along with a code generator to create a family of classes (API still being determined) similar to QOpenGLFunctions. These classes will contain functions for each OpenGL version and profile. QOpenGLContext could be modified to return a pointer to the class appropriate for the requested context. This has the advantage of having access to OpenGL functions per context (entry point addresses can change between contexts on some platforms) and providing compile-time errors if you try to use functions not present in a given version and profile (e.g. glBegin() with an OpenGL 3 Core Profile context). Aspects that still require some thought are how to incorporate OpenGL extension entry points and higher level is feature X available. For the latter, a given feature may be provided either by the core functionality in some versions of OpenGL or by extensions in earlier versions. This kind of query is needed to re-enable support for Geometry shaders and to introduce support for Tessellation shaders in QtGui. I also have some ideas (and some code cooking) for other enabler classes e.g. QOpenGLVertexArrayObject. - QOpenGLWindow Yes this would be a useful convenience class to have. - Shared cross process graphics buffer APIs - copy to texture - bind to texture Along these lines it would be nice to have OpenGL texture formats as storage formats in QImage. There is also no replacement in QtGui for QGLWidget::convertToGLFormat() as yet. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On Jun 26, 2012, at 11:16 AM, ext Sean Harmer wrote: - QOpenGLWindow Yes this would be a useful convenience class to have. Which features are we talking about here? I have been thinking that we could add something equivalent to the rasterwindow I did for the examples here: https://codereview.qt-project.org/#change,29059 So it would have: - render(QPainter *) -- so we can skip the QOpenGLPaintDevice / swap setup - render() -- for raw GL rendering - update() / repaint() -- for scheduling and triggering repaint. It could also add a few commonly used utilities like: - drawTexture(id, rect) - others? If we go down this path, then using the QOpenGLWindow to do rendering in a different thread suddenly becomes hard. What is convenience and what is api bloat? I think such a class is nice to have, but it would need to be a minimal helper for the most common case based on the existing enablers, and also not turn into another QGLWidget. - Shared cross process graphics buffer APIs - copy to texture - bind to texture Along these lines it would be nice to have OpenGL texture formats as storage formats in QImage. There is also no replacement in QtGui for QGLWidget::convertToGLFormat() as yet. One thing that would be fairly easy is to add RGB, RGBA and RGBA_PM to the image formats. That would give us the quick conversion between the formats, and regardless of how we proceed, we will need these. However, as both our image codecs and the raster engine are written for ARGB_PM and RGB32, we would get conversion when loading from disk and we would not be able to render to these as targets with the raster engine without doing conversion again. Adding RGBA support to the raster engine as a first class citizen with full optimization paths for all special cases we currently have for ARGB_PM is doable but quite a bit of work. We are talking about a span functions written for several different SIMD instruction sets for instance. It also means we void the work we did for Qt 5 in trimming down the size of the raster engine's helper functions, but that is less of an issue. Another aspect is that quite a lot of (shared-memory architecture) hardware supports more direct upload paths which do not use OpenGL at all. These often support both ARGB and RGBA alike, and with the right architecture in place, one could decode the image data directly from disk into texture memory without going through QImage at all. This is doable already today in QML and scene graph using a custom QQuickImageProvider and QQuickTextureFactory. However, as it is not part of the default image provider, it does not apply to standard loaded Image elements. It would be nice to centralize these concepts in QtGui so others could also benefit from them. cheers, Gunnar Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On Tue, 26 Jun 2012 07:05:35 +, gunnar.sletta wrote: The lines left above highlights the general problem... The QPainter API is very feature rich and opens up for a number of use patterns that are less than ideal for performance. Please don't forget that QPainter is more then rendering to screen: f.e. when you need to generate PDF documents and you don't want to implement the render code twice. IMHO being an abstract API for very different backends is as important as performance issues ( that you won't even notice in most use cases ). One note about performance: QPainter often does pointless calculations - in many applications I had much more effect with doing polygon clipping in application code - before the points have been passed to the painter - than with using a hardware accelerated backends. And these type of algorithmic optimizations work on any system - even on those, where you don't have any hardware accelerated option ! I bet that introducing a QPainter::ClipPolygon render hint would improve the performance of many Qt widgets showing graphics significantly - without any major redesign neither in Qt nor in application code. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtCS: OpenGL session notes
Hi, OpenGL session notes (pasted from http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtOpenGL) so you can comment inline. Thanks to Samuel for leading the session and taking the notes! Girish Future plans - Desktop OpenGL 3+ support, ES 3 support - QOpenGLWindow - Shared cross process graphics buffer APIs - copy to texture - bind to texture - bind as framebuffer - locking / unlocking subrectangles for SW / HW access - synchronization - QPA / preliminary ? - IPC / way of exposing buffer across processes - file descriptor - hardware address, handle, etc - capabilities - page flipping to the screen - linear formats / non-linear formats - orthogonal to the QPA APIs? multiple buffer abstractions - QOffscreenSurface - texture atlas API / area allocator - simple imperative GLES2 painter suited for Canvas 2D etc, lose all the poorly / unnecessary performing features of QPainter - QPainterV2 API, reduced QPaintEngine API - learn from Skia - improved API that discourages slow use cases - the problem of RGBA - BGRA - new image formats? - image upload parts of scene graph adaptation layer - better abstraction? - move from declarative to QPA? - fast texture uploads - subpixel layout - QScreen API for accessing subpixel layout information - subpixel layout information in QImage / QPixmap ? - QImage vs QPixmap - QPixmap::internalImage() accessor with no deep copy? - wrapping non-Qt contexts in QOpenGLContext ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
