[fpc-devel] Unicode resource strings

[Mattias Gaertner]

On Tue, 21 Aug 2012 10:24:38 +0100
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> On 21 August 2012 10:01, Mattias Gaertner <nc-gaertnma at netcologne.de> wrote:
> >> > The conversion is done only when entering and exiting the OS / GUI framework
> >> > calls. I understand this does not happen too often.
> >>
> >> I beg to differ.
> >
> > Maybe you can name some example.
> 
> 
> OK, lets assume I'm under Linux and fpGUI uses UTF-8 internally
> (ideally I would like fpGUI to use the correct encoding on each
> platform).
> 
> TfpgMemo,LoadFromFile().   TfpgMemo uses a TStringList internally,
> which LoadFromFile maps too. Under Linux, filenames are UTF-8 encoded,
> so conversion occurs because TStringList uses UTF-16 (as per the FPC
> 2.7.1 suggestions) for the filename variable, and for all the file
> access routines. The file contains UTF-8 encoded text. They are now
> converted to UTF-16 text to be stored internally in the TStringList.
> fpGUI now needs to display that text, so calls the UTF-8 X11 API's, so
> another conversion is required.

The conversion of the file names is negligible compared to the
overhead of the OS itself. Even on Linux.

Converting a text from UTF-8 to UTF-16 does some overhead, but compared
to loading it from disk the overhead is not that big. Normally an
application does not simply load a text, it scans or parses the text.
So for most programs the conversion makes only a few percent.

Painting a string is much more expensive than the conversion.

I agree that TStringList can easily create a performance problem, but
afaik loading a text into a GUI is not a good example to
show conversion overhead.

 
> This is a simple example, but look at all the conversions already. Now
> if UnicodeString uses the correct encoding on each platform, the
> conversions would be zero!

No. On Windows you have to open UTF-8 files too.


Mattias