X11Libre
treewide: drop ifdef's for GLYPHPADBYTES != 4
It's always defined to 4, for over a decade now, so no extra case checks needed anymore.
See: 17c3347f14822b9f7da4253c71f6ed51be2b38d1 Signed-off-by: Enrico Weigelt, metux IT consult [email protected]
Apparently the value was supposed to be chosen as the most suitable for a given architecture. But then someone decided (in fb.h) that it can only be 4. I wonder why? And wouldn’t it be good to make it 8 for modern 64-bit architectures?
Apparently the value was supposed to be chosen as the most suitable for a given architecture. But then someone decided (in fb.h) that it can only be 4. I wonder why? And wouldn’t it be good to make it 8 for modern 64-bit architectures?
IMHO this was about alignment issues on strange acient CPU architectures that really can't cope with unaligned memory access.
Apparently the value was supposed to be chosen as the most suitable for a given architecture. But then someone decided (in fb.h) that it can only be 4. I wonder why? And wouldn’t it be good to make it 8 for modern 64-bit architectures?
IMHO this was about alignment issues on strange acient CPU architectures that really can't cope with unaligned memory access.
Alignment is still very important nowadays. On arm, unaligned access leads either to crashes or a very high performance penalty. On x86, unaligned access works, but is slower than aligned access.
Alignment is still very important nowadays. On arm, unaligned access leads either to crashes or a very high performance penalty. On x86, unaligned access works, but is slower than aligned access.
It seems to be always be set to 4, so I'd guess it's not a practical issue anymore.