PDA

View Full Version : QImage -> QPixmap Issues all white on display



IanC
18th February 2012, 02:55
I had a program working that was getting jpg images over the network loading it into a QPixmap with the loadFromData() method and assigning the QPixmap to a QLabel with setPixmap().

The user interface was not very responsive so I decided to speed things up a little bit I by moving the jpeg decoding over to a separate thread. I found out that QPixmap couldn't run in a secondary thread so my plan was to load the data into the QImage on the secondary thread and then on the GUI thread load the QImage into the QPixmap with fromImage().

When I did this I ended up with a white image being displayed on the screen. To verify that things were working correctly I wrote the JPEG data to a file before loading into a QImage and then had QImage save it to another file. Both of these two files have the images I expect. I even tried moving the QImage loadFromData() back to the GUI thread just to rule out threading issues.

I know it's got to be something I'm doing wrong but it seems so straightforward. Here's the code snippet of what I'm doing.

bool foobar(uchar *p_imgbuf, int img_size)
{
QImage image;
QPixmap my_pixmap;
QLabel *p_label;

p_label = new QLabel();

status = image.loadFromData(p_imgbuf, img_size,"JPG");
my_pixmap.fromImage(image);
p_label->setPixmap(my_pixmap);
}

wysota
18th February 2012, 09:11
What's the value of status? By the way, QPixmap has loadFromData() too, you don't have to go through QImage. Also, where do you free the buffer you pass to this method? How do you run this method?

IanC
18th February 2012, 18:17
status returns true from both QImage loadFromData() and QPixmap fromImage().

I was using QPixmap loadfromData() but I wanted to move that JPEG decode off of the GUI thread and QPixmap can't run in a secondary thread. The code I posted moved it back to the GUI thread just to remove any threading issues while I was tracking down this issue.

The buffer passed to QImage keeps getting overwritten with newer images until the window is closed. The method is called whenever a new image is received over the UDP socket.

Ian

wysota
18th February 2012, 18:27
So you got rid of all the threads? What if you change your uchar* buffer to QByteArray that contains the data?

IanC
18th February 2012, 22:53
This is interesting I just added a save of the QPixmap and it fails. Which certainly implies that something is going wrong in moving the QImage into the QPixmap. Wish I could get more info.

What difference would sending QByteArray make since that's going into the QImage, but my problem seems to be in converting the QImage into a QPixmap.

Thanks

wysota
18th February 2012, 23:12
but my problem seems to be in converting the QImage into a QPixmap.
This works just fine in thousands of applications worldwide so I guess it's not the problem. Overwriting the buffer you're using for your image might be more problematic though. Ignoring my questions will not bring you closer to a solution as well.

IanC
19th February 2012, 00:42
Wysota I didn't mean to offend you and I certainly wasn't trying to imply that I'd found a bug. Going from a QImage to QPixmap is all over the place in examples which is why from the start I've said I must be doing something wrong.

I also wasn't ignoring your question I was merely asking what difference do you think using a QByteArray vs the uchar* going into the QImage would make since it seems like the issue I'm having is with the conversion from a QImage to a QPixmap not with the byte buffer into the QImage.

If overwriting off the memory was an issue I would expect the first image into the QPixmap would be good but the rest would be bad, but even the first one is just all blank and the save to a file fails.

Anyway I tried switching to a QByteArray into the QImage and the result was the same. QImage's writing out correctly, QPixmap failing to write and all white on the screen.

wysota
19th February 2012, 07:09
I will repeat my unanswered questions then:


How do you run this method?
So you got rid of all the threads?

IanC
20th February 2012, 01:47
Gotha, somehow I must have missed those original questions.
- In this code yes everything is running on the main GUI thread (for solving this problem). The code which collects up the UDP packets into a frame runs on a separate thread and sends a signal that the frame is complete with an index of the frame inside the buffer pool.
- When the slot is received (on the main GUI thread, I verified this with the debugger, and there are no messages that the QPixmap can't be used on the non gui thread) it calls a method to get the address of the buffer and the length (yes they are protected by a mutex), it then calls the routine which i provided a snippet from. When this routine finishes the caller release the buffer so the secondary thread can reuse it.

I just tried something else today. After I load the QImage from the buffer I call QImge.isNull() which returns false. After I convert the QImage to the QPixmap I call QPixmap.isNull() and it returns true. So something is going wrong with that conversion, even through QPixmap.fromImage() is returning true.

IanC
20th February 2012, 04:43
I figured out what the problem was. Somehow I didn't see that fromImage was a static member so my code was bogus
my_pixmap.fromImage(image); should have been my_pixmap = QPixmap::fromImage(image);

Spitfire
21st February 2012, 11:04
I wonder why do you use QImage as a temporary data container?
Wouldn't it be easier and faster to use QByteArray to store the data and load it directly to QPixmap?

IanC
21st February 2012, 14:29
Because my original goal was to do the JPEG decoding on a secondary thread. QPixmap cannot run on a secondary thread but QImage can. Therefore I load (which does the decode) QImage on the secondary thread, then let QPixmap render the image on the GUI thread.