Simon Montagu wrote:
>
> [EMAIL PROTECTED] (Erik van der Poel) wrote:
>
> >> 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?
>
> 16.5K and 35K
I guess that's large enough to be it's own 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.
>
> No, I was thinking of the #ifdef PLATFORM code that the reviewers
> objected to in XP modules, for example in nsPresShell.cpp. The example
> there is a case where we have to identify the specific Windows
> platform at runtime and perform different text conversions depending
> on the platform, because of differences in the way they treat Arabic
> characters.
In general, the platform-specific clipboard code is under
mozilla/widget/src. For example, windows/nsClipboard.cpp. Is there any
way that you could do the conversion there?
What other examples of platform-specific code are there in the XP code?
> >> 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?
>
> I agree with you here, especially since any factoring out into
> nsBidiPresUtils.cpp is only on the level of the source files -- I
> don't think the methods there could sensibly go in their own library
> independent of the layout module.
Would it be difficult to put that file into a separate DLL?
Erik
