"m...@apollinemike.com" <m...@apollinemike.com> writes: > On Feb 10, 2012, at 1:51 PM, David Kastrup wrote: > >> David Kastrup <d...@gnu.org> writes: >> >>> David Kastrup <d...@gnu.org> writes: >>> >>>> Han-Wen Nienhuys <hanw...@gmail.com> writes: >>>> >>>>> Just a very quick look: I notice you're creating affine transform >>>>> matrices in Scheme. IMO, this seems an excellent candidate to >>>>> implement in C++ and expose through bindings, as the C++ matrices will >>>>> be better packed in memory, and should probably only be manipulated by >>>>> operations involving multiple floating point ops (add, multiply, etc.) >>>> >>>> Stupid question: wasn't Cairo a dependency of LilyPond? It should >>>> offer affine transforms as a builtin entity anyway, and it is >>>> conceivable that using those will play together smoothly with other >>>> rendering operations. >>> >>> Cancel that: I was confusing this with Pango. >> >> Well, uncancel the idea in itself: seems like it applies to Pango as >> well: > > I've implemented all of the affine transformations in > stencil-integral.cc. They're pretty simple, but they work and are > fast.
No disrespect intended, but if we do our text stencilling in Pango anyway, it seems like we don't buy us any advantages by maintaining our own code for transformations, possibly needing to convert them into the Pango form when passing them on. I immediately agree that it is a nuisance to first do the work of coding this, then do the work of replacing it again, then check that the replacement also works. It would have been nicer if I had thought of this earlier. But things like using SSE instruction sets for transforms have a place in Pango (where it is a fundamental operation) but would not be a reasonable fit of code complexity in LilyPond. It may be a naive assumption without looking at the respective code, but I would at least hope that we can rely on the Pango stuff being in reasonable shape, and if it isn't, have people care about bug reports without needing to invest too much work of our own. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
