From bf99e355d9d24a4820dc93b49321b15318501b61 Mon Sep 17 00:00:00 2001 From: Carl Worth Date: Thu, 28 Feb 2008 15:45:11 -0800 Subject: Clarify that 16-bit limit still exists in pixman --- NEWS | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) (limited to 'NEWS') diff --git a/NEWS b/NEWS index b23e5309..47583add 100644 --- a/NEWS +++ b/NEWS @@ -23,21 +23,22 @@ that extends beyond the surface bounds and expect it to fill the surface completely, (rather than overflowing and triggering random behavior). -Meanwhile, nobody has ever really needed 16 bits of sub-pixel precision. +Meanwhile, nobody has ever really needed 16 bits of sub-pixel +precision. With this snapshot, the fixed-point system is still in place and is still using a 32-bit representation, (future versions of cairo might move entirely to floating-point when targeting PDF output for example). But the representation now provides 24 bits of pixel -addressing and only 8 bits of sub-pixel positioning. It is hoped that -this larger space is adequate to avoid pain for many application -developers. - -Note that the 24-bit limitation is only on the range of the allowable -device space. It is still legitimate to arrange a transformation -matrix that provides an arbitrarily large user-space, (the space in -which floating-point values are provided to cairo), as long as the -post-transformed values fit within the 24.8 representation. +addressing and only 8 bits of sub-pixel positioning. This should give +a much less stifling space to many applications. + +However, the underlying pixman library still has 16-bit limitations in +many places, (it has its roots in the X server as well). Until those +are also fixed, applications targeting cairo image surfaces, or +hitting software fallbacks when targeting other surfaces will still +encounter problems with device-space values needing more than 16 +integer bits. generic fixes ------------- -- cgit v1.2.3