Simon Montagu wrote:
>
> Steve Clark <[EMAIL PROTECTED]> wrote:
>
> >A) code size
> >Clearly, clients that are not interested in supporting Bi-Di should not
> >have to pay a significant penalty for the additional code required for
> >Bi-Di. The two ways we can think to minimize the impact are to factor
> >as much as possible into a separate library, or to leave significant
> >code chunks in #ifdef BIDI blocks. I'd like to urge people to think
> >about which code could reasonably be factored into it's own library,
> >since the support costs for #ifdef code is high.
>
> See my reply to Erik for some statistics.
>
> The most obvious candidate for a separate library is the Bidi
> utilities in intl\unicharutil. Currently these more than double the
> size of ucharuti.dll.
What are the old and new sizes of that DLL?
> If we move these into their own directory (say
> intl\bidiutil), that would probably also be a good place to put
> libraries for the remaining platform-specific code.
What do you mean by "remaining platform-specific code"? Do you mean
font-related stuff? That probably belongs under mozilla/gfx.
> Other than that, the greatest increase is of course in layout:
> gkhtml.dll grows by ~190K, over 10%. Here it would be much more
> difficult to factor out the Bidi code, since it is mostly made up of
> small changes scattered very widely through the tree.
However, there is a new file called nsBidiPresUtils.cpp, so you seem to
have factored out some of the code already. It doesn't surprise me that
a lot of the other changes are scattered widely throughout
mozilla/layout. Such is the nature of bidi. I guess ifdefs are fine for
those, for now. No?
Erik
