[cairo] integer world coordinate system

[Arjen Nienhuis]

On Wed, Aug 18, 2010 at 10:12 AM, M.R. <makrober at gmail.com> wrote:
> On 08/18/2010 03:35 PM, Chris Wilson wrote:
>>
>> On Wed, 18 Aug 2010 14:17:04 +0800, "M.R."<makrober at gmail.com>  wrote:
>>>
>>> We are evaluating options for graphics on a new project. Cairo is
>>> high on the list, with one potential problem:
>>>
>>> The application area 2-D "world-space" is in our application in
>>> "display surface scaled" integer coordinates...
>>
>> Right. You have to remember that you are not the first to wonder...
>
> Hi Chris;
> thank you very much for the quick response.
>
>> Numbers talk. Converting the interface isn't a major task, so if you feel
>> that it would be better to use integer-only for your code, please do try
>> and tell us what difference it made.
>
> Our application takes a multi-dimensional physical model of reality and
> "flattens" it into something that can be shown on a screen or printed
> page. We end up with large "poly-line" coordinate arrays. Memory
> is an issue.

If memory is an issue... Sending arrays with bilions of coordinates to
cairo will not give the desired performance i guess. Cairo is really
fast with large paths though. Paths with 10000s of points will work
great.

>
> Some lines are the result of a complex, expensive mathematical productions.
> If the application knows what pixel of the 2D graphical
> space a point on a multidimensional curve will end on, it can do the
> following ("Compute" in the following is something expensive"):
>
> Get line segment multidimensional end-points (A) and (B) from stack.
> Compute pixels [A] and [B] (corresponding to (A) and (B)).
> Compute pixel [M] of mid-pint between (A) nad (B).
> If the [M] is the same as mid-pixel of [A] and [B], connect
>   [A]-[M]-[B] with straight lines in display cordinate space.
> Else push (M) and (B) on stack and process (A) to (M) segment.

You can keep [A], [B] and [M] as float and check if abs([M] -
midpoint) < Epsilon with Epsilon the maximum error.

> This will yield a line that has used as few expensive computations
> as possible, yet be rendered with maximum granularity the display
> is capable of.

If you round [A] and [B] to integer, that it's not the 'maximum
granularity'. Because a display can handle grayscale a line
[0,0]-[10,0] is not the same as a line [0,0.1]-[10,0]. And for PDF or
PS output for printing it depends on the resolution of the printer.

> More examples could be given, but these two are in themselves enough
> for us to require that the application (and not the graphical platform)
> handles the "last step" in the coordinate pipeline between the
> multi-dimensional physical reality and the 2D display pixel.
>
> thanks again for your interest;
> Marko R.
>

Met vriendelijke groet,
Arjen