qt4 and X11 remote display

**bnolsen** · 22nd January 2009, 04:31

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.

**wysota** · 22nd January 2009, 06:55

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

**bnolsen** · 22nd January 2009, 16:44

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

**Brandybuck** · 22nd January 2009, 19:35

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

**bnolsen** · 23rd January 2009, 03:56

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.

**wysota** · 23rd January 2009, 08:58

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

**bnolsen** · 23rd January 2009, 19:13

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

**wysota** · 23rd January 2009, 21:33

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

**Brandybuck** · 23rd January 2009, 21:59

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.

**bnolsen** · 23rd January 2009, 23:33

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.