[cairo] Working on degenerate matrix problem, some questions

[Daniel Kraft]

Hi,

thanks for the further input regarding the "degenerate matrix" thing in 
cairo.  Today I started real working on it, and begun by creating a new 
cairo_transform_t type which encapsulates a transformation together with 
its inverse if it exists.

Currently, I replaced ctm/ctm_inverse in cairo_gstate_t with one single 
cairo_transform_t member and tried to change cairo-gstate.c accordingly, 
moving the transforming functions (like _cairo_gstate_scale) into the 
cairo-transform.c domain.

At the current state, the code should work (to my understanding) the 
same as it did before (at least roughly), and the only failures I get in 
the "transforms" test are the xlib-fallback-rgb24 ones which I simply 
suspect to be failing anyways; but of course I can't tell...  My current 
diff is attached.  The next step will be to actually use the new 
transform->has_inverse feature to allow some actions even with 
degenerate matrices, like painting as the problem statement suggests.

This were the first few hours I worked on the cairo codebase, so I'd be 
happy if you could answer me some questions:

* The patch is far from complete and has a lot of parts marked with XXX; 
but I'd like to know if it looks good on the whole, that is, if my way 
of touching the codebase is ok in general or if there's something I 
should do another way.  BTW, how should I communicate patches like this 
to you?  Is it ok like this, should I append the diff directly to the 
mail text, use something other than the mailing list...?

* At some points I am currently ignoring a cairo_status_t return value; 
that is, in functions already present with a void return type.  How can 
I set the error flag if an error occurs there without having to return 
the error code?  What should I do there?  (For instance, the gstate 
device-to-user transformations, IIRC)

* There are a lot of use-cases in cairo-gstate.c that want the 
ctm/ctm_inverse matrices; there, I currently simply accessed those in 
the cairo_transform_t, as my current understanding of what's going on 
there is too bad to do any serious changes...  Is it ok as I did it, or 
is there mostly functionality that should be encapsulated into 
caito_transform_t anyway?  And related, the font-transformation-matrix 
in gstate is currently not touched in any way, could this be a 
cairo_transform_t, too?

* And last but not least, are there any other places besides 
cairo-gstate.c that should make use of cairo_transform_t, or is gstate 
indeed the central piece of code dealing with the transformations? 
IIRC, I just did a grep to find a place where transformation matrices 
are used.

Thanks,
Daniel

-- 
Done:     Bar-Sam-Val-Wiz, Dwa-Elf-Hum-Orc, Cha-Law, Fem-Mal
Underway: Ran-Gno-Neu-Fem
To go:    Arc-Cav-Hea-Kni-Mon-Pri-Rog-Tou
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
Url: http://lists.cairographics.org/archives/cairo/attachments/20080324/579fc5cb/attachment-0001.txt