On 2020/05/09 12:00:01, hanwenn wrote: > On 2020/05/09 11:03:12, dak wrote: > > Rationale? This negates work done as part of issue 5347 with the long-term > goal > > of making transforms a better integrated and accessible part of stencils. > This > > will be increasingly important when we move to Cairo since Cairo cannot > > represent rotations by multiples of 90 degrees cleanly other than by using an > > explicit transform matrix since (in defiance of all other graphical systems > like > > Postscript, PDF, METAPOST) it refuses to represent angles in any other form > than > > as radians (an actual patch implementing angles as degrees was proferred and > > rejected on what can hardly be called anything but philosophical grounds), and > > PI does not have an exact representation in those. > > Could you sketch how SCM-accessible Transform help with implementing Cairo > support?
I have not said that SCM-accessible transforms help with implementing Cairo support. The problem with Cairo is that it cannot properly represent rotations by multiple of 90 degrees (a common use case) except by using transform matrices, and so the in-stencil (and thus Scheme-accessible) support of transformations, currently mostly constrained to translations and rotations, would have to be moved over to whole transform matrices. > As you can see from the current state, it is not necessary to export them to > Scheme, and > I actually think the state from before https://codereview.appspot.com/344970043 > is preferable > to SCM encapsulation. With SCM encapsulation, we create GC overhead, and lose > the type checking that C++ gives us. That statement is not borne out by facts since a Simple_smob does not incur _any_ GC or Scheme overhead or loses any of the type checking of C++ unless you actually call smobbed_copy on it. Overhead occurs once you do significant manipulation with it using Scheme, and when doing so, there would be a reason for it offsetting the overhead. The Simple_smob base class itself contains no virtual functions and no non-static data members and thus comes without any runtime overhead until you actually use it from within Scheme. > It is extremely hard to deprecate or change APIs once they gain use in Scheme, > so everything being equal, the safe option is to not make them accessible IMO. They aren't available from Scheme as of yet. This is just done in preparation of changes that are sensible to make in future. And stencil expressions, albeit expressed in terms of Scheme data structures, don't really are manipulated to any significant degree from the user. Which is good since it would make a whole lot of sense to implement them in terms of, say, Cairo data structures in the long run. And the refactoring of the transform matrix and its use (at the current point in terms of a Pango transform matrix, but changing that detail would be comparatively trivial even though annoyingly the respective structures don't have the same internal layout) lends itself to that purpose very well in that regard. As I stated: performance cannot possibly be an issue before smobbed_copy () is even called since the memory layout and management and access is completely unchanged until one does. So undoing work that has been done for the sake of future extensibility would warrant an actually valid reason. In the long run, I'd be in preference of moving the SCM reflection of data types now represented by class derivation from Simple_smob (namely expressions without an SCM identity that sensibly can be eq?-compared and a straightforward storage layout) to a templated mechanism that allows confining the Scheme reflection to files actually concerned with it. As long as we are not there, however, I don't see the point in making life harder for those who would want to use transforms from the Scheme side. We have enough graphical entities represented by Scheme lists already, an appallingly expensive storage representation for material of fixed size. Having a way to represent transforms with a single SCM cell rather than 6 cons cells and 6 float cells can avert exactly the situation you are concerned with: too much use of SCM data management for the sake of getting a job done. https://codereview.appspot.com/567580043/