Re: GtkCanvas requirements?



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.

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).

Havoc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]