On Sat, May 9, 2020 at 4:56 PM <d...@gnu.org> wrote: > > 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
Well, the change I we are discussing, you are actually calling smobbed_copy, for example in line 412 here: https://codereview.appspot.com/344970043/diff/60001/lily/stencil-integral.cc > > 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. I sitll don't understand. You want to have Transform as a smob in support of some future functionality. Can you explain what that functionality is, and how it would use a smobbed transform? This is currently dead code, and the normal treatment of dead code is to delete it. > 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/ -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen