I am working on a project that presents live data acquired in real-time using the QCustomPlot plug-in for Qt. The display has a black background color, and the multiple channels of data are colored differently. When taking a screenshot, we would like to make it printer-friendly, so the background is white and all data is black. I am thinking of a solution like this:
Change all colors the way I want by manipulating the pointers for the graphical objects
Grab the screenshot using QWidget::grab() to get a QPixmap
Change all the colors back to normal
This did not work at first, because the system could not change the colors in time for the screenshot to be taken. So I used a QApplication::processEvents(), and it all worked on my Mac.
However, it does not work on a Windows 7 (which is required). Any ideas what to do?
Code:
QSting fileLocation = "...";
toggleColors(false); //function to toggle the colors
QApplication::processEvents();
QPixmap shot = grab();
toggleColors(true);
shot.save(fileLocation, "png");
Again. It works on Mac, but not Windows.
Update 1. Content of toggleColors include:
if(enable)
ui->plot->setBackground(QBrush(Qt::black));
else
ui->plot->setBackground(QBrush(Qt::white));
ui->plot->repaint();
I also tried with ui->plot->update() instead.
I am not sure what is the problem on Windows specifically, but I recommend you calling QWidget::update() on the given widget. That forces the next update to re-render itself.
On the other hand, I'm not sure why toggleColors() didn't somehow cause that to happen.
Also, ensure that QWidget::setUpdatesEnabled(bool) wasn't set to "false."
It appears the problem lies with QCustomPlot. It was solved by performing a ui->plot->replot() which is specific to QCustomPlot and not QWidget.
Related
I just started creating a X11 application.
I am rendering text to the display using XDrawString(...).
Now, given I'd like to add something like a clock, some counter or something that changes constantly, how would I "override" the already rendered text?
The way it currently is that it just renders again and leaves the old contents behind.
From Java I know "BufferedImages", where I would render everything before transferring it to the actual screen. With this, the old contents on the display would be overwritten.
Is there a similar mechanism in X11 or do I have to paint the whole screen white and then render everything again on top of it?
I am using C++ along the X11 libs with the gcc compiler.
Thanks!
I think the only option is to use the X11-DoubleBuffer Library for C++. I now settled with SDL instead.
After upgrading to qt version 6.2 from qt5 I faced the problem with starting the app in the maximized mode. The widget is first painted with it's normal size and then repainted fine. The intermediate state is shown on the gif below:
The code of the app from the giff comes together with Qt (my version is Qt-6.2.3) and called "styles" (path is Qt/Examples/Qt-6.2.3/widgets/widgets/styles) or can be found on the qt.io. I have just changed widget.show() to widget.showMaximized() in main.cpp.
I figured out that sometimes widget starts fine, but this is rather rare. Also the more complicated widget is, the more time it takes to correctly paint it on the first show.
In the example from the gif the start is so quick that it is almost invisible, but in the heavy app I'm working with this slow startup really catches the eye.
If this can not be easy fixed, does anybody have any idea how to mask this behaviour? I thought about painting the widget on the virtual framebuffer and moving it back to the main display right after first show, but I did not find any easy means to create it in c++.
Any help is appreciated.
EDIT:
I finally reported a bug to qt developers.
See QTBUG-104357
I am currently having a problem with Qt graphics view framework namely, I want to clear my QGraphicScene background color and then run a function to take a webcam picture. So far when I use QWidget.repaint the screen only got repaint after about 1 second and by then the camera function has been called and the image captured is always off. Here is how my code currently look like.
//Scene is a QGraphicScene
//View is a QGraphicView
//Camera is a camera object
Scene.setBackgroundBrush(Qt::Blue)
View.repaint()
Camera.Capture()
I have tried wrapping the repaint() call with another function and use signal and slot call but it still fail. I want to know if there is a way to pause the program until the screen has been refreshed.
A QGraphicsView has a bit more going on than most QWidget subclasses and I'm not familiar enough with it to say what is going on for sure but I might venture a guess that your problem is related to the fact that the scene is actually rendered onto the view port widget. Perhaps calling viewport->repaint() will give you the results you are looking for?
Also, unless you really need to be using the webcam in this scenario, you could call ::render() on your scene and pass it a QImage which you could save directly to a file.
I have a top-level Qt widget with the FramelessWindowHint flag and the WA_TranslucentBackground attribute set. It has several children, each of which draws an image on it. They are not in a layout. Instead, I simply move them around when something changes (it is not user-resizable).
There are two states to the window - a big state and a small state. When I switch between them, I resize the window and reposition the children. The problem is that as the window resizes, a black box is briefly flashed on the top-level window before the images are painted over it.
The problem goes away if I disable Aero. I found brief mention of this problem being fixed in an article describing a new release of Qt (this release is long past), but it still doesn't work.
Any ideas why?
Thanks!
I don't have experience with Qt specifically, but I have worked with other windowing toolkits. Typically you see this kind of flashing when you are drawing updates directly to the screen. The fix is to instead use Double buffering, which basically means that you render your updates into an offscreen buffer (a bitmap of some sort, in the purest sense of the word), and then copy the entire updated image to screen in a single, fast operation.
The reason you only see the flickering sometimes is simply an artifact of how quickly your screen refreshes versus how quickly the updates are drawn. If you get "lucky" then all the updates occur between screen refreshes and you may not see any flicker.
I'm trying to implement some drag and drop functionality for a material system being developed at my work. Part of this system includes a 'Material Library' which acts as a repository, divided into groups, of saved materials on the user's hard drive.
As part of some UI polish, I was hoping to implement a 'highlight' type feature. When dragging and dropping, windows that you can legally drop a material onto will very subtly change color to improve feedback to the user that this is a valid action.
I am changing the bar with 'Basic Materials' (Just a CWnd with a CStatic) from having a medium gray background when unhighlighed to a blue background when hovered over. It all works well, the OnDragEnter and OnDragExit messages seem robust and set a flag indicating the highlight status. Then in OnCtrlColor I do this:
if (!m_bHighlighted) {
pDC->FillSolidRect(0, 0, m_SizeX, kGroupHeaderHeight, kBackgroundColour);
}
else {
pDC->FillSolidRect(0, 0, m_SizeX, kGroupHeaderHeight, kHighlightedBackgroundColour);
}
However, as you can see in the screenshot, the painting 'glitches' below the dragged object, leaving the original gray in place. It looks really ugly and basically spoils the whole effect.
Is there any way I can get around this?
Remote debugging is a godsend for debugging visual issues. It's a pain to set up, but having a VM ready for remote debugging will pay off for sure.
What I like to do is set a ton of breakpoints in my paint handling, as well as in the framework paint code itself. This allows you to effectively "freeze frame" the painting without borking it up by flipping into devenv. This way you can get the true picture of who's painting in what order, and where you've got the chance to break in a fill that rect the way you need to.
It almost looks like the CStatic doesn't know that it needs to repaint itself, so the background color of the draggable object is left behind. Maybe try to invalidate the CStatic, and see if that helps at all?
Thanks for the answers guys, ajryan, you seem to always come up with help for my questions so extra thanks.
Thankfully this time the answer was fairly straightforward....
ImageList_DragShowNolock(FALSE);
m_pDragDropTargetWnd->SendMessage(WM_USER_DRAG_DROP_OBJECT_DRAG_ENTER, (WPARAM)pDragDropObject, (LPARAM)(&dragDropPoint));
ImageList_DragShowNolock(TRUE);
This turns off the drawing of the dragged image, then sends a message to the window being entered to repaint in a highlighted state, then finally redraws the drag image over the top. Seems to have done the trick.