Since I upgraded from F17 to F18, all plots in X11 devices are completely blank. For example, plot(1:10) does not show anything except an empty window. Other devices (such as PNG) work as they should. This is with an Intel Ironlake Mobile GPU: VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller]) I don't really know where to start the debugging, so please advise.
Additional information: using X11.options(type="nbcairo") works around the problem (i.e. plots are drawn as expected); so does X11.options(type="Xlib"). The reported bug (plots not drawn) applies to both X11.options(type="cairo") (the default) and X11.options(type="dbcairo"). So the problem seems to be with buffering. Note that calling dev.flush() has no effect (it returns 0 anyway).
Arch Linux has a report which seems to be about the exact same problem: https://bugs.archlinux.org/task/32597 They noted that in addition to the remarks I made in comment #1, simply resizing the plot window makes the plot appear. So it looks like the buffer is not flushed correctly. This may well be a bug in Cairo since different GPU vendors are affected, and even building R 2.14 from source is said not to fix the bug.
Installing cairo-1.10.2-7.fc17 fixes the bug. But it's still present with cairo-1.12.4-1.fc18. I just filed a bug upstream at https://bugs.freedesktop.org/show_bug.cgi?id=59085
Reassigning to cairo.
Sorry, but according to Cairo developers, this is more likely an R bug. Still investigating ATM...
Okay. Back to R then. :)
Upstream R bug: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15168
I have only experienced this behavior on intel graphic cards. Nouveau works fine.
Very interesting information! I'm not sure this means that the bug is in Cairo or in the drivers, ruling out the possibility of it being an R bug, but I'll ask Cairo developers about this.
According to: https://bugs.archlinux.org/task/32597 it also occurs on ATI, so it's likely not a driver problem.
Indeed, I had somewhat skipped that detail. So maybe the proprietary NVidia driver forces drawing while others are not, so that's why they experience the problem...
We are not using the proprietary driver for NVidia as mentioned before.
Argh... Being wrong three times in a row. Not my day! But feel free to correct my mistakes directly upstream! ;-)
Created attachment 682993 [details] Patch applied upstream Upstream has committed a fix. It would probably make sense to apply it directly in Fedora instead of waiting for R 2.15.3, as this will appear as a major regressions (some users might not even discover that resizing the window is workaround). I'm attaching the patch, it should apply cleanly to R 2.15.2 as the files at stake have not been touched since then.
R-2.15.2-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/R-2.15.2-5.fc18
Package R-2.15.2-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing R-2.15.2-5.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1258/R-2.15.2-5.fc18 then log in and leave karma (feedback).
R-2.15.2-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 904257 has been marked as a duplicate of this bug. ***