Even if it's old, I would try with this version if Qt to see if you have the same issue going on.

I don't believe X11 will allow negative coordinates, as traditional geometry uses the form AxB+C+D where the (+) can also be a (-) to cause the offset to be from the right hand side or bottom of the display. You should however be able to use coordinates that are GREATER than the visible desktop.

Hi, AFAIK, QSystemTrayIcon doesn't use dbus in its Linux backend. That might be related to your situation.

@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.

First, look and feel is a very vague thing. You should try to find something concrete, such as that the image is too light, too contrasty or something. I think you have not assigned a color table to the input image, which it should need just like the output image. But wouldn't the conversion have been done with that already...

This topic is old, but nevertheless, for the sake of completeness... Do not close ssh session, otherwise the forwarded display would become invalid.

Hi and welcome Maybe this has some interest. https://forum.qt.io/topic/56672/need-help-with-performance-of-qt-application-when-x11-forwarding

Hi and welcome to devnet, What backtrace do you get from the crash ?

Hi, Did you compile your application with your desktop Qt and then copied it over the RPi2 ?

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 if (no_pixmap_set) { pos = calculateTextPosition() QPainter::drawText(pos, text); return; } QLabel::paintEvent(event); 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. Thanks again!

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.

Hi and welcome to devnet, Which version of Qt are you trying to build ?

Compiled and rebuilt with Qt5.5.0 (beta). Interestingly, the warnings I received when running over VNC or when in high-dpi mode (QT_DEVICE_PIXEL_RATIO=2) no longer appear with Qt5.5.0. So, this is a definite improvement. However, I still receive the 147 (Unknown) error on launch when running over X11 forwarding.

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: main_window->show() with message: 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. I tried: resize(QApplication::desktop()->width(), QApplication::desktop()->height()); But no effect. @SGaist I have Gamma Ray, I guess it can help. Which informations are relevant?