Drawing QPixmap Rects Over QWidget with QPainter - qt

I'll get serialized QPixmap Rects over the socket. I'll unserialize them and draw the rects in a QWidget Now my question is which QWidget should I use for this purpose ? is there any recontamination about how should I proceed ? at the moment I've decided to use a QPainter and draw using drawPixmap am I going in a wrong direction ?

It sounds like you might want use QGraphicsPixmapItem instances drawn on a QGraphicsScene with a QGraphicsView.
See Qt Graphics View Framework:
Graphics View provides a surface for
managing and interacting with a large
number of custom-made 2D graphical
items, and a view widget for
visualizing the items, with support
for zooming and rotation.
The framework includes an event
propagation architecture that allows
precise double-precision interaction
capabilities for the items on the
scene. Items can handle key events,
mouse press, move, release and double
click events, and they can also track
mouse movement.
Graphics View uses a BSP (Binary Space
Partitioning) tree to provide very
fast item discovery, and as a result
of this, it can visualize large scenes
in real-time, even with millions of
items.

Related

Qt custom widget update big overhead

We are trying to use Qt 4.8.5 for some Linux-based embedded devices in our company. I use Qt embedded without X server. I need to plot measured data and update them very often (20-30fps, but only a small portion of the widget). The system is ARM based, 400Mhz, have no GPU and no FPU. I subclassed QWidget and overridden the paintEvent(). I have WA_OpaquePaintEvent and WA_StaticContents set. For testing, my paint event is empty, and I call the update() function of the widget form a timer set to 50ms. My problem is that the empty update is eating up 30% of the CPU. The amount varies with the area of the update, so I think QT may redraw something in the background. I have read many posts but I cannot find the solution for my problem. If I comment out the update call, the CPU usage drops to ~1% (even if I generate a sine in the timer for testing the widget, which should be much more complex than an empty function call). My widget is rectangular, is not transparent and I want to handle the full drawing procedure from the paint event.
Is it possible to reduce this overhead, and handle the whole painting process by my own?
The "empty update" is not empty - it repaints the whole window :)
Have you read the below?
To rapidly update custom widgets with simple background colors, such as real-time plotting or graphing widgets, it is better to define a suitable background color (using setBackgroundRole() with the QPalette::Window role), set the autoFillBackground property, and only implement the necessary drawing functionality in the widget's paintEvent().
You should also be using QWidget::scroll(), since internally it does scroll the backing store of the window, and that's much more efficient than repainting the entire thing if only a tiny slice is added to it.

Setting Polygon ROI with mouse in Qt

