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

Previous Next

Full log

Message #37 received at 37755 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 37755 <at> debbugs.gnu.org
Subject: Re: bug#37755: Logic in init_fringe_bitmap should be moved to
 backends (maybe rif->define_fringe_bitmap)
Date: Sat, 26 Oct 2019 13:39:27 +0300

> From: Carlos Pita <carlosjosepita <at> gmail.com>
> Date: Sun, 20 Oct 2019 13:32:36 -0300
> Cc: 37755 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.