Re: General performance [was: drawing performance]


Subject: Re: General performance [was: drawing performance]
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Mon Dec 18 2000 - 13:57:09 CST


ms> I can see we can make some real efficiency gains by going to
ms> enumerated constants. I think this would also be easier to
ms> maintain because all defined attributes/properties would have to
ms> be listed in an obvious header file.

Well, they are already listed in two obvious header files (at least
it's obvious after you search around for a while :-). I think there
are two problems (aside from the performance question) with the
current scheme...

First, the symbols which actually appear in the two header files are
not the same as the symbols used for the property names elsewhere in
the code. It's understandable how the macros were done, but it's
inconvenient for a developer to check that s/he's using the right
symbol. You can't, for example, put your emacs cursor on it and ask
"cscope" to find the place where it's defined. So, I hope any new
scheme that uses enums or whatever will solve this annoyance as a side
effect.

Second, somewhere lost in the mists of time someone decided there
should be cross-app properties and per-app properties (hence the two
header files). That's a fine first cut, but I don't think it's really
the right model. In the first place, it is sometimes conceptually
difficult to tell into which pile a new property should be placed. In
the second place, I think of (most of) the properties the same way I
think of formatting attributes. I think of cross-app defaults,
subject to per-app overrides, subject to per-document overrides,
subject to overrides within a document to a fine degree of
granularity. If I want to mark off a chunk of a document to avoid
spell-checking it, why shouldn't I be able to?

(I recognize that this last idea possibly works against those who are
attacking the current properties performance issues. Sorry about
that.)

-- 
bill@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3



This archive was generated by hypermail 2b25 : Mon Dec 18 2000 - 13:56:45 CST