[cairo] Working on degenerate matrix problem, some questions
Daniel Kraft
d at domob.eu
Mon Mar 24 10:22:57 PDT 2008
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
More information about the cairo
mailing list