If the screensaver is already active without a lock, and it got a
request to lock, it would bail out without switching to a locked
state.

https://bugzilla.gnome.org/show_bug.cgi?id=668967

commit adfc2809 changed the drawing area associated with each
monitors screensaver window to get realized early.

That change is seemingly causing problems for users.

This commit stops preemptively realizing the drawing areas, and
instead makes the background color settings get applied reactively
in response to realization.

http://bugzilla.gnome.org/show_bug.cgi?id=679441

this avoid some build warnings

taken from:
https://git.gnome.org/browse/gnome-screensaver/commit/?id=214ab95
https://git.gnome.org/browse/gnome-screensaver/commit/?id=4f0124a

That won't work correctly with GTK3, even more so given that we set
app_paintable = TRUE on the drawing area.
Instead, set the background GdkRGBA to black directly
on the GtkDrawingArea's GdkWindow.

taken from:
https://git.gnome.org/browse/gnome-screensaver/commit/?id=43ee32e

This gets rid of some compile warnings

taken from:
https://git.gnome.org/browse/gnome-screensaver/commit/?id=73c0e41