On 2020/05/09 16:19:59, hanwenn wrote: > On Sat, May 9, 2020 at 4:56 PM <mailto: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
Which actually is a pretty good use of it since passing around an SCM expression (and the stencil expression being passed in parallel also is an SCM expression) is cheaper than passing a whole transform matrix by value as done before. And there is only rather occasional change needed (necessitating the creation of a new object) since most stencil expressions do not change the current transform. > > > > 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? Stencil expressions during interpretation currently need to recreate transforms on the fly. It would be easier to just store them along with the expression. > This is currently dead code, and the normal treatment of dead code is > to delete it. Han-Wen, you don't accept long-term plans of other developers without proof of concept. And you throw out intermediate steps working towards that goal and declare them dead code. The right point of time for making objections to other people's contributions is when they were put up for review and discussed. You did not participate in those discussions. The next thing you are doing (when git blame clearly points to available information about the contributions, their time, their issues, their rationale and likely point of time) is deleting them without offering a rationale for that, indicating that you have no respect of previous decisions, previous discussions, and previous work. The last decade of LilyPond development has largely been marked by the goal to make much of LilyPond's internals workable and accessible to power users at the Scheme level. This has been a significant driver of LilyPond-based solutions and of an active and helpful user base. It has enabled significant contributions by community members that are not core C++ programmers. I don't see the point in reversing this course and locking access to LilyPond's internals to anybody but C++ programmers. Rewinding every effort in that direction throws away the potential of a quite larger community of contributors than the C++ programmers, and in this particular case the C++ programmers do not even get anything in return. https://codereview.appspot.com/567580043/
