Re: Stop smobifying Transform (issue 567580043 by address@hidden)

[Han-Wen Nienhuys]

On Sat, May 9, 2020 at 4:56 PM <address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen