Re: GtkLayout and Pango

[Peter Lund <firefly vax64 dk>]

On Thu, 2006-11-02 at 20:58 +0100, Sham Gardner wrote:


> I'm writing an application that uses a GtkLayout as a large horizontally 
> scrollable area and uses Pango to plot short pieces of text at regular 
> intervals within that area. Other drawing primitives are also used at 
> similar intervals.
>
> I have observed that while the drawing primitives I use work fine with 
> 32 bit coordinates, Pango inexplicable fails to plot anything beyond an 
> X coordinate of 2^21 (2097152) (Y coordinates may be similarly affected, 
> but my application does not use large Y coordinates).


It is not all that inexplicable.  Pango needs to use values less than
one pixel's worth and floating-point is slow on some platforms and can
easily lead to rounding errors.  Therefore, Pango uses fixed-point
internally.

I found this in the Pango Reference Manual (I use devhelp as my viewer):


PANGO_SCALE

#define PANGO_SCALE 1024

The PANGO_SCALE macro represents the scale between dimensions used for
Pango distances and device units. (The definition of device units is
dependent on the output device; it will typically be pixels for a
screen, and points for a printer.) PANGO_SCALE is currently 1024, but
this may be changed in the future.

When setting font sizes, device units are always considered to be points
(as in "12 point font"), rather than pixels. 



________________________________________________________________________

PANGO_PIXELS()

#define PANGO_PIXELS(d) (((int)(d) + 512) >> 10)


Converts a dimension to device units.

d :
a dimension in Pango units.

(The addition of 512 is for rounding.)

As 1024 is 2^10, that fits nicely with your observation.


>  Is this a known 
> issue and is there any way around the problem short of resorting to an 
> intermediate Pixmap object?

The more scalable solution would be to handle the scrolling yourself but
that can end up being harder than it should be.
Also, if you blithely draw to the whole scrolled area, you might end up
with very slow code because so much work goes into drawing something
that isn't visible anyway.

See also:
http://lists.freedesktop.org/archives/cairo/2006-May/006993.html

Best of luck :)

-Peter