X Virtual Frame Buffer allows us to run GUI applications in a virtual screen that is not on the physical monitor. This is useful when we would like to have some automated tasks run on servers that are not connected to a particular monitor. The specific benefit for us is the ability to run capybara tests without having to have the browser window popping up all the time.
By default, xvfb-run creates a virtual screen of size 640x480 pixels at 8-bit color depth. This is in no way similar to real screens we see in computers in general.
Instead, running xvfb-run with extra parameters
xvfb-run -an 90 -s "-screen 0 1280x1024x24" #{insert command here}
allows us to create a virtual screen of size 1280x1024 with 24-bit color depth. In details,
-a means we want to find an available screen number automatically. By default the automatic screen finding starts at screen 99.
-n means we want to use screen number 90 or greater that is available.
-an 90 is beneficial when there are many tasks running that require a separate screen for each. Jenkins is the prime example.
-s "-screen 0 1280x1024x24" means that we want to pass custom parameters to the underlying xvfb server. In this case, "-screen 0 1280x1024x24" is passed on to xvfb server.
For xvfb server,
-screen 0 1280x1024x24
means that we want the first monitor of the screen to have a resolution of 1280x1024 with 24-bit color depth. Of course, there can be many monitors that the screen is displaying. We want the first monitor to be of this specification. For example, we may run the specs as
xvfb-run -an 90 -s "-screen 0 1280x1024x24" bundle exec rake parallel:spec
and expect that the screen is big enough for HTML elements to be visible on screen.
We don't want to type in all this long command all the time. What we can do is to insert the alias command onto .bashrc file:
alias xvfb-run-custom="xvfb-run -an 90 -s \"-screen 0 1280x1024x24\""
and restart terminal. From then on, we can run the specs as
xvfb-run-custom bundle exec rake parallels:spec
Refer to
for more information.