I have a SDL_surface that plays a video in its own window. I want this window to be rendered on a QWidget. I want a generic solution because my targets are OSX, Windows and Linux.
I've come across 2 solutions summarized as below:
The Window ID hack involves setting SDL_WINDOWID to the QWidget's id so SDL pushes pixels on the QWidget. Here is an Example Qt snippet from a related thread.
However, this doesn't work on OS X and is not guaranteed to work on all Win and Linux platforms.
Manually copying from non-window SDL_surface to QWidget.
Found some example code for Gtk+ but nothing for Qt so far. The idea is to push the video to memory and pull it from QWidget. Surely one shouldn't use a QImage to render each frame. So how would one implement this copying?
There are possible duplicate questions but my question is more specific about platform-independence
Retrieve the pixels from the SDL_Surface and create a QImage with it, then use a QPainter to draw the QImage on the widget.
Related
I'm trying to get Qt and EGL to work together. I'm working on a program that uses EGL to draw, and I have to use Qt to create a GUI overlay.
The current solution was to turn a QWidget into a native window, and pass it's window handle to EGL. This works, but it's difficult to work with. Qt isn't aware that the widget is being drawn in by something else. So when another widget is overlaid, even if it's transparent, the image drawn by EGL is erased. The only way to get them to work is if I jigsaw the buttons and other GUI elements in a way that they don't overlap the parts of the native window I want to show. However this means that I can't use layouts or QML or any of the tools that would make creating different GUIs easy.
So my question is, how can I draw with EGL into Qt in a more usable way.
I'm working with Qt 5.4.2 by the way. If absolutely necessary, I might be able to upgrade to 5.5, but newer versions won't work.
I was looking into QOpenGLContext, and ways to make it use the context created by EGL, but I can't seem to find any good examples on how to actually go about doing this.
I am using a QGraphicsScene with a QGraphicsView, as described in this document. I intend to eventually overlay Qt widgets on top of my OpenGL rendered scene.
When I launch a dummy application modeled after the tutorial above, the rendered view is heavily pixelated-- HiDPI isn't working at all. Per this document, I've manually added:
<key>NSHighResolutionCapable</key>
<string>True</string>
to the application's Info.plist file, still with no effect. (It seems this is supposed to default to true anyway, so maybe that's not surprising).
Beyond the above, I haven't found what's needed to get HiDPI working. I am not using QtCreator, and my Qt install is macports' qt4-mac. What am I missing?
Qt5 enables HiDPI for the OpenGL context, but not for widgets and QGraphicsItems.
According to this bug, support for rendering widgets and QGraphicsItems on a QGLWidget in HiDPI is not yet supported; they will render at standard res and be resized.
QGraphicsView will render in HiDPI if it has an ordinary QWidget to back it. If it is possible to achieve the desired effect using QGraphicsItems without OpenGL, this may be preferable until HiDPI support is improved.
I just found the solution: run your program with --graphicssystem native. Or if you can alter the sources you can use QApplication::setGraphicsSystem("native");.
I'm upgrading some Qt (C++ & QML) code from Qt4.8 to Qt5.1.
The Qt4.8 code is a trivial C++ "QML viewer" app subclassing a QDeclarativeView, and a bunch of QML.
It's been easy enough to change this to use Qt5/QtQuick2's QQuickView except for one thing:
The Qt4.8 app has a method for printing to PDF:
void MyQMLViewer::printToPDF(const QString& filename) const {
QPrinter printer(QPrinter::HighResolution);
printer.setOutputFormat(QPrinter::PdfFormat);
printer.setPageSize(QPrinter::A3);
printer.setOutputFileName(filename);
printer.setOrientation(QPrinter::Landscape);
QPainter painter(&printer);
render(&painter);
}
There were a few "environment" changes needed for Qt5.1 to get a QPrinter (ie add QT += printsupport to the project .pro file and #include <QtPrintSupport>), but there seems to be a more fundamental problem that QQuickView doesn't provide anything which is obviously compatible with the QGraphicsView/QPainter/QPaintDevice world of QPrinter (specifically, QQuickView has no render method, and all the drawing/painting/rendering-related methods it does have seem very tied up with OpenGL).
Any suggestions for how to best obtain high-quality PDF output from a QQuickView ?
(Note that I am not simply looking to screenshot the view; with QDeclarativeView, the code above generates PDFs with much better resolution even than the app fullscreened on my largest monitor).
I see the "QDeclarativeItem and QDeclarativeView" section of the "Porting QML Applications to Qt 5" guide does mention the loss of QGraphicsView-specific functionality, but doesn't offer any solutions (although it does mention workrounds for the case of items with custom QPainter-based rendering being bought into the new regime).
Update with some additional background info: an example of a PDF printed from QDeclarativeView using the above code can be found here. There's a png of the same view on a decent size monitor here. (This is actually the last slide in a series of slides; it's actually a gallery of the previous slides which bounces each slide onto the screen; if I had the time I'd look into the feasibility of the gallery being the only thing and transforming each scattered slide into view for a Prezi-style presentation; suspect QDeclarative isn't really performant enough though, which is one reason for wanting to get onto QtQuick2+Qt5.2's new scene graph stuff). Anyway, If you zoom the PDF up to 100% you'll see the text is... well it's better than anything a sanely sized image file will manage I think, although the sloping text baselines perhaps look a little uneven. There is also an issue with opacity values not being represented in the PDF (so the drop shadows and "bubbles" come out solid); another one of my motivations for trying for a QtQuick2 version was actually to see if translucent elements were dealt with any better. I assume the PDF just contains rasterized (or maybe vector outlines) of all the elements as utilities like "pdftotext" can't extract anything from it. I don't know enough about PDF tools to know how to inspect the internal structure of the thing but I assume there's some hierarchy there and the QML element tree is all laid out using a similar structure of nested transforms to the QML. Just for comparison and the sort of richness I'm potentially working towards here's a poster I did with LaTeX/Beamerposter; I find Beamerposter's rigid block structure rather limiting (and fiddly) compared with the possibilities QML seems to offer though. BTW, another thing on my wishlist/todolist is a QML element which can render LaTeX source, math and all, just to get the best of both worlds.
Update: Recent Qt blog post on all the backend changes in Qt5.8 has a comment linking to this Qt issue to use the new possibility of QPainter-rendered QtQuick scenes to render PDFs.
At the moment, there is no code in Qt that supports rendering of a scene graph to a pdf. The underlying data that is used to render Qt Quick 2 is held in the scene graph. As Laszlo suggests, you'd need to iterate the scene graph and generate PDF primitives. There's some impedance mismatch there, but it should be doable with some sweat. I think a proof of concept could be small enough to fit here, so I'll see how easy it could be :)
If you really want a PDF, you currently have no choice but to render it to a large image at 300dpi and wrap that in a PDF. The image doesn't have to be large if the poster has large areas of solid color. PDF can do do TIFF encoding and also JPEG encoding.
I have been looking far and wide to find out how, if it’s possible, you can fill a particular area in a QML screen with an OpenGL context and do custom OpenGL only in that context. I’ve seen plenty of demos where the QML components like buttons, etc lay on top or below a screen-wide OpenGL context (as is typically required by games), but I’d like to be able to situate several distinct OpenGL contexts within QML and have the QML file define how large they are, where they are positioned, etc.
Now, since Qt 5 is all OpenGL under the hood, it makes me wonder if using a Canvas element with custom drawing via javascript could result in similar rendering performance as custom OpenGL? This would be a meaningful alternative but it’s not clear to me how the javascript drawing is handled via runtime compared to custom OpenGL drawing.
What is it that you want to draw? QQuickPaintedItem may be the simplest way to go about it. When you're using QOpenGLFramebufferObject as the target, the painter will use OpenGL to paint the texture. It might be easier than writing your own OpenGL code if all you're doing is 2D.
I have a problem in my Qt Application. I have a QMainWindow with a QGraphicsScene and a QGLWidget as viewport.
The problem comes when I want to show another QGLWidget with other OpenGL information (for example, the general view and another window with the Top view).
In this case, the two windows don't work good and have problems with the transformation Matrix in OpenGL.
I try to use a shared widget (my first QGLWidget) and have the same context, but it fails anyway.
Any idea?
Thanks
This will be pretty difficult to without code. As a guess, perhaps you're not resetting your matrix operations to a known state before using them (see part 3 of the link)?