DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480 [PATCH] Experimental performance improvements. ------- Additional Comments From [EMAIL PROTECTED] 2004-01-10 01:07 ------- Finn, I'm now looking at the changes to PropertySets.java (already applied) and PropertyList.java (only partly so) and have a few questions: 1.) For the new PropertyList constructor (in the patch), you appear to be duplicating the element ID argument, once as "el", the other time as "elementId"--just to confirm, they are referring to the same thing (and hence one of them can be removed)? ---------------- 2.) In PropertySets.java (already applied), method makeSparseIndices, you define indices[0] as: indices[0] = (short) (set.cardinality() + 1); Later, in PropertyList, you initialize the values array as follows: this.values = new Property[indices[0]]; I think we can then just use set.cardinality() in makeSparseIndices(), correct? (i.e., leave out the +1). ------------------ 3.) PropertySets.java defines those properties which are valid for each FO--in PropertyList, the proposed implementation then uses that information to limit the properties that can be assigned to an FObj (i.e., only those defined as valid for it.) Am I correct here on this point? If so, we may need to expand the "valid" properties to include the inheritable ones. As Peter notes on the Alt-Design pages [1], in 5.1.4 of the Spec [2]: gives these two statements: "The inheritable properties can be placed on any formatting object." "Hence there is always a specified value defined for every inheritable property for every formatting object." [1] http://xml.apache.org/fop/design/alt.design/properties/introduction.html [2] http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#inheritance Do we need to expand then the property sets for each FO to include the inheritable properties (you may already have done so, I'm not sure if those were included)--and do we also need to somehow additionally qualify *those* properties as "valid for the FO but not directly relevant for it"? (I think "yes" for the first question, "no" for the second.) ------------------------------------ 4.) Finally, I'm too far removed from my C programming days to understand the math here: In the PropertyList constructor, you code this: this.specified = new int[(indices[0] >> 5) + 1]; (where indices[0] defines the number of properties valid for the FObj) Why the bitshifting 5 to the right? What does this accomplish--what is this shorthand for? also, in putSpecified(int idx, Property value), you code this: specified[i >> 5] |= 1 << (i & 31); I'm not clear what this is doing either. What does putSpecified() do, and what's the point of the i & 31 and the Or'ing? Sorry for the long post--feel free to move this to FOP-DEV if easier for you to respond. Thanks as always for your help! Glen
