Is there any way to get the pixels that will be displayed on a QWidget, do some processing, and then display the processed pixels?
I can't seem to overcome the limitations of paintEvent(), hopefully someone can help.
QPixmap::grabWidget and QWidget::render will get me the pixels I need, but they cannot be called from within paintEvent(), since doing so will trigger an infinite loop.
I have tried running a timer, taking a snapshot, doing my processing, forcing a repaint, and displaying the saved image. This works to some extent, but on dynamic content (i.e. moving) it fails miserably.
I need to be able to do this from within paintEvent().
Is there any way to do this?
It sounds like your problem would be best solved by rendering the widget to a pixmap (within the paint event), doing your processing on the pixmap, then rendering the result to the widget afterwards:
void MySuperAwesomeWidget::paintEvent(QPaintEvent* event)
{
QPixmap pixmap(size());
QPainter painter;
painter.begin(&pixmap);
// Drawing code goes here
painter.end();
// Do processing on pixmap here
painter.begin(this);
painter.drawPixmap(0, 0, pixmap);
painter.end();
}
Normally, the technique I've described would be considered unnecessary (or even undesirable) because it is essentially a form of double-buffering and QWidget already provides double-buffering behind the scenes. However, in your case you are doing some processing on the drawing before performing a final rendering. As such, this is probably the best approach.
Related
This is a sequel to another question here in which I was not precise while describing my goal.
As mentioned in the linked question, I wish to save a QML which is embedded in a QQuickWidget and it is larger than the window size. The QQuickWindow grabWindow() method captures only the window area and hence I tried the following code after I visually displayed it:
QQuickWidget* content..
content->setSource(QUrl("qml:/main.qml"));
QPixmap *pm = content->grab(QRect(QPoint(0,0),QSize(-1,-1));
pm->save("someFilename.png", 0, 100);
So, it is definitely not the issue of saving image after rendering. The used QML code is just a plain Rectangle. The proposed solutions in the previous question only grabs content falling within the window.
Any suggestions? Thanks! :)
Addendum:
I have tried the following but didn't work:
QImage paintdev(largeWidth, largeHeight, QImage:Format_RBG32);
content->render(paintdev, QPoint(0,0), QRegion(QRect(0,0,largeWidth, largeHeight), QWidget::DrawChildren);
paintdev.save(fileName, 0, 100);
This should by logic solve the issue of window size since there is no window. Any comments?
Ok, so I solved it by manually shifting the QML by the window height and saving all the images from the window captures and collate it to form the original image.
Not too much work though, but I am still mystified by the QWidget render() method which did not work.
Thanks for all the replies!
If your QML content is larger than the window size, the part that is out of screen is not drawn. Hence, there is no way to capture something out of screen, unless you use 2 monitors and extend view. This last approach would work.
I'm making fractal creator software. So I need one scene per fractal and these scenes need to be "layered" because of zooming rubber band.
I've already tried to write it the "widget" way, so I had one custom widget called "canvas". In my canvas class I overrided paintEvent, and inside this event I rendered current fractal. Everytime when somebody clicked to menu with another fractal, I called update() method and new fractal was rendered. To zooming I used overriding of mouse events and update() of canvas. At the first time I repainted the whole canvas, but it was very very slow. After that I repainted only the part under the rubber band, but still slow when I'd like to select some bigger area and other problems with repainting.
So I've looked for another way to do it. Layers. I've found the QStackedWidget, but I didn't find way how to make visible both of my layers and the top one to be transparent. After that, I've found QGraphicsScene and this seems to be the best way to do it. But I don't know the correct procedure to do it. Below are two procedures I'm thinking about:
Create QGraphicsView
Instead of the widget, the canvas will be QGraphicsScene
I'll override some QGraphicsScene event (but I don't know which one - drawItems() is obsolete and override update() seems wrong to me, but maybe...)
When other fractal will be chosen, I'll repaint canvas by calling update() the same way as in my "widget" solution
In the foreground layer will be zooming rubber band
or:
Create QGraphicsView
Instead of the widget, the canvas will be QGraphicsScene
Every fractal will be the child of QGraphicsItem
When other fractal will be chosen, I'll remove the old one fractal
item and replace it by new one and probably call invalidate()
In the foreground layer will be zooming rubber band - I think, that
it's common behaviour of the QGraphicsScene isn't it?
Is one of my reasonings correct? Do you suggest anything else? Fractals are complicated in the calculations and It's very important to repaint only if it is necessary. Could you help me, please?
Thank you :-)
Edit: "zooming rubber band" explanation:
I'm sorry for my expression "zooming rubber band". It means scale (zoom) the area below the selection made by the rubber band - zooming the same way as in Photoshop CS5 (for example). And I'd like to know what part of the scene is repainted while selecting this way. If there is repainted whole scene, or the part of the scene below selected area, or there is nothing repainted and rubber band selection is done in separate layer.
I hope my explanation helped :-).
In Qt, a QGraphicsScene can be thought of as a world of items, with a QGraphicsView as a window into that world. Therefore, you should be adding items to the QGraphicsScene, based on QGraphicsItem (or QGraphicsObject if you want signals and slots).
In your situation, I'd create a Fractal class that inherits from QGraphicsItem and add that to the scene. Ensure to override the necessary pure virtual functions such as boundingRect and paint.
Do not calculate the fractal code in the paint function. I suggest the Fractal class stores a QPixmap (or QImage if you're drawing at the pixel level) and render the fractal to this. Then perodically, in the paint function, the Fractal class would render the contents of the QPixmap with a call to painter->drawImage or painter->drawPixmap; whichever is relevant in this case.
As for zooming, your Fractal class can then response to being scaled, appropriately changing the rendering on the internal representation.
I am making an app using Qt (currently 4.8) which displays a literal map from a large number of QGraphicsScene items. I would like to annotate the view with a scale. My requirement for the scale is that it is permanently fixed w.r.t the viewport widget. It needs to be updated whenever the view scale changes (zoom in, etc). There are other possible overlay items as well (compass, etc) so I'd prefer a generic solution.
I have looked at earlier questions around this which suggest:
using the ItemIgnoresTransform
using an overlay pixmap.
I tried IgnoresTransform but that way didn't work right: I couldn't figure out how to fix it in place in (say) the bottom corner of the viewport and was having some difficulty getting the text and lines always displaying in the correct size.
I scrapped that and subclassed QGraphicsView, adding an overlay pixmap by reimplementing the paintEvent (calls original one, then paints the overlay pixmap on top), and an alignment option to indicate where it goes. Coding some pixmap paint code produces a usable scale on the view. Yay! ... but it doesn't work with scrolls - I get "shattered" renderings of the scale all over, or sometimes no scale at all. I think this is because QGraphicsView::scrollViewportBy() uses viewport()->scroll() so I wondered if switching to ViewportSmartUpdate would help, but it doesn't help enough. I'd prefer not to switch to ViewportFullUpdate as that would likely slow the app down too much (there are millions of items in the scene and that would require a full repaint just to move around).
So. Any ideas from here? Would adapting my pixmap code to write to a new mostly-transparent Widget that is overlaid on the viewport be a better way?
Thanks for any help...
Though it may not be the best way of doing this, in the past I've added custom widgets to the window that holds the QGraphicsView / QGraphicsScene, which have the same graphic style as the QGraphicObjects in the scene. When the view is then used to move objects in the scene, or the scene itself, the items on the window remain in the same place.
Hope that helps.
In a Qt4 application, is it possible to tell inside a paintEvent() handler whether the repaint was triggered by a resize or not?
I have a widget which is very slow to redraw (a complicated plot), and I want to speed up resizes by just blitting a resized pixmap while the widget is being resized, and only redraw the widget when the resize is complete.
I've tried setting/unsetting a flag at the beginning and end of resizeEvent() but that doesn't seem to work (i.e. the flag is always off in paintEvent()).
I don't think you can easily do this. It's kind of hard to tell when resizing started/stopped, especially in a cross-platform way. I'd probably have a single-shot timer triggered by resizeEvent, that would render the image onto a QPixmap. If you get another resizeEvent while the timer is still active, just restart it. In paintEvent always paint the current pixmap, and after you render a new pixmap from the timer, call update() on the widget. Not an ideal solution, but it should work.
One approach you could take is to always paint the pixmap, but remember to recreate the pixmap "soon" if the window size has changed.
So, when the paintEvent comes in, if the size is different to current pixmap size, then paint the stored pixmap anyway, but then set (or reset) a QTimer to trigger a signal to a slot which will refresh the pixmap.
When this refresh method runs, it will re-render the pixmap and request a refresh of the widget.
Another possibility would be to have a look at how QMdiSubWindow::RubberBandResize is implemented internally, it may provide hints as to how to achieve this. Works only on a QMdiSubwindow if I recall correctly - it 'stops' painting (except a small window border with a transparent body) during resizing and fires one final resizeEvent (which triggers update/paint) when you stop resizing the window...
I'm migrating an application to Qt from MFC.
The MFC app would use GDI calls to construct the window (a graph plot, basically). It would draw to a memory bitmap back buffer, and then BitBlt that to the screen. Qt, however, already does double buffering.
When the user clicks and drags in the graph, I'd like that section of the window to be inverted.
I'd like to find the best way to do this. Is there a way to do something like grabWindow() that will grab from the widget's back buffer, not the screen? ... maybe a BitBlt(..., DST_INVERT) equivalent?
I saw setCompositionMode() in QPainter, but the docs say that only works on painters operating on QImage. (Otherwise I could composite a solid rectangle image onto my widget with a fancy composition mode to get something like the invert effect)
I could do the same thing as MFC, painting to a QImage back buffer... but I read that hardware acceleration may not work this way. It seems like it'd be a waste to reimplement the double buffering already provided to you in Qt. I'm also not so sure what the side effects of turning off the widget's double-buffering may be (to avoid triple-buffering).
At one point, I had a convoluted QPixmap::grabWidget() call with recursion-preventing flags protecting it, but that rendered everything twice and is obviously worse than just drawing to a QImage. (and it's specifically warned against in the docs)
Should I give up and draw everything to a QImage doing it basically like I did in MFC?
EDIT:
Okay, a QPixmap painter runs at approximately the same speed as direct now. So, using a QPixmap back-buffer seems to be the best way to do this.
The solution was not obvious to me, but possibly if I looked at more examples (like Ariya's Monster demo) I would have just coded it the way it was expected to be done and it would have worked just fine.
Here's the difference. I saw help system demos using this:
QPainter painter(this)
in the start of paintEvent(). So, it seemed to naturally follow to me that to double buffer to a QPixmap then paint on the screen, you needed to do this:
QPainter painter(&pixmap);
QPainter painterWidget(this);
... draw using 'painter' ...
painterWidget.drawPixmap(QPoint(0,0), pixmap);
when in fact you are apparently supposed to do this:
QPainter painter;
painter.begin(&pixmap);
... draw using 'painter' ...
painter.end();
painter.begin(this);
painter.drawPixmap(QPoint(0,0), pixmap);
painter.end();
I can see that my way had two active painters at the same time. I'm not entirely sure why it's faster, but intuitively I like the latter one better. It's a single QPainter object, and it's only doing one thing at a time. Maybe someone can explain why the first method is bad? (In terms of broken assumptions in the Qt rendering engine)
Assuming you don't really want to pixel values from your offscreen buffer (but rather, just drawing something again on top of it and blit again to the screen), you should use QPixmap as the buffer, not QImage. Using the latter disables all painting acceleration as Qt falls back using its software raster engine, hence the use QPixmap. If you use OpenGL graphics system, you can still benefit from it.
For an example on how to do this, check my last code on running the Monster demo, it needs to have an offscreen pixmap to due the motion blur effect via repeated painting with source over composition mode.
To disable Qt's backing store (which is generally not a good idea), use the Qt::WA_PaintOnScreen for your top-level widget.
A bit unrelated, but you might want to have a look QRubberBand widget.
Drawing on top of the graph area you should be able to use composition modes to invert. Draw white using the Difference composition mode. The following example is a subclass of a QLabel showing a pixmap:
void Widget::paintEvent(QPaintEvent *pe)
{
// make sure we paint background
QLabel::paintEvent(pe);
// paint the overlay
if (!selectionRect.isNull()) {
QPainter p(this);
p.setCompositionMode(QPainter::CompositionMode_Difference);
p.fillRect(selectionRect,QColor("#FFFFFF"));
}
}
alt text http://chaos.troll.no/~hhartz/yesManInverted.png
The simplist, most straightforward answer I know of is to do it like you were doing before, to a QImage, and use the QImage as the source for your widget on the screen.
Another option might be to add a transparent widget over your graph, which only draws the inverted part of the graph. I don't think this will optimize the drawing at all, however. It will likely cause the underlying graph to be drawn, and then the overlay of the inverted part.