@SGaist
Thank you for the reply, SGaist! I'll do it.

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.

@zepfan As told earlier the rendering is all done by OpenGL which in turn is handled by the GPU so that wont matter. The Timer is what is affecting the CPU.
QtQuick renderer is capable of handling thousands of items at a time. Please check it here. Also here are some benchmark examples.
Extremetable example loads 100000 items as and when required.
Anyway here are some more link that you may fine useful:
http://doc.qt.io/qt-5/qtquick-performance.html
http://www.sletta.org/apps/blog/show/42708211-looking-at-throughput-in-qt-quick
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
Try profiling your example.

Hi,

The only good answer is: benchmark.

In any case, Qt's State Machine Framework is not know to be slow so unless you're expecting speed of light it should run well enough.

This question may look stupid, are you build it with release version?

Looping is not slow, what takes time is string comparison, cause you basically do brute force string searching.
As Chris mentioned in normal circumstances this can't lag your GUI.

But if you fill your tree with huge number of data there might be a few performance problems.
Possible solutions:

a) QTreeView with custom model may be faster for multiple reasons including no need for frequent memory allocation and reduced data duplication.

b) Consider using additional data structure ( temporary or permanent) to speed up large modifications. Example will be usage of hash table which will speed up your search. But keep in mind that maintenance of such data structure may actually make it even slower depending on your usage case.

Hm. You would have to ask Qt developers (on IRC, or development mailing list) to get a definite answer. In Qt4->5 transition, the whole painting architecture was changed, so it is understandable there are differences in performance. What is not so good is that (from your data, and sporadic reports I see in other places) the performance of Qt5 is worse instead of better.