> 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.