0

Fix C extension build warnings

Today in "why did we ever do this?", we discover we've vendored
code from PIL/Pillow, but PIL/Pillow moved some macro definitions
around, so now our vendored code conflicted with their macros that
they included in the headers we're including.

The solution is to throw out our vendored macros and update the
semantics in our vendored Draw.c. I'm not sure why we vendored it,
but we seemingly did remove some stuff from it to avoid having to
pull in all of PIL/Pillow.
This commit is contained in:
Nicolas F
2019-02-21 16:22:22 +01:00
parent a05daa7519
commit 03a8697866
2 changed files with 9 additions and 21 deletions

View File

@@ -64,13 +64,6 @@
#define INK8(ink) (*(UINT8*)ink)
#define INK32(ink) (*(INT32*)ink)
/* like (a * b + 127) / 255), but much faster on most platforms */
#define MULDIV255(a, b, tmp)\
(tmp = (a) * (b) + 128, ((((tmp) >> 8) + (tmp)) >> 8))
#define BLEND(mask, in1, in2, tmp1, tmp2)\
(MULDIV255(in1, 255 - mask, tmp1) + MULDIV255(in2, mask, tmp2))
/* -------------------------------------------------------------------- */
/* Primitives */
/* -------------------------------------------------------------------- */
@@ -100,14 +93,14 @@ point32(Imaging im, int x, int y, int ink)
static inline void
point32rgba(Imaging im, int x, int y, int ink)
{
unsigned int tmp1, tmp2;
unsigned int tmp1;
if (x >= 0 && x < im->xsize && y >= 0 && y < im->ysize) {
UINT8* out = (UINT8*) im->image[y]+x*4;
UINT8* in = (UINT8*) &ink;
out[0] = BLEND(in[3], out[0], in[0], tmp1, tmp2);
out[1] = BLEND(in[3], out[1], in[1], tmp1, tmp2);
out[2] = BLEND(in[3], out[2], in[2], tmp1, tmp2);
out[0] = BLEND(in[3], out[0], in[0], tmp1);
out[1] = BLEND(in[3], out[1], in[1], tmp1);
out[2] = BLEND(in[3], out[2], in[2], tmp1);
}
}
@@ -159,7 +152,7 @@ static inline void
hline32rgba(Imaging im, int x0, int y0, int x1, int ink)
{
int tmp;
unsigned int tmp1, tmp2;
unsigned int tmp1;
if (y0 >= 0 && y0 < im->ysize) {
if (x0 > x1)
@@ -176,9 +169,9 @@ hline32rgba(Imaging im, int x0, int y0, int x1, int ink)
UINT8* out = (UINT8*) im->image[y0]+x0*4;
UINT8* in = (UINT8*) &ink;
while (x0 <= x1) {
out[0] = BLEND(in[3], out[0], in[0], tmp1, tmp2);
out[1] = BLEND(in[3], out[1], in[1], tmp1, tmp2);
out[2] = BLEND(in[3], out[2], in[2], tmp1, tmp2);
out[0] = BLEND(in[3], out[0], in[0], tmp1);
out[1] = BLEND(in[3], out[1], in[1], tmp1);
out[2] = BLEND(in[3], out[2], in[2], tmp1);
x0++; out += 4;
}
}

View File

@@ -33,7 +33,7 @@
// increment this value if you've made a change to the c extesion
// and want to force users to rebuild
#define OVERVIEWER_EXTENSION_VERSION 54
#define OVERVIEWER_EXTENSION_VERSION 55
/* Python PIL, and numpy headers */
#include <Python.h>
@@ -42,11 +42,6 @@
/* Fix Pillow on mingw-w64 which includes windows.h in Imaging.h */
#undef TRANSPARENT
/* like (a * b + 127) / 255), but much faster on most platforms
from PIL's _imaging.c */
#define MULDIV255(a, b, tmp) \
(tmp = (a) * (b) + 128, ((((tmp) >> 8) + (tmp)) >> 8))
/* macro for getting a value out of various numpy arrays the 3D arrays have
interesting, swizzled coordinates because minecraft (anvil) stores blocks
in y/z/x order for 3D, z/x order for 2D */