[cairo] 16-bit precision issues in cairo

[Russell Shaw]

Owen Taylor wrote:
> On Thu, 2005-08-11 at 21:32 -0700, Carl Worth wrote:

...

> Generally, *rendering* to areas outside the 16-bit coordinate space is
> is uninteresting. But rendering *primitives* larger than 16-bits
> is quite natural and normal.
> 
> We've seen quite a few reports of problems with GTK+ which has the
> limitations of X for rendering primitives larger than 16-bits. 
> People create gigantic windows for scrolling, then try to draw
> lines or rectangles across the entire window.
> 
> This doesn't seem that easy to fix in Cairo - by the time we get to a
> point where it is easy to clamp, we are already in 16.16 coordinates. 
> But it's something worth keeping in mind. If we were willing to waste
> code space, we could imagine having a separate 48.16 path 
> implementation and rasterizer that we fell back to when we encountered
> out-of-bounds points.
> 
> (16.16 is really somewhat of a questionable split - do you really need
> 1/65536'th of a device unit? Pango uses 20.12, Windows, 24.8. 
> Not that I'm suggesting changing cairo at this point.)

In making a few cad programs, i've found the best way that minimizes memory
and maximizes drawing speed is had by not drawing everything in the whole
document when the portal (viewable area) is a zoomed in tiny portion of the
document. The users program or graphic library should be smart enough to
omit drawing primitives outside the viewable area before xlib even gets to
see anything. If users render things exceeding 16 bits, it's their own fault.