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
