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

Reply via email to