@hskoglund I already have an underlying data store and I'm using a subclass of QAbstractTableModel to bridge it into a Qt GUI.
Making two in-memory copies of that data store and then jerry-rigging View-like synchronization between the actual data and two widget-specific data stores (plus all the requisite automated testing to make sure it works reliably) seems like the exact opposite of what I want.
Thanks for the reply. This is using intel graphics, and unfortunately your workaround does not help. After your message, I've tested the same code from a newer live image and also on my more up-to-date laptop (which has similar hardware) and I can not reproduce the issue in either of these cases. On the affected machine, I tried updating the intel driver and mesa, but this did not solve it, so I guess it probably needs the kernel or qt packages updated as well. Unfortunately, this is not an option at this point.
I've worked around the issue by re-implementing paintEvent() to do something like the following
Which seems to work just fine. In fact, re-implementing the paintEvent has given me the chance to animate the image changes which looks pretty nice, and it will be easy to simplify the code a bit when all my machines are fully updated and the glitch is gone.
The 8 bit paletteized option (PseudoColor in X11 speak I think) is an interesting idea. Last time I used that stuff was late 80s when true RGB displays were much more expensive; I was glad to see the back of it. We did indeed used to use a custom palette depending on what we were displaying: for greyscale images we used some palette with something like 224 greys and the rest for a few "UI colors"; for color images we had to dither to 3 bits red, 3 bits green and 2 bits blue and it still looked terrible. No idea whether Qt supports such customization; documentation at http://doc.qt.io/qt-4.8/qapplication.html#setColorSpec suggests Qt has it's own palette built-in for such purposes. I'd be amazed if anyone was seriously using this sort of palletized graphics display these days when it seems OpenGLES is defines the min.spec graphics for even the lowliest embedded chips.
But if you think the 3:1 or 4:1 reduction in bandwidth moving from a 24/32-bit "visual" to an 8 bit one is all you need, AND most of your bandwidth hogging content is greyscale images, then my instinct would be to just look into displaying the images by sending them to the server (display) side using a single channel OpenGL GL_R8/GL_INTENSITY8 texture, and appropriate GL commands to texture that to a view-filling polygon. This changes the solution focus a bit from messing around with Qt to messing around with OpenGL though.
I have similar problem with running Wireshark GUI on Centos7 using XMing on Windows 10.
I was trying to debug this issue, but it seems to be inside Qt libraries. The QtApplication constructor print "failed to get the current screen resources", and after quite a lot of code application finished at this line:
The X11 connection broke: I/O error (code 1)
XIO: fatal IO error 2 (No such file or directory) on X server "localhost:14.0"
after 363 requests (363 known processed) with 0 events remaining.
Just to be clear, it's not app crash, I did not describe it good.
Sometimes fullscreen mode look messy(look at image), let say it's happening every 10th time.
But, I can exit from that messy fullscreen and video plays in normal mode.