In all themes except "Strange Geometry" KBounce's message popups come out in unreadable black-on-black format on the Apple OS X platform, including the startup message "Click to start a game" and the scoreboard message. This makes the game unplayable. See screenshots attached. Reproducible: Always Steps to Reproduce: 1. On an Apple Mac, install KBounce (e.g. using MacPorts). 2. Start KBounce. Actual Results: The default theme (Egyptian) shows a black-on-black message ... Expected Results: A semi-transparent message widget, floating over the play area, with a readable message in black (or very dark) text.
Created attachment 86098 [details] How KBounce looks on startup on Apple OS X
Created attachment 86099 [details] How KBounce SHOULD look (in other themes) on startup in Apple OS X
I know how to fix this problem and will submit a patch soon, but the problem seems to be widespread in KDE apps and libraries when running on the Apple OS X platform, so I am writing a general post about it on the kde-devel mailing list.
Can you select "-graphicssystem raster" on OSX? Still an issue? QPainter::setOpacity() should iirc be slow on non raster graphicssystem backends, but since and as long your background is opaque, simply don't use destination_in but sourceOver. Another issue I ran into in this regard, but rather affecting the raster graphicssystem (then?), maybe extending to Quartz, though, was that detaching a 32bit pixmap was broken and resulted in an opaque alpha channel. You rather had to QPixmap tmp; if ( useRaster ) // raster engine is broken... :-( { tmp = QPixmap(upper.size()); tmp.fill(Qt::transparent); QPainter p(&tmp); p.drawPixmap(0,0, upper); p.end(); } else tmp = upper; // this will detach tmp from upper as soon as the painter is opened. QPainter p; if (opacity < 1.0) // this blends out the upper pixmap { p.begin(&tmp); p.setCompositionMode(QPainter::CompositionMode_DestinationIn); p.fillRect(tmp.rect(), QColor(0,0,0, opacity*255.0)); p.end(); } p.begin(&lower); p.setCompositionMode(QPainter::CompositionMode_SourceOver); p.drawPixmap(x, y, tmp); p.end();
(In reply to comment #4) > Can you select "-graphicssystem raster" on OSX? Still an issue? > Thanks very much, Thomas. That worked wonders. The "black on black" goes away in both KBounce and KPat. Some bonuses are that the unplayable slow-motion in KBounce on Apple OS X goes away and that a problem in Palapeli also goes away (bug 333336, failure to display the rubber-band properly when using it to select jigsaw puzzle pieces). I have not yet investigated why KGoldrunner, a faster busier game than KBounce, has never been affected by slow-motion on Apple OS X. I installed KDevelop on MacPorts, but the bad news is that bug 332335 does NOT go away when I use -graphicssystem raster. The usage of CompositionMode_DestinationIn in this case is in the code of Plasma::ToolButton, so maybe it is unaffected by KDevelop's command-line. I do not know why raster is not already enabled in MacPorts' qt4-mac package. I will raise the matter with the MacPorts developers. Macports' qt4-mac is at v4.8.5 and raster is supposed to be the default from Qt 4.8 onwards. Thomas, you might be interested in https://svn.reviewboard.kde.org/r/6810/ which enforced use of raster graphics on all KDE Games back in Qt 4.7 days, but the code is in only the KDE Games library and is conditional on Q_WS_X11. Clever stuff, though. If DestinationIn does not work in native Mac graphics, I do not know why that fact has not been documented in http://qt-project.org/doc/qt-4.8/qpainter.html#CompositionMode-enum which only says that RasterOp_* modes are a no-no in Mac native graphics. > QPainter::setOpacity() should iirc be slow on non raster graphicssystem > backends, but since and as long your background is opaque, simply don't use > destination_in but sourceOver. > QPainter::setOpacity() is quite fast enough in KBounce, because the display is not animated. It is just a popup message box, which is semi-transparent so as to show the state of the game (frozen) underneath the message. I might just change the code to use QPainter::setOpacity(), and make it simpler and more readable (hence more maintainable by others). > Another issue I ran into in this regard, but rather affecting the raster > graphicssystem (then?), maybe extending to Quartz, though, was that > detaching a 32bit pixmap was broken and resulted in an opaque alpha channel. </snip> > Not applicable in KBounce or KPat, but might be in other KDE apps and libraries.
(In reply to comment #5) > I do not know why raster is not already enabled in MacPorts' qt4-mac > package. raster should be (is on X11) the default since Qt4.8 and the only graphicssystem in Qt5 > If DestinationIn does not work in native Mac graphics, I do not know why > that fact has not been documented in > http://qt-project.org/doc/qt-4.8/qpainter.html#CompositionMode-enum which > only says that RasterOp_* modes are a no-no in Mac native graphics. Supported != Bugfree. On the native graphicssystems, the outcome is determined by the driver, so it could be a bug in Qt, Quartz or the driver (wild guess: AMD chip?) - ie. differ on various Mac HW. Probably nobody just ever noticed. QPaintEngine has some internal capability list, which eg. on X11 ever enforced gradients to be done on the raster graphicssystem, since it was not supported by drivers (read: fglrx, eg. nvidia could always do at close to GL speed, but had issues with multistop gradients as well) Frequent graphicssystem changes or issues in drivers (the nvidia driver sucked at allocating pixmaps) would be the cause for major slowdowns as well. (Therefore the turn towards raster only; though the native systems could -on GPUs- do much better performance, their quality is too unreliable)
We are not out of the woods yet with this one, nor with bug #333336 (rubber-banding in Palapeli). Yesterday on MacPorts, I uninstalled all dependents of qt4-mac, re-installed qt4-mac with the raster graphics variant and re-installed all KDE Games, KDevelop and a few other KDE packages. After clearing the cache files in KDevelop, all the black-on-black cases I know about had gone, i.e. in KBounce, KPat and KDevelop. However, unplayable slow performance in KBounce remained and so did failure of rubber-banding in Palapeli. When I added export QT_GRAPHICSSYSTEM=raster and re-ran, both problems disappeared. Similarly if I used the OS X command 'open <PathToApp> --args -graphicssystem raster'. Could this be due to the order of precedence referred to in http://qt-project.org/doc/qt-4.8/qapplication.html#setGraphicsSystem and internal swapping of graphics systems you mentioned in your previous comment, Thomas? OTOH and IIRC the animation code in KBounce was not the best when I looked at it last with a GSoC student in 2012 and the Palapeli code uses an exotic method of programming a rubber band --- see <QStyleOptionRubberBand> and paint() method at https://projects.kde.org/projects/kde/kdegames/palapeli/repository/revisions/master/entry/src/engine/interactors.cpp#L325 --- which I was thinking, a month or two ago, of replacing with plain old <QRubberBand>.
(In reply to comment #7) > Could this be due to the order of precedence referred to in > http://qt-project.org/doc/qt-4.8/qapplication.html#setGraphicsSystem and > internal swapping of graphics systems you mentioned in your previous > comment, Thomas? Yes, however i don't see setGraphicsSystem() in kdelibs or some *_mac.* file of Qt - and those would trump QT_GRAPHICSSYSTEM You could ensure this by qDebug() << bool(someWidget->paintEngine()->type() == QPaintEngine::Raster); I'd test whether env | grep QT_GRAPHICSSYSTEM or echo $QT_GRAPHICSSYSTEM says sth. *before* exporting it yourself (ie. it might be exported by /etc/profile or so, trumping the compiled in default) - afaics it's the only option if the environment has a word in it and the config switch was picked correctly (where I do unfortunately not know how to check that) > OTOH and IIRC the animation code in KBounce was not the best when I looked > at it last with a GSoC student in 2012 and the Palapeli code uses an exotic > method of programming a rubber band --- see <QStyleOptionRubberBand> > and paint() method at This is pretty much what QRubberBand does except that on WS_MAC, it creates an extra ARGB toplevel window for this purpose (no idea why - seems silly af first hand) The rubberband will however be slow/broken for the painting mode, you'd have to perform some painting that is esp. not XOR nor any Porter&Duff mode but SourceOver or Source. But if the native Mac graphicssystem is broken to such a degree, the sane solution seems to avoid it.
I'm confused on how to proceed regarding this bug. Is it in fact a KBounce bug or something that can be changed externally? Should I #ifdef WS_MAC then set the graphics system to raster? As I said, I'm confused. I don't know whether that would fix the problem.
The bug itself must be considered in Qt -> Quartz (OSX rendering) -> OSX driver The driver is broken (I assume that Quartz will do this in Hardware) and neither Quartz not Qt blacklist the HW for this paint mode. This will affect more than just kbounce (no more mac here) The solution (from our side) is to get Qt on OSX to use the raster graphicssystem. Since compiling Qt w/ raster as default (what should be the case anyway) doesn't work and since setting the env does work, this actually can only mean that QT_GRAPHICSSYSTEM is somewhere exported to "native" on Ian's box (before he overrides this) #ifdef WS_MAC QApplication::setGraphicsSystem("raster") #endif should do, but should imo not be done. 1. doesn't fix situation of other processes 2. secretly overrides QT_GRAPHICSSYSTEM for no actual reason (so if Apple/AMD/Whoever fixes the DestinationIn painting and whatnot and HW accelerated painting would turn superior ... before Qt5 ;-) ... the user could not easily re-activate it for kbounce) For now I suggest to wait for a comment from Ian about the QT_GRAPHICSSYSTEM state (ie., "why does Qt not use the compiled graphicssystem?")
(In reply to comment #9) > I'm confused on how to proceed regarding this bug. Is it in fact a KBounce > bug or something that can be changed externally? > No, Roney, I thought the black-on-black message was your bug when you first ported KBounce to QGraphicsView in GSoC 2012 days, but then I found it only happened on Apple OS X, not Linux. Eventually I remembered it when a similar-looking bug turned up recently in KDevelop on OS X, but KBounce is an easier application to investigate. So for now just relax and watch the show ... :-)
First some facts about my configuration. The CPU is 2GHz Intel i7, quad-core, and the graphics is Intel HD 3000 384 Mb. No mention of AMD anywhere, unless it is in some more souped-up graphics cards they sell with some Apple configs. Before Intel, Apple had PowerPC CPUs from IBM via Motorola and its successor Freescale (see 1 below). QT_GRAPHICSSYSTEM is not defined in my login environment, nor in my development environment. I did a bit of reading around and here are some interesting sources: 1. http://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_processors 2. http://www.zestymeta.com/2013/03/qt-and-peril-of-multi-platform.html (a blog) 3. http://blog.qt.digia.com/blog/2009/12/16/qt-graphics-and-performance-an-overview/ 4. https://bugreports.qt-project.org/browse/QTBUG-12615 (please read the comments) In short, raster graphics never did become the default for Qt 4.8 on Mac (2 and 4 above). The section on QGraphicsView near the end of 3 is interesting. Apparently it sets up a QPainter internally and keeps it for as long as needed. Then it can rapidly draw QPixmaps and geometrical figures as the items in the QGraphicsScene change and move around. Most KDE Games are based on QGraphicsView. I put some qDebug() lines in KBounce to see what graphics systems are in use at various places and times. Please refer to the screen shots I attached earlier. What you see is an Apple OS X main window and decorations surrounding a KDE central widget. That widget always has graphics system QPaintEngine::CoreGraphics 3 Mac OS X's Quartz2D (CoreGraphics) and so does the main window. It is an Apple OS X main window. The CoreGraphics system is used here regardless of whether you install raster in Qt, set it in code before creating the QApplication, set it in the command-line or export it in QT_GRAPHICSSYSTEM. QGraphicsView's scrolling widget (viewport()) also has an Apple OS X paint engine. At some point during its initialization QGraphicsView must set up its internal QPainter and paint engine, but seems to ignore or not be able to discover if Qt Mac has been installed with raster graphics. Subsequent QPainters *are* set up with raster (e.g. the QPainter used in KBounce's code to paint the translucent message-box correctly and the QPainters used in Plasma widgets, as in the KDevelop case), provided that Qt was installed with raster. One of my QDebug() lines shows this to be so. If I use one of the other three methods to specify raster graphics (all of higher precedence than installing Qt with raster), QGraphicsView sees that, honors it and uses raster graphics for its internal QPainter. So then the KBounce game runs at normal speed and the rubber-band in Palapeli is correctly drawn. This blog http://blog.qt.digia.com/blog/2011/02/23/alien-widgets-on-mac/ and its two videos might be relevant to why KBounce gets slowed down, but I still do not know for sure. Palapeli and KGoldrunner have always been fast and smooth enough on Apple OS X. What is the remedy for all this? All the KDE Games could be bullet-proofed against it by ORing Q_OS_MAC into the part of libkdegames that statically sets raster graphics before a game application begins (re https://svn.reviewboard.kde.org/r/6810/ I mentioned earlier). "Well, I'm all right, Jack", as they say in England, but what about the rest of KDE? Any ideas, Thomas? Could KDE just set raster graphics statically in all KDE apps that use KMainWindow or QMainWindow and forget about installing them in Qt?
Further to comment #12) > This blog http://blog.qt.digia.com/blog/2011/02/23/alien-widgets-on-mac/ and > its two videos might be relevant to why KBounce gets slowed down, but I > still do not know for sure. Palapeli and KGoldrunner have always been fast > and smooth enough on Apple OS X. > Results of further tests when Qt is installed with raster by MacPorts ... KBreakout is slowed down, just like KBounce. A debug patch showed that KGoldrunner is missing QTimer signals quite frequently (due to slow graphics). That was not easy to see before, because KGr makes up lost time by skipping the painting of some animation steps, keeping up full game-speed but making the animation look jerky. Both cases were fixed by using "-graphicssystem raster" on the command line.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Semi-transparent messages in KBounce work OK on Apple OSX now. I think we fixed this bug by a patch in the MacPorts builds of KDE apps and libraries some years ago. Those builds are still using KDE4 and Qt4, so the patch is irrelevant in KF5 and Qt5 and more recent releases of KBounce and other affected applications. We never did get Frameworks, Qt5 and KDE Applications playing nicely together on Apple OSX BTW, which is a real pity. So this bug does not apply to the latest releases of KDE Community software.