Note the crosspost between opera.os.solaris and comp.sys.sun.hardware,
since although this is a problem in Opera (and maybe also in QT, but I
can't find any Trolltech newsgroups), it may be that someone with
knowledge of the various Sun Graphics Cards will be able to shed some
light on it.

My system is:

chl% uname -a
SunOS clerew 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-2

I run the Opera browser version 9.25 which incorporates Qt 3.3.5, but the
problem also existed on Opera Version 9.0. I have two screens, my main one
running on /dev/fbs/ffb0 (the on-board Creator Graphics) and the other on
/dev/fbs/cgsix (an sbus Turbo GX).

Opera works fine on the TGX screen, but there is a big problem on the
Creator Screen.

It happens when there is an editing window open (usually when composing an
email), AND the insertion point is within that sub-window (i.e. not scrolled
out of sight) AND the cursor is anywhere within the Opera window (AND, to
show it up, when there is lots of text visible in there).

In that situation, Opera slows to a crawl (as seen by the Perfmeter) and
typing in characters becomes unacceptably slow (e.g. you type ahead a
large number of characters, possibly incluging backspaces and cursor
movements, and then sit back and watch while they get displayed, at the
rate of about 2 or 3 per second). No such problem on the TGX screen, so
something somewhere knows what graphics card it is speaking to.

Here is some truss output:

/1@1: <- libX11:XSetErrorHandler() = 0xfe7af45c
/1@1: -> libX11:XPutImage(0x13c0248, 0x13daccd, 0x18e7190, 0x1d8cda8)
/1@1: <- libX11:XPutImage() = 0
/1@1: -> libX11:XSetForeground(0x13c0248, 0x18e7190, 0x0, 0x0)
/1@1: <- libX11:XSetForeground() = 1
/1@1: -> libX11:XSetForeground(0x13c0248, 0x18e7190, 0x0, 0x0)
/1@1: <- libX11:XSetForeground() = 1
/1@1: -> libX11:XSetErrorHandler(0xfe7af45c, 0x15, 0x0, 0x0)
/1@1: <- libX11:XSetErrorHandler() = 0x8dc504
/1@1: -> libX11:XGetImage(0x13c0248, 0x13daccd, 0x27, 0x175)
/1: write(3, " H02011E01 =ACCD01 =ACCF".., 1164) = 1164
/1@1: <- libX11:XGetImage() = 0x1d8cda8
/1@1: -> libX11:XSetErrorHandler(0x8dc504, 0x93, 0x24c, 0x1cc09d0)
/1@1: <- libX11:XSetErrorHandler() = 0xfe7af45c
/1@1: -> libX11:XPutImage(0x13c0248, 0x13daccd, 0x18e7190, 0x1d8cda8)
/1@1: <- libX11:XPutImage() = 0
/1@1: -> libX11:XSetForeground(0x13c0248, 0x18e7190, 0x0, 0x0)
/1@1: <- libX11:XSetForeground() = 1
/1@1: -> libX11:XSetErrorHandler(0xfe7af45c, 0x3f, 0x0, 0x0)
/1@1: <- libX11:XSetErrorHandler() = 0x8dc504
/1@1: -> libX11:XGetImage(0x13c0248, 0x13daccd, 0x43, 0x174)
/1: write(3, " H02\09901 =ACCD01 =ACCF".., 632) = 632
/1@1: <- libX11:XGetImage() = 0x1d8cda8
/1@1: -> libX11:XSetErrorHandler(0x8dc504, 0x276, 0x9d8, 0x18e7488)
/1@1: <- libX11:XSetErrorHandler() = 0xfe7af45c
/1@1: -> libX11:XPutImage(0x13c0248, 0x13daccd, 0x18e7190, 0x1d8cda8)
/1@1: <- libX11:XPutImage() = 0
/1@1: -> libX11:XSetForeground(0x13c0248, 0x18e7190, 0x0, 0x0)
/1@1: <- libX11:XSetForeground() = 1
/1@1: -> libX11:XSetErrorHandler(0xfe7af45c, 0x1c, 0x0, 0x0)
/1@1: <- libX11:XSetErrorHandler() = 0x8dc504
/1@1: -> libX11:XGetImage(0x13c0248, 0x13daccd, 0x89, 0x174)
/1: write(3, " H0202 |01 =ACCD01 =ACCF".., 2564) = 2564
/1@1: <- libX11:XGetImage() = 0x18e70c8

which is repeated over and over again (fd 3 is the stream sending it all
to the XSun Xserver).

I managed to catch a stack trace using 'pstack':

feb40c80 _read (3, ffbfc878, 20, 0, 7, ff29322c) + c
ff21cf68 _XRead (0, ffbfc878, 20, 13c0248, 0, 20) + 38
ff21df2c _XReply (13c0248, ffbfc878, 0, 0, 4, 13c49ec) + 10c
ff2404ec XGetImage (13c0248, 13b6b11, 0, 0, d, 8) + a0
fe7af78c XftGlyphCore (1d40cc8, 13b6b11, 1944a48, ffffff74, ffffff29, 3) + 328
fe7a5964 XftDrawGlyphs (1d40cc8, ffbfdeb8, 1944a48, ffffff74, ffffff29, ffbfce50) + ac
fe7a5aec XftDrawString16 (1d40cc8, ffbfdeb8, 1944a48, ffffff74, ffffff29, 1cdb90e) + 8c
0091a7e8 DrawString__7Xft2LibPvT1iiiiiUiPCvii (13e45c0, 1944a48, 1d40cc8, ffffff74, ffffff29, 0) + 80
003e10f0 DrawStringFragment__20X11OpPainterInternaliiPCUsi (1cdb90e, 3, 2820, 3, 0, 3f) + 34c
003e0d20 DrawString__20X11OpPainterInternaliiPCUsi (194e470, ffffff74, ffffff29, 1cdb908, 3, 1001c00) + 298
003e1ce0 DrawString__12X11OpPainterRC7OpPointPUsUii (194e430, ffbfe1a0, 1c045c2, 3, 0, 3e1c6c) + 74
003ec94c ???????? (194e430, ffbfe1a0, 1c045c2, 3, 0, 3e1528)
003f0290 TxtOut__12VisualDeviceiiPCUsi (194e4d8, 97, 1bc, 1c045c2, 3, 3f01e8) + a8
006f7268 DrawFragment__FP12VisualDeviceiiiiiiPCUsP16OP_TEXT _FRAGMENTUiUiUii (194e4d8, 93, 1f4a, 0, 0, 0) + 18c
006ecfa0 HandleWord__14PaintTraverserP9OP_TCINFOP16OP_TEXT_ FRAGMENTi (ffbfe3d8, 1423c60, 1c04660, 1966248, 6ecd28, ffbfe340) + 278
006ee4d0 Traverse__9OpTCBlockP9OP_TCINFOP18OpTCBlockTravers eriii (0, 4, 7, 1c7, 0, 0) + 558
006ecc20 Paint__16OpTextCollectionUiUiUiRC6OpRect (1c04550, 12df800, ffffff, 800000, ffbfe490, 2df) + 130
006e5bc0 OutputText__15OpMultilineEditUi (1965f88, 0, 4, 403, 2, 2d7) + 1d4
00a4d8d4 DrawMultiEdit__16CssWidgetPainterRC6OpRect (1423c18, 1965f88, 13418e8, a4d600, 0, 0) + 2d4
006f5d38 DrawMultiEdit__22OpWidgetPainterManagerRC6OpRect (153683c, ffbfe660, 6f5d0c, ffbfe660, 8, 375) + 2c
006e497c OnPaint__15OpMultilineEditP15OpWidgetPainterRC6OpR ect (1965f88, 1536830, ffbfe7e0, 6e4948, 19791c8, 1000) + 34
006f3b78 GenerateOnPaint__8OpWidgetRC6OpRecti (1965f88, ffbfe7e0, 0, 6f3784, 29d, 123) + 3f4
006f3d84 GenerateOnPaint__8OpWidgetRC6OpRecti (194e660, ffbfe870, 0, 6f3784, 0, 126) + 600
00f5412c OnPaint__22ContainerPaintListenerRC6OpRectP9OpPain terP8CoreViewii (194dc60, ffbfe908, 194e430, 194e160, 0, 0) + bc
003ea64c Paint__8CoreViewRC6OpRectP9OpPainteriii (194e160, ffbfea00, 194e430, 0, 0, 0) + 298
009278b0 OnPaint__17CoreViewContainerRC6OpRectP6OpView (194e160, ffbfea00, 194e1f8, 13345c8, 92780c, 19a2428) + a4
008d5b44 paintEvent__10ScrollViewP11QPaintEvent (194e280, 0, ffffffff, 1, 1, 19a29b8) + 6c4
00bff940 event__7QWidgetP6QEvent (194e280, ffbfecb8, ffbfecb8, fead41c8, feb92000, 1000) + 3f8
008d546c event__10ScrollViewP6QEvent (194e280, ffbfecb8, 132de18, 8d5258, 8dd72c, feb709b0) + 214
00ba474c internalNotify__12QApplicationP7QObjectP6QEvent (0, 194e280, ffbfecb8, feb92000, 13d9e98, 0) + 1c8
00ba42f8 notify__12QApplicationP7QObjectP6QEvent (0, 194e280, ffbfecb8, 132ffe8, ba3a5c, ffbff228) + 89c
00b78fc8 repaint__7QWidgetRC7QRegionb (194e280, 1d35208, 0, fbdfa4, 1969428, 0) + f4
00ba5afc sendPostedEvents__12QApplicationP7QObjecti (0, 0, cb1e80, 13d9e20, ba3a5c, ffbfedc8) + 1e8
00ba5904 sendPostedEvents__12QApplication (1, 13ae000, 13be3b8, 1, 9da860, 19babf9) + 8
00d45ff0 processEvents__10QEventLoopUi (18db5e0, 4, 1397fe8, 0, 1233400, 0) + 38
00baf820 enterLoop__10QEventLoop (18db5e0, 1397fe8, baf7b4, 4c69f8, feb68284, feb709b0) + 6c
00baf708 exec__10QEventLoop (18db5e0, 1397fe8, 0, baf6c0, feb92000, 1000) + 48
00ba4a20 exec__12QApplication (ffbff228, 1232c00, bd, 4c6968, feb68284, feb709b0) + 18
008c63cc Exec__15QtOpMessageLoop (1b1bc38, bd, 1231400, 12e5dd0, 18dbdb8, 0) + 8
003cfff8 main_contentL__FiPPc (1b1bc38, 13ab800, 0, 0, 0, 0) + 3c98
003cb7dc main (0, ffbff91c, ffbff924, 13b1094, feb90240, f80) + 40

The important thing to note is the call of XftDrawString16, which comes
from libXft (which is hard built into Opera, presumably via QT).

Sadly, I cannot run Opera under 'dbx', so I had to resort to 'mdb', which
is a gross pain to use :-). But I then did manage to work out what was
happening. Each call of XftDrawString16 (of which there are many) writes
one 'word' (for a rather conservative definition of "word") to the screen.
And it continues to make those calls until it has written the whole of your
editing window, at which point it accepts exactly one character that you
have typed in. Wash, rinse, and repeat :-( .

But that (inefficient as it might seem) is NOT the problem. Because on the
TGX sceeen the implementation of XftDrawString16 has the good sense to
realise that it is merely being asked to overwrite exactly what is already
there, so it takes no further action (unless something really has
changed).

BUT, on the Creator screen, it calls XPutImage (and all the rest of the
stuff you saw in the truss) once for every two calls of XftDrawString16,
which in turn calls upon the Xserver to send it all afressh to the
graphics card, and that is where all the time is getting lost.

So, is this a bug in Opera (well, yes it obviously is) or is it a bug in
QT, or is it a but in libXft?

All opinions welcome!

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Charles Lindsey wrote:
> Note the crosspost between opera.os.solaris and comp.sys.sun.hardware,
> since although this is a problem in Opera (and maybe also in QT, but I
> can't find any Trolltech newsgroups), it may be that someone with
> knowledge of the various Sun Graphics Cards will be able to shed some
> light on it.
>
> My system is:
>
> chl% uname -a
> SunOS clerew 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-2
>
> I run the Opera browser version 9.25 which incorporates Qt 3.3.5, but the
> problem also existed on Opera Version 9.0. I have two screens, my main one
> running on /dev/fbs/ffb0 (the on-board Creator Graphics) and the other on
> /dev/fbs/cgsix (an sbus Turbo GX).
>
> Opera works fine on the TGX screen, but there is a big problem on the
> Creator Screen.
>

You didn't say which Opera you downloaded, Static or Dynamic. I have
the latest Opera running on my Blade 2500 and use the Static version.
Way in the past I did have some trouble with the Dynamic version. Try
downloading the Static version.

Paul