[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Cairo Port
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Tue, 08 May 2007 10:14:33 +0100
- Subject: Re: [XaraXtreme-dev] Cairo Port
There appears to be a goofy allocation scheme whereby GDraw doesn't
provide an allocation function, but instead just provides a
GDraw_ContextLength function and the layer above performs
allocation. I'm not sure what the precise semantics of that function
are, (is it just sizeof(private_struct) ? or does it also include a
dynamic component based on the size of the image buffer?).
It is a fixed length thing. The goofy allocation scheme is (I think)
because the assembler version doesn't / didn't once upon a time
link against the same C library that did memory allocations.
Also, the code above must certainly be able to get at the image buffer
contents somehow in order to be able to actually display them. But I'm
not sure how that happens.
The image buffer is allocated (and, I believe, blanked) in the application.
For extra bonus confusion value the bitmap bit itself needs to be in
windows DIB format. Given that it's (almost) exclusively used in 32 bit
mode these days, this is simply one 32-bit word per pixel, and row
alignment etc. aren't a problem, so we are merely talking byte ordering and
"where T goes" considerations.