On Wed, Jun 19, 2019 at 11:05 PM Rene Rivera via SG13 <sg13_at_[hidden]>
wrote:

> On Wed, Jun 19, 2019 at 9:52 PM Michael McLaughlin via SG13 <
> sg13_at_[hidden]> wrote:
>
>> The inverse of the transformation matrix that transforms user space to
>> surface space (i.e. device space) can transform coordinate input to the
>> coordinate system the user (programmer) is working in.
>>
>> Depending on the scale of the transformation it's possible for the result
>> to be inaccurate to a degree that the result is inaccurate, but that can
>> easily be cured with a function that returns the input coordinates in
>> surface space, which uses should use if the scaling factor of their
>> transformation from user space to surface space is large enough.
>>
>
> It can only be cured, to an extent, when the spaces are equally
> dimensioned. I work in a field where I need to meld 1d, 2d and 3d input
> coming from varied sources with 1d, 2d, and 3d output. Hence I understand
> the challenges in making all that work without loosing precision+accuracy,
> and your sanity :-)
>

1d can be interpreted as being 2d, with the second dimension having no
meaningful value. 3d graphics ultimately resolve to 2d on all displays I'm
familiar with. That said, 2d graphics is only concerned with 2d graphical
output. 3d graphics is a steadily evolving field in terms of functionality.
2d graphics has been functionally stable no later than the introduction of
PostScript in the early 80s. Methods of implementing 2d graphics have
changed, but the basic functionality (paint, stroke, fill, mask, and text
rendering) have remained the same since then. Indeed, even text rendering
is one or more combinations of stroke, fill, and mask, such that there are
only four core functionalities involved.

-Mike