Re: [Pnet-developers] libCrayons

[Rich Baumann]

On Mon, 2005-11-21 at 10:28 +0100, Marc Haisenko wrote:
> I'll get tasked with helping to finish libCrayons, as you probably already 
> know. I don't know when I'll start (depends on my boss), but I estimate in 
> about three weeks or so.

OK.

> I just had a quick look at it, it looks quite impressive (I *love* code with 
> lots of comments :-)
> 
> So I have a few questions:
> 
> What are your design ideas, i.e. how should all the pieces come together ?
> What are the tasks that need to get done ?
> And how are you planning to integrate it with 
> System.Drawing/System.Windows.Form ?

        The way all the pieces should come together is, the classes in
System.Drawing should be light wrappers around their matching Crayons
objects. Graphics contexts are constructed by providing a surface;
currently, there is a bitmap surface which draws to a Crayons bitmap,
and an X11 surface which, for now, just uses XGetImage/XPutImage. Win32
and OS X surfaces are still TODO at the moment, though X11 surfaces
should work well enough for now on OS X.

        Internally, for now, all rendering is done using pixman images. The
pixman library is a client side version of the XRender server-side
fallback implementation. Eventually XRender will be used when available,
and the current X11 surface implementation will only be the fallback for
when it is not; some additional internal abstractions will need to be
added for this. When the bounds of a drawable change, the X11 surface
needs to be updated with the new bounds, and there are surface
locking/unlocking functions to maintain thread safety, though most of
the library's instance methods are not thread safe. The mutex code uses
pthreads if it's available, otherwise it does nothing, though it should
eventually support more options. X11 surfaces are designed to be created
for each visible control and should have the same lifetime as their
associated control.

        Metafiles are still totally unsupported. Currently, images can only be
created using the width/height/format and the
width/height/stride/format/scan0 constructors, just as found in
System.Drawing.Bitmap, so DotGNU.Images will continue to be needed for
all image loading and saving. All 16-bit and 32-bit non-indexed formats
are supported for bitmap creation as well as LockBits/UnlockBits. The
image data is stored internally in pixman images (32bppPArgb, native
endian) and the pixman data is converted to/from the standard
PixelFormat formats as needed, so all image operations should be
relatively cheap in the common case. In the case of LockBits/UnlockBits,
only the relevant portion of the image undergoes format conversion. Most
image functionality is still TODO (or half done and #if 0'd out), such
as support for multiple frames, encoders/decoders, etc., so
DotGNU.Images should continue to do most of the work and System.Drawing
images should just feed Crayons the image data so it can take care of
the data manipulation and rendering work.

        Text rendering support, which currently requires freetype and
fontconfig as hard dependencies, is not done yet. The font code is in
cvs and #if 0'd out, but the measuring/drawing end of it is not. As
usual, it's taking much longer than I thought it would.

        Aside from text rendering, the tasks which need to be completed are
testing, debugging, and pnetlib integration. Most of the integration
work should be pretty trivial as most of the Crayons functions map
directly to System.Drawing methods. When testing and debugging, you
should build the library with "CTESTING" defined, otherwise the internal
library functions will use the hidden visibility attribute, making it
impossible to call them from outside the library.

        I've tried rendering to an X11 window using an X11 surface and nothing
is drawn to the window, though I have yet to figure out why. This may be
a problem with the X11 surface code and/or a problem with the path
polygonization or polygon trapezoidation algorithms. I'm fairly certain
there's a bug in the X11 surface code as images also fail to render,
even though they don't go through the poly/trap code, though there could
be problems in both areas. It could also be that I simply screwed up the
test case.


Rich
-- 
Government is the great fiction through which everybody endeavors to
live at the expense of everybody else. -- Frédéric Bastiat
(http://bastiat.org/en/government.html)