wysota:

You might be correct. I seriously have no idea how Qt's painting works. I dropped the question just to find the correct solution.
You gave so much explanation but only without a solution.
I'm wondering if you can afford me a direct solution, for example, affording an inherited class
Qt Code: 
  1. myQGraphicsView :: public QGraphicsView
To copy to clipboard, switch view to plain text mode 
and the demo code, which is really able to successfully display an QImage .

By the way, I didn't pretend to do anything.
If I pretend to be like that, I will never drop questions.
The reason why I drop the question is just to let the whole world to know I'm not familiar with that,
and I beg a solution sincerely.

So, can you please help?
All kinds of blame is of no use, compared to giving out a solution.

Seriously hope you can give me a hand, by a solution to demonstrate you can do it.

Looking forward to your solution.

Best Regards
JIA



Quote Originally Posted by wysota View Post
The problem is in your code. You can be chasing ghosts all the time or you can just correct your code and forget about the problem. Your code is clearly incorrect. You lack understanding of how Graphics View and Qt's painting works but you keep pushing pretending you do understand it. The paint event of the viewport is not called because the scene doesn't change and Qt takes the rendering of the viewport from the backing store. If you invalidate the whole scene then contents of the backing store is marked dirty and the viewport is repainted using your event because Qt thinks there are some changes in the scene.

repaint() and update() have different functionality - the first performs an immediate redraw, the other schedules one. A practical example:
Qt Code: 
  1. repaint();
  2. repaint();
To copy to clipboard, switch view to plain text mode 
will cause the paint event to be executed twice and
Qt Code: 
  1. update();
  2. update();
To copy to clipboard, switch view to plain text mode 
will cause the paint event to be executed once.