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

[Carlos Pita <carlosjosepita@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]

>
>
>
> > Ok, I'm not sure about how dumping works, but the patterns that you
> store are backend specific. Does the
> > dumper take that into account?
>
> The pdump file, like the Emacs binary, is architecture-specific.  So
> yes, this is inherently taken into account.
>

I kept thinking about this and there is also the fact that is not only the
architecture (I mean x, w32, ns, endianness) that is assumed in that bit
shuffling but also, for example, if we have cairo or pure xlib backend, and
that's because I'm quite sure that code was written with the input format
assumed by the rif (even if the rif still doesn't exist at that point) in
mind. Again, I don't know about the dumper but my intuition says there is
something potentially wrong in this arrangement.

What I proposed is:

1. Static initialization of fringe rif/platform-independent structures,
that I guess will be dumped.

2. Prepare. Per-rif initialization of the rif/platform-dependent
structures. This shouldn't affect the independent structures, although in
some cases the original bit pattern is still destructively changed because
it was simpler to keep the existing implementation.

3. Draw. Rendering of the rif/platform-dependent structures to the screen.

What you argue for is:

1. Idem.

1'. Init. Initialization of the platform-dependent but rif->independent
structures.

2'. Prepare. Initialization of the rif/platform-dependent structures from
the platform-dependent but rif->independent structures.

3. Idem.

Now 1' is just cheap bit shuffling of some twenty or so standard bitmaps
having an average grid of 8x8 bits. Also there are might be bugs if output
patterns are not rif specific and the dumper is unaware of that (again I
can't say for sure because of my lack of knowledge of the dumper).

Moreover, having 1' and 2' merged in 2 may actually speed things up,
because there is no need for two separate iterations over the bitmaps, the
first one producing the bit pattern for the second one. It's natural to
simply iterate over the original pattern and directly produce the input
expected by the particular rendering backend.

So, having exposed my reasoning as detailed as I could, and once again, are
you sure that you want to keep that phase 1' just to save some milli
(micro?) seconds, if any? There is a price in code complexity and the risk
of coupling fringe.c too much with backend specific logic. Also, suppose
that there is a problem with this cairo vs xlib decision hardcoded there,
before the dumping happens. One option is to move that xlib vs cairo
decision to the rif (that is to 2 or 2' above). And this way you will be
converging to an empty 1' and 2'->2.

[-- Attachment #2: Type: text/html, Size: 4031 bytes --]