Ok, I found the bug. The init part was in general iterating along bits
by advancing the pointer (i.e. bits++). When I juxtaposed this part to
the define part, that also used bits, then bits was pointing to one
past the end of the bitmap and not to the bitmap itself, as expected
by the define code. Once diagnosed, it was an easy fix. In detail:

1. For Cairo, I followed my own suggestion above of not modifying bits
at all. Both the previous init and define loops are now merged into a
single loop that directly writes to the surface data, instead of
modifying bits.
2. For X11, bits is the only state propagated between init/define and
draw and there was no specific define part before my changes, so the
new define is simply the old init. Here bits is obviously modified in
order to prepare it for the drawing routine.
3. For Win32, I replaced bits++ with bits[i]. Bits is also modified,
although here it's easy to avoid that if so desired because it's only
locally needed to initialize the platform-specific bitmap structure
then used by the drawing routine.
4. For MacOS/NS, there is nothing to be done since there was no
specific init part, as I observed a few posts above.

I've cursorily tested this patch both alone and merged with my "hidpi
fringe" patches and seems to be working fine for the Cairo backend.

The new change amounts to yet another code simplification and an
overall ~40 reduction in LOCs.

Best regards
--
Carlos