bug#37755: Logic in init_fringe_bitmap should be moved to backends (maybe rif->define_fringe_bitmap)

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 20 Oct 2019 13:32:36 -0300
> Cc: 37755@debbugs.gnu.org
> 
> > If RIF is the problem, we could make each terminal backend do this
> > initialization unconditionally at dump time.
> 
> According to my rationale above, I don't see any problem at all. But,
> as I have said, I ignore everything about the dumper. Yet, I find it
> hard to believe that whatever this  dumper thing is, it needs the bits
> to be in little-endian, 8-bit per row format, or any other
> rif-specific pattern.

Sorry, we cannot just ignore the dumping issue.  We don't want to
waste CPU cycles each startup to regenerate these standard bitmaps.
So the fringe bit patterns need to be initialized at dump time and
dumped together with all the other stuff we prepare at that time.

If I understand correctly, the difficulty you had with doing this at
dump time was that frame's RIF was not yet set (because dumping works
in batch mode, where redisplay interface is not set to the correct GUI
frame type).  If so, my suggestion is to call the window-system
specific initialization function directly.  For example, in the X
build, you can add code to syms_of_xterm code to call
x_define_fringe_bitmap, and similarly for Cairo, w32, etc.

Does this proposal resolve the difficulty?  If not, please point out
what else is missing.

Thanks.