Flash Bug (#410407)

This bug has been misidentified as a bug in Compiz, when in fact it’s a bug in Adobe’s Flash Player plug-in. It causes mouse clicks to not be handled by the Flash application. The bug is inconsistent – it’s an all or nothing thing. You’ll either get the bug on a video, or you won’t, and sometimes it can be coaxed into working by spamming clicks.

Eclipse Bug (#443004)

This bug has caused a lot of wasted time. Similar to the bug with Flash, clicking on a button with some dialogs will not register. It’s also inconsistent, which can be a real pain. Some dialogs in Eclipse can span many pages, such as the Export to JAR dialog.

Both of these bugs are related to a change that happened regarding GDK, the underlying method GTK-style applications use to draw things instead of calling X directly. I think the core problem is:

A small gotcha is that the GDK_WINDOW_XID() call is no longer a trivial accessor for the XID of the window, and thus must not be called from another thread without taking locking precautions.

This matches the inconsistency of the problems, since it’s a related to concurrency.

To combat the bug in Eclipse I’ve started using the repository version, since the SWT-related bug was fixed and they added support for user plugins.

The workaround for the Flash bug isn’t as nice, since Adobe is the master of making horrible “fixes.” For example, they pulled the rug out from underneath a lot of websites using Flash player to do the heavy lifting of uploading multiple files by requiring the file selection dialog to be initiated by a user interface interaction. Essentially you have to tell Flash not to enjoy the benefits of client-side windows by modifying /usr/lib/nspluginwrapper/i386/linux/npviewer to look something like this:

#!/bin/sh
TARGET_OS=linux
TARGET_ARCH=i386
GDK_NATIVE_WINDOWS=1
. /usr/lib/nspluginwrapper/noarch/npviewer

So that’s two features Adobe has nerfed in one configuration file (64-bit and client-side windows)

This is a misleading name because it does more than just monitor the scaling, it allows you to change it easily. Most people disregard these settings because many settings like this don’t make a huge difference in other applications. There is one place it makes a big difference, which is the mother of all CPU users: Web Flash-based video. This thing basically physically abuses your processor. You can use flash little performance tests to get an idea of how CPU scaling affects your hardware.

In the same way, I find that actually making use of the Powersave and other options when on battery. On desktop systems where power consumption isn’t an issue, this setting will always be set at Performance. While Ondemand is rather good for typical use, some users find that it degrades response-time for things like Compiz.

Also remember that IOWait is typically the bottleneck for a lot of applications. I chose to use Flash as an example because it does a poor job of accomplishing it’s job and as a result requires a magnitude of additional computational power. You can easily compare the amount of processor usage to anything like VLC, Totem, or Mplayer and they will be a fraction of the usage.