@maxwell31 said in Semi-transparent blurred window:

How would getting it to work on a system which does provide it work?

On Windows, there is this Qt page from the Qt Windows Extra documentation:
http://doc.qt.io/qt-5/qtwinextras-overview.html#dwm-and-glass-frame

Not sure how much of this is still relevant in Windows 10 though.

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

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.

Any one knows how to fix that? I have the same problem with Qt5.8.

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?