Re: GtkCanvas requirements?

[Damon Chaplin <damon karuna eclipse co uk>]

On Thu, 2007-04-19 at 16:19 -0400, Havoc Pennington wrote:
> Marco Pesenti Gritti wrote:
> > There is something which bothers me though. Support for some units, 
> > points for example, would require floating points measures. And I 
> > suspect we don't want to do layout in floating point (instability 
> > issues). Mozilla converts css units in twips (an arbitrary integer unit, 
> > 1/20 of a point). That's a way to go about it I guess, though it 
> > requires conversions it in the canvas items. Better ideas?
> > 
> 
> I agree that it would be really good to avoid floating point. Pixels are 
> by far the most intuitive thing for people using or writing items, too 
> (since as you say they avoid having to multiply everything). Pango does 
> have the precedent though and for convenience we could just use the same 
> units as Pango.

I don't really think that pixels or fixed point integers are enough for
a general purpose canvas. If people want to write complex layout apps
like DTP/illustration packages they need more precise control over
coordinates (and in different units like points/millimeters/inches).

e.g. the SVG spec says high quality viewers should use doubles for
calculations:
  http://www.w3.org/TR/SVG11/types.html#BasicDataTypes


> Maybe there's some way to make this optional, for example items that 
> feel they can do something useful with sub-pixel sizes could implement 
> an interface that did the size negotiation in sub-pixels. The default 
> implementation of the sub-pixel size negotiation methods would call the 
> whole pixels one, and the default implementation of the whole-pixels 
> methods would call the sub-pixels one and round off. If you didn't 
> override either one it would break badly, but don't do that then ;-)
> all items would have to implement one or the other but not both.
> 
> One downside of doubles is simply the extra memory usage when storing 
> coordinates; I think keeping the abstract base class for items and most 
> common concrete classes as small as possible is a nice win. I'd like to 
> see items be "lighter" than GtkWidget, in almost any of the usage 
> scenarios (widget core or drawing api or other).

In these days of 64-bit machines I don't think sizeof (double) is a big
deal, if its just for a few coordinates per item. Anyway if we're using
interfaces for items then the items can use whatever they like
internally.

Damon