[cairo] 16-bit precision issues in cairo
otaylor at redhat.com
Fri Aug 12 06:33:05 PDT 2005
On Thu, 2005-08-11 at 21:32 -0700, Carl Worth wrote:
> Uhm... at that point you are creating a surface with dimensions of
> about (take your pick):
> 100000x100000 points
> 1389x1389 inches
> 115x115 feet
> 35x35 meters
> Is that actually useful for any practical purpose? I can imagine
> posters for covering tall office buildings, but somehow I don't think
> that such posters would want the kind of geometric accuracy that cairo
> provides at this scale. (Bézier splines accurate to within 0.1 points
> on a 100000-point poster?)
Pick a random book on Project Gutenberg, bring it up as a single HTML
file in your web browser. This is equivalent to cutting all the pages
in the book apart and arranging them into a single scroll... 115 feet
isn't ridiculous for that.
Now, scroll to the middle and try to clear the background of that
web-page using cairo_rectangle(), cairo_fill().
Assuming that the web browser is double-buffering, it doesn't actually
render it to the window, but to a reasonable size pixmap, but reasonable
app code will try to draw a rectangle with bounds something like:
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
(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.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050812/462f1f6c/attachment.pgp
More information about the cairo