Subject: Solaris 8 and Iconv

From: Olivier Chapuis <[email-masked]>
Date: Thu, 4 Mar 2004 06:35:05 +0100

Hello,

So it seems that Solaris 8 + Iconv and 2.5.7 has no problem with text
rendering performance (at least with an iso8859-1 locale). But 2.5.8
and better has some important problem (fixed by --disable-iconv).

In a certain sense text rendering performance with Solaris 8 + Iconv is
not surprising. Solaris 8 has a poor iconv implementation.  E.g., sun
ask to use gnu libiconv on Solaris 8 for GNOME2.

About 2.5.7 vs 2.5.8 or better, I see two possibility, either there is
a configure bug in 2.5.7 which disable iconv or some change in
Flocale*.c force to use utf-8 conversion to often. The only thing I
can remember is that when I wrote the locale support I take care to
use utf-8 conversion only when this is really needed.

Markus can you check that all the new (vs 2.5.7) text conversion
stuff are not used too often?

In any case even if we can found workarounds for an iso8859-1 locale +
Solaris 8 we may still have some problem as any other software which
uses iconv (e.g., any i18n soft which use the glib!).

So it will be fine if we can detect during configuration that the libc
implementation of iconv is ok and disable iconv if not (note that if
gnu libiconv if found fvwm will use it and I do not think that we will
have problem with it).

Unfortunately, I do not see a simple generic way to test if a libc
iconv implementation is ok. But, maybe we just have to check that the
libc is the Solaris 8 libc (Is this possible?).  Maybe other system
either have a good libc iconv implementation or use gnu libiconv (This
is the case of the BSD* I think).

Regards, Olivier
 
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Marcus Lundblad <[email-masked]>
Date: Sat, 6 Mar 2004 01:37:40 +0100 (CET)

> stuff are not used too often?

I removed some redundant calls.
Actually for example when drawing underlines, the width (in pixels) of one
character is computed. In this case, if the character consists of one byte
(ISO-8859-x) I make the assumption that the width is equal to the "raw"
character corresponding to that byte. This will work exept for ISO-8859-6
(8-bit Arabic) which we don't support anyway (this would need joining
characters using UTF-8 internally).
I also included a check in the drawing routine so that character positions
is only computed when combining characters are actually present in the
string (redundant otherwise).

Could somebody try this out in Solaris 8?

//Marcus

---

From: Dan Espen <[email-masked]>
Date: Fri, 05 Mar 2004 20:19:49 -0500

> Could somebody try this out in Solaris 8?

Not before monday for me.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Mon, 08 Mar 2004 10:40:51 -0500

> Could somebody try this out in Solaris 8?

It's definitely faster.
The menus come up blank and the text appears 1/4 second later.
On larger menus, I can see the text appear in blocks.

If I had to use a Solaris system, I would still want to disable iconv.

---

From: Marcus Lundblad <[email-masked]>
Date: Mon, 8 Mar 2004 20:29:27 +0100 (CET)

> On larger menus, I can see the text appear in blocks.

How about using UTF-8 locale on Solaris 8?
Is that implementation smart enough to just return imediatly when
converting UTF-8 to UTF-8 (like in glibc, the pointer is just return back,
the code in Flocale.c checks this)?

I don't see much more to do (the combining code uses 16-bit charcters
internally, so converting to UTF-8 and then to 16-bit is needed).
One alternative as a last emergency could be to write special code as
fallback for at least ISO-8859-x to/from UTF-8, but this seems close to
reimplementing Iconv.

Actually I find it amazing that implementation can be so slow.
On my system, PII 400 MHz, I don't notice any abnormal delay even using
the version before my last fix (though I use UTF-8 locale, so maybe that's
the reason).

//Marcus

---

From: Dan Espen <[email-masked]>
Date: Mon, 08 Mar 2004 15:01:23 -0500

> How about using UTF-8 locale on Solaris 8?

I went back to the console prompt, then did:

export LANG=en_US.UTF-8

then I started up xwindows and fvwm.
I didn't see any speed difference.

The Ultra 5 that I have is 270MHz with 128Meg.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 28 Mar 2004 23:22:00 +0200

> the code in Flocale.c checks this)?

I do not think that the Solaris 8 libc supports an UTF-8 locale.

> fallback for at least ISO-8859-x to/from UTF-8, but this seems close to

Hum, for which charset we need to "combine" characters? Do we need
to combine for iso8859 1 or 15 charset for example? If yes can you give
a concrete example.

With bidi conversion are performed only for UTF-8, ISIRI-3342,
ISO8859-6, ISO8859-9, CP1255 or CP1256. I suggest we do something
like that for combining.

> the version before my last fix (though I use UTF-8 locale, so maybe that's

The problem is not the CPU. It seems that on Solaris 8 iconv is
dramatically slow.

Regards, Olivier

---

From: Marcus Lundblad <[email-masked]>
Date: Mon, 29 Mar 2004 00:30:19 +0200 (CEST)

> ISO8859-6, ISO8859-9, CP1255 or CP1256. I suggest we do something

Actually there could be more encodings that need combining (TIS 620, the
Thai 8-bit encoding comes to mind).
But for ISO 8859-1, 8859-2 etc., I guess you're right and we can skip it.
I'll investigate this further.

//Marcus