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

[dak]

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/