This is trivial in the Wayland backend; just instantiate a pixman
pointing to the same mmapped memory as the wayland buffer.
In the XCB backend, we change the implementation slightly; instead of
rendering via a cairo XCB surface backend (to a server side pixmap),
which is then blitted to the window in commit(), we now render to a
client-side pixman pixmap, and blit it using xcb_put_image() in
commit().
All decoration, particle and module interfaces now takes a
pixman_image_t parameter, and all drawing is done using pixman APIs.
The wayland/xcb backends implement a new interface functions,
get_pixman_image(), that should return a pixman image instance that is
suitable for rendering.
In the wayland backend, the image uses the same backing data as the
cairo surface.
In the XCB backend, we create a new image each time, and then blit it
to the cairo surface at commit time.
We do it differently from everybody else...
A traditional HiDPI implementation typically scales up
everything. I.e. if the user wants a 1px border, it's scaled up to
2px. The wayland server typically presents an output width/height that
has been scaled *down*.
This is all a bit backwards, but perhaps was the best choice to make
legacy applications at least work.
f00bar on the other hand, wants to give the user absolute
control. Thus, we don't scale up at all. If the user wants a 25px bar
height, that's what he gets.
This does mean however, that we need to scale *down* the surface size
since it's in logical pixels, not physical.
So we scale *down* the surface size (which then gets scaled back up by
the wayland server), and then render everything *on* that surface
without any scaling.
Bar is drawn, though only TOP is supported atm. No
screen/display/output selection is possible yet. Mouse *click* works,
but not setting the cursor.
Lots of debug output, crappy code yada yada.
