[KDE/Mac] Fixing graphics problems in KDE/Qt on Apple OS X

Ian Wadham iandw.au at gmail.com
Fri Apr 25 05:15:07 UTC 2014


Hi guys,

I am writing here rather than macports-dev because I think KDE
and Homebrew guys might also be interested.

But I am looking for action on MacPorts at least, to make KDE apps
look and run better in the next year or two.

PROPOSED ACTION:

To standardise on using Raster Graphics in qt4-mac and KDE on
MacPorts as soon as possible.

I have found that it is not as easy as installing qt4-mac with +raster.
See DETAILED ACTION AND CONCLUSION below.

DISCUSSION:

Here are three problems that all have the same underlying cause:

    https://bugs.kde.org/show_bug.cgi?id=333429 Black-on-black
    https://bugs.kde.org/show_bug.cgi?id=332335 Black push-buttons
    https://bugs.kde.org/show_bug.cgi?id=333336 Faulty rubber-band selector

Another is that at least four KDE Games experience slow graphics,
making KBounce and KBreakout almost unplayable, KGoldrunner
rather jerky and KJumpingCube lose some of its animations.

Any other KDE or Qt app that relies on fast graphics, fast animation,
rubber-band selection or Plasma-style widgets (such as buttons), is
likely to be affected --- and that could be quite a lot of apps.  Sometimes
these bugs will just make graphics effects look glitchy or of poor quality,
sometimes they will cause slow response and sometimes the app
will be unusable or give a bad first impression that will turn off users
--- as happens in KBounce and KDevelop.

The story behind all this is that Qt has been working for years to make
its graphics libraries fast and truly cross-platform, but there have always
been problems on one platform or another.  Finally they decided to
write a cross-platform paint engine functionality called Raster
Graphics [1].

It is done mainly in software, so you would think it would be slow, but
not so.  It is actually faster in most ordinary applications, such as all
the GUI apps in KDE and Qt.

Why?  Because it can do almost all its work in big buffers and not
have to take lengthy trips through the local library and OS or up
and down the line to the X11 server, before it gets access to the
graphics hardware.  I can quote references about this [3].

So Qt has now made Raster Graphics "standard" on ALL platforms
in Qt 5 and on Linux, Un*x and Windows in Qt 4.8.

And there's the snag.  It is not "standard" in Apple OS X, because
there were too many bugs in it at the time of the first Qt Mac 4.8 release.
Most of those bugs have now been fixed and those that remain do
not seem nearly as bad as the ones above, which you get when
Qt uses Apple CoreGraphics. See:
    https://bugreports.qt-project.org/browse/QTBUG-12615
Please read the comments.

So I think it will be a great improvement to standardise on
Raster Graphics in qt4-mac and KDE on MacPorts.

DETAILED ACTION AND CONCLUSION:

I tried installing qt4-mac with +raster, but it made only one of
the reported bugs go away (the black-on-black).  The other bugs
seem to be because Qt and KDE apps start in Apple CoreGraphics
mode, so that they can paint an Apple OS X main window and widgets,
but then Qt's QGraphicsView suite of library classes fails to switch
back to Raster, the installed preference.  I found I could force it to
switch in one of three ways [2]:

  1. Put --args -graphicssystem raster on the "open" command-line.
  2. Define environment variable QT_GRAPHICSSYSTEM=raster,
      either by exporting it or by prepending it to the command line.
  3. Execute QApplication::setGraphicsSystem("raster") in the app's
      code before the QApplication object is constructed.

Libkdegames already has a way of doing 3 for all KDE Games apps
at once, but it is not feasible to do that in kdelibs, because kdelibs is
frozen as of v4.8, unless you wish to patch it in MacPorts and Homebrew.

I think either of 1 or 2 could be made part of MacPorts installations of
all KDE apps and maybe also Qt apps.

So can we proceed with method 1 or 2 in MacPorts as soon as possible?

I am sure that will eliminate dozens of bugs at one fell swoop and will
make KDE apps from 4.12, 4.13 and 4.14 look and work better and
faster until KF 5 ports of the KDE apps begin to appear.

All the best, Ian W.

[1] Not to be confused with the raster graphics we all use today on our
     screens and desktops, which was invented by Xerox PARC circa 1975.

[2] http://qt-project.org/doc/qt-4.8/qapplication.html#setGraphicsSystem

[3] https://bugs.kde.org/show_bug.cgi?id=333429#c12
     contains further references.


More information about the kde-mac mailing list