Anyone have any idea how I can implement this? I'd like to have a function basically exactly like impoly in matlab or the "polygon sections" tool in imageJ, where you click to form a polygonal section and then each node can be adjusted, etc. I'd also like to have access to this function from Qt since I'm trying to make a gui for a small program I wrote.
Also, I'd like to avoid making calls to the matlab function because it's part of the image processing toolbox which isnt free. Thanks.
I think the best way to implement this is using the Qt Graphics View framework. Create a scene with an Item displaying your image in the back and add draggable Items on top representing the corners of your polygon.
Your selection tool should probably be a subclass of QGraphicsObject hosting the polygon corners as child items and a QGraphicsPolygonItem below the corners being updated whenever the user readjusts the selection. As QGraphicsObject inherits QObject, you can emit signals with a QPolygonF or QPolygon argument whenever the selection changes, informing other parts of your application
This demo should be a good example of the corner-adjust functionality you need.
Qt Pathstroke Demo
(uh well, the example implements the drawing and dragging of the control points from scratch.. I'm sure you can do it by using QGraphicsEllipseItem instead and react on their position changes)
I think you would need to code this yourself. There is an excellent example in the C++ GUI Programming with Qt 4 book (there's a PDF copy floating around online; I think it's legal) where they show you how to create a diagram with nodes and links. The chapter is called "Item-based rendering with Graphics View".
The basic idea is that you have some draggable nodes, which are QGraphicsItems with the ItemIsMovable flag set to true, and then some links that connect them, which are QGraphicsLineItems. All of these would go into a composite QGraphicsItem representing the ROI, and all of those would go into a QGraphicsScene, which would be displayed by a QGraphicsView.
Bottom line: there isn't a built-in copy of the MATLAB function, but all the tools are there for you.

QGLWidget for graphics and QT for GUI

I am trying to implement a custom OpenGL scene (wrapped in a QGLWidget), but still use QT controls (such as slide bars and buttons). I tried to make my main widget a QGLWidget, which has QWidgets as children. The child widgets seem to work (when I click a pulldown menu, its options appear), but the widget fails to draw (I see a white square). I changed the base class of my children widgets from QWidget to QGLWidget, and now QPainter calls work, but QT GUI stuff is still not displaying...
Some claim that a QGLWidget can not have QWidgets as children... I am not sure about that and I'm not willing to give up. By the way, I am using Visualization Library to draw the OpenGL scene, but it is just an OpenGL wrapper...
Any clues where the problem might be? Also, key events stop being processed for some reason when I add subwidgets to the GQLWidget.
Update:
I tried various combinations of widgets and layouts. It seems that the QGLWidget just gets drawn on top of anything. I even tried with raise() to arrange Z-depth of the widgets, to no avail. Is overlayGL() the only way to draw on top of an OpenGL widget?
Update 2
After months of trying, I figured out it is something related to QT. Whenever a QGLWidget is drawn on top of another QGLWidget, the first's background() function is not called. So a button is there and can be clicked, but it's not drawn. My workaround was to draw everything myself using QPainter - that works. What I found curious is, one has to use QPainter::startNativePainting() in order to draw with it. One would expect that they would overload start() in QPainter to call startNativePainting() whenever a QGLWidget is the painting device...
Another (maybe useful) fact is that QPainter calls CHANGE the Opengl context. So if you have another tool in cooperation with QPainter (in my case Visualization Library), chances are that one of them will crash (in my case VL which checks if the context state has been cleared before each frame).
There is a labs example of rendering Qt widgets using opengl it's a little old and I haven't tried it with the improved qglwidget in 4.8
There is also an issue with drawing over the top of a fullscreen QGLwidget - it was supposedly a bug in NVidia's openGL driver. It doesn't seem to have been resolved
https://bugreports.qt-project.org/browse/QTBUG-7556
If I were you I would use the QGLWidget as a viewport for a QGraphicsScene, then you can draw your widgets using a QGraphicsProxyWidget. That way you get a proper OpenGL viewport with the ability to put widgets in and manipulate them easily.
Did u try to call update() explicitly? I find that sometimes QGLWidget update the display stuff kind of slow.
This is an old question, but I recently had quite a bit of trouble with this, and this is what helped me -
Use QML/QT Quick. QML is a javascript-like language that allows you to layout your widget elements on a window and do basic processing on events like mouse clicks. There are a few other cool features, but the one that is most relevant to this question is that you can import qt widgets from C++ code.
So you can make a custom QGLWidget, import it into the QML window, and set the size/position/stick widgets on top of it in whatever you want, very easily. QT's Scenegraph example does a great job explaining this. Scenegraph's code is also included as an example in at least Qt Creator 3.2.1 Open Source (that's the version I have anyway)

More efficient central widget in a QMainWindow: QGLWidget VS QGraphicsView

I am using a QMainWindow for my app and want to do some openGL rendering. 2 approaches:
1) set as central widget a QGLWidget and do all the rendering there,
OR
2) set as central widget a QGraphicsView, set the viewport to my QGLWidget to create the rendering context and do the rendering in my scene.
Which one would be preferable when it comes to efficiency? (I will be adding some other objects later which in the former case are going to be QGLWidgets (as child widgets) and in the latter QGaphicsItems)
Using a QGLWidget and rendering with OpenGL directly will in most cases be more efficient, but it will require more work to manage a dynamic set of rendered items. Using the QGraphicsView framework will have some overhead, but it provides many features for managing rendered items. The amount of overhead for QGraphicsView will depend upon various details, but in most cases it will not be a bottleneck and it can be adjusted for various usage patterns.

Transparent QLabel in QGraphicsView a good idea?

I'm trying to write a piece of software that allows one to click on a video frame and mark the x,y coordinates of a location in the frame. To design this, I've been wanting to use a QGraphicsView subclass and, on the mouse click event, instantiate a QLabel with a PNG image "target" on where the click occurred.
So far I've gotten everything to work except getting the QLabel to be transparent. All of the info I've found online doesn't seem to work with the latest Qt. Should I totally rethink my design and utilize some sort of integration with painting in Qt? Or is there a way to salvage the QLabel PNG implementation and indeed make the label transparent?
Thanks,
--Dany.
QLabel inside QGraphicsView is not a good idea indeed. QGraphicsView was designed to host QGraphicsItems, to display an image you should use QGraphicsPixmapItem.
Embedding QWidget into QGraphicsView has some overhead and was really designed for complex widgets that can't be easily reimplemented in terms of QGraphicItems.
I think a QGraphicsItem with ItemIgnoresTransformations flag is just what you want.

Resources