Regression Problem in Xorg 7.3

[Anthony L. Awtrey]

Hello the list,

Short Version:

I've got a weird regression performance problem between Xorg 6.5 and
Xorg 7.x and I don't know where to report the bug or the details that I
need to provide to hopefully get a fix. Basically, it looks like that
some image and pixmap display operations now take 50% to 100% longer in
Xorg 7.3 when compared to Xorg 6.5. Using Debian Etch and Debian Lenny
(pre-release) as baselines, I can demonstrate this issue very clearly.
Details including x11perf and test applications are here:

http://www.awtrey.com/files/xorg-performance/Xorg_Performance.tar.gz

Long Version:

I've got a Debian-based touchscreen application that runs on Panasonic
Toughbook hardware, specifically the CF-18, the CF-19 and CF-74 models.
Panasonic revs the hardware periodically without changing the model
number and the "Mark III" version of the CF-74 utilizes a "Intel
Corporation Mobile Integrated Graphics Controller" that has required
that I look past our Debian Etch baseline, which runs a 2.6.18 kernel +
Xorg 6.5, to get hardware acceleration to work. Once I home rolled the
2.6.23 kernel and hand-built the Debian packages for Xorg 7.3, I noticed
a performance problem relating to the display of images. To prove that
it wasn't something I introduced in my franken-distro, I was able to
reproduce the same issue with the current pre-release of Debian Lenny
running 2.6.22 and Xorg 7.2.

The touchscreen application is written in Qt4, so to minimize the
possibility of the issue being related to Qt4 we scripted both an
example application in C++ / Qt4 and a Python/GTK2 script that
demonstrates the same issue using two different implementations.

In most cases Xorg 7.x is faster than Xorg 6.5, but in some very
specific cases (unfortunately the ones that I need) it is much, much
slower. The best example of this is the Python / Gtk2 code. In one case,
we used the lower level Gtk pixmap functions to display an image with a
transparent overlay as fast as possible. As expected, the test runs
faster on Lenny. However, if we use the more typical high level
Gtk.Image functions, Lenny is much slower than Etch. Here are the actual
results from runs on our CF-18 hardware:

Debian Etch

  cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py
  Time to draw a pixmap over a pixmap 5000 times: 15.002710

  cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py
  Time to flip the blue overlay 500 times: 17.241337

Debian Lenny

  cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py
  Time to draw a pixmap over a pixmap 5000 times: 12.012802

  cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py
  Time to flip the blue overlay 500 times: 25.642715

The Qt4 test application we provided is much closer to what the
touchscreen application actually does and when you run the application
under Debian Etch, touching the "Toggle" button to display the overlay
happens immediately. When you do the same thing under Debian Lenny, you
see a very noticeable 1/2 second hesitation before the overlay displays.
Since this is how we pop menus up all over our touch screen application,
the usability of the application has been significantly reduced.

I searched the bug list and couldn't find an issue that seemed to
address this performance issue. I don't know if it is related to the
Intel driver (we tried 2.0, 2.1 and 2.2 with no improvement) or some
other library or component of Xorg. Any help or insight you guys can
provide would be greatly appreciated. I'll be happy to test anything you
suggest.

Tony