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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list