qt4 and X11 remote display

As of Qt4 a lot of cad operations went in the toilet.
What we've still seen lately is totally unacceptable performance when exporting displays over even a gigabit network.

One application shows digital camera photos and allows a user to measure corresponding features. This one basica application lag time to clicking on an image to when the glyph shows up is 3 seconds. Lag time for display change is about 5 seconds. During that time network traffic is observed to spike at 20-30MB/s.

Another application was ported from qt3 to qt4. It allows an operator to click very fast to essentially trace features using vectors. This application also has become utterly intolerable running over a gigabit network.

Are there any quick suggestions/hints/strategies to eliminate these problems with qt4 ?

I have not seen these problems, and routinely use Qt applications over X11. I have seen problems with some Windows X11 servers having problems over VPNs, so if you're on Windows you might try a different server to see if it makes a difference.

This is all over linux based X11. The processing software must be run on linux to avoid the really bad windows network and IO performance.

FYI these are GIS and photogrammetry applications. It's also not just our software, but a partner who ported their qt3 GIS app over to qt4 (not sure if they're using qt3 support, we certainly aren't). Their customer who is complaining has 10G and is having bad problems. Note the biggest problems show up with drawing interactive vector graphics on imagery (these are layers of imagery, not just single images). When Qt4 first was released the formal qt support groups had more than a few threads about bad vector performance in general.

Could this related to everything in qt4 being double buffered and grossly excessive cross chat with the x server? Also because of these types of problems we dumped Qt and used fltk for our interactive apps. The speed of fltk is absolutely amazing but its still an unfinished toolkit.

You might try Qt 4.5 with the raster engine. Maybe it gives better results in your case than the x11 backend.

Did a search for raster engine and came up on this comment regarding their raster engine:

"All of the above mentioned optimizations are minimizing work done in the raster engine, our software backend for QPainter, so it is very unlikely that this will affect exported displays."

http://labs.trolltech.com/blogs/2008/09/22/sorry-guys/

Not sure what this means though.

However I also bumped on this page:

http://labs.trolltech.com/blogs/2008...-for-the-blit/

and hunted down any and all uses of QPixmap/drawPixmap in the code and replaced with QImage/drawImage. This helped make our application more tolerable, but certainly still totally unacceptable for fast "click tracing" operations.

Just tried 4.5 beta1 with both raster & opengl engines...no change

I think you need to get in touch with Qt support for this.

Well we did dump our maintenance contract. I only started exploring this again because of the LGPL announcement (we got tired of ever increasing maintenance fees while it seemed like qt4 wasn't really making things better).

I did some more looking into that code and I do see ways of making our own application faster, it just requires a helluva lot more code to limit redraws which definitely was not an issue with qt3. Back to the reasoning behind us dumping maintenance.

Have you verified the problem is related to the X protocol? How much bandwidth does the application consume?

A single click results in a spike of 30MB/s on a full screen 1920x1200 application.
Total network transfer itself is about 15MB on that, using a single event as the driver. since that's network transfer itself that definitely contributes to the perceived slowness. I used iftop to gather some of these statistics.

On our own application I probably could spend a couple days trying to totally fix this problem, although our own application is good enough remotely. I'm a bit more concerned about our partner's application which processes our output.

Customer just confirmed....the windows build of that application also runs unacceptably with windows terminal server...

"Speed" won't tell us anything. How many bytes are transferred per click?

Is your main window QGraphicsView (previous QCanvas) based? Or something else? If graphics view, you can sometimes get into pathological cases where the bounding rects overlap such that everything needs to be redrawn even if only a small line changes. If this is the case, you may want to play around with QGraphicsView::setOptimizationFlags().

But without your source code it's had to track down what's wrong. That's where support contracts come in handy, you don't have to share your source with the world in order for someone to figure out your problem.

No we're not using QCanvas or QGraphicsView

We have extremely rigorous demands for sub pixel accuracy and have all of our own precise transforms. My partner actually worked with the developer responsible for qt's engine at qt4 was being written to try get these type transforms introduced. That didn't happen.