Re: [Pnet-developers] Module for libSystemDrawing

[Rich Baumann]

On Mon, 2005-10-17 at 19:23 +0530, Gopal V wrote:
> How about libCrayons ?

Gopal said he'd do the renaming of the functions/macros/types, so I
changed the name as he requested. Anyone who wants to have a laugh at my
expense can now checkout "dotgnu-pnet/libCrayons". The autoconf/automake
files don't even work, yet.

If you want to build it now, this works for me (yes, you need libpixman,
as I'm not about to reinvent that wheel):

touch include/CrayonConfig.h
cd src
gcc -o libSystemDrawing.so -shared -Wno-long-long -DSDTESTING -DSDDEBUG
-DHAVE_PIXMAN_H -DHAVE_X11_XLIB_H -DHAVE_PTHREAD_H -DHAVE_STRING_H
-DHAVE_STDLIB_H -DHAVE_ASSERT_H -DHAVE_MEMORY_H -DHAVE_MEMSET
-DHAVE_MEMCMP -DHAVE_MEMCPY -DHAVE_MEMMOVE -DHAVE_MATH_H -DSIZEOF_LONG=4
-DSIZEOF_LONG_LONG=8 -Wall -g -pedantic -L/usr/X11R6/lib -lm -lpixman
-lX11 -std=c89 -I. -I.. -I../include CAffineTransform.c CB*.c CC*.c
CF*.c CG*.c CH*.c CI*.c CLineBrush.c CM*.c CPa*.c CPe*.c CPo*.c CR*.c
CS*.c CT*.c CU*.c CX11Surface.c
su
cp libSystemDrawing.so /usr/lib
cp ../include/CrayonConfig.h ../include/Crayon.h /usr/include


For those of you who wish to dig into the code:

The X11 surfaces don't draw to the screen, and I have yet to figure out
why. Currently the XGetImage/XPutImage fallback is all that's used atm,
as I think the fallback should be made to work before adding render
support. Also, it'll take a bit of extra work to make patterns and masks
more generic, as they're currently hard-wired for using pixman images,
and I'd like to get the fallbacks working correctly before adding
extras.

Text support is not done yet, so it's still in skunkworks; freetype and
fontconfig will be hard dependencies (even on windows, where font
support is not 64-bit safe, at least if you want reentrancy) once it's
in, and "graceful degradation" won't be coming any time soon. The bulk
of the FT/FC code is already in cvs, but is #if 0'd out atm. Region
rasterization (for clip masking) seems to produce the wrong results,
though path trapezoidation has been tested and works correctly afaict,
so I don't think it's that. Win32 surfaces are on hold as they're low
priority, and I'd like to at least get the X11 surfaces working first.

Images are a bit hackish atm, because doing them right requires some
more in depth probing of gdi+ behavior, so SDBitmap_Create and
SDBitmap_CreateData are the only ways to create images for now. Some of
the right behavior has been #if 0'd out, because it's of no use without
other functionality. DotGNU.Images can do the work of opening images and
then just feed SDBitmap_CreateData the default frame data for those
images, so I consider it relatively low priority for now.

I still haven't cannibalized the GDI+ wrapper I wrote back in Jan/Feb,
so there's no C# wrapper for any of this atm. Considering that all the
function names are going to change, given the name change to libCrayon,
I guess that's a good thing. A wrapper also wouldn't be of much use atm
given that a lot more work needs to be done before this will work as a
decent replacement for the System.Drawing backends.

Everything is commented to the point of absurdity, as per my usual
coding style, so I'd appreciate it if new code and modifications would
follow that pattern. Also, all publicly exposed enumerations are
typedef'd unsigned 32-bit integers, with #defines for their members, so
they have a predictable size on all platforms; any new public
enumerations should follow this pattern, though internal enumerations
can use the C "enum" type. Thanks.

Oh, and if anyone wants to go through the code adding const to function
parameters, where appropriate (I've only added after the fact, where
it's shut the compiler up), feel free to do so, but please strictly
follow the whitespace pattern for functions as used throughout the
library; consistency aids readability.


Rich