194511 - Window painting on remote X server without "RENDER" extension painfully slow

Status: RESOLVED INVALID

(Core Graveyard :: GFX: Gtk, defect)

Description

[Michael Abbott]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030216
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030216

My application environment is slightly unusual: mozilla is running on FreeBSD,
but is being rendered on X-Win32 running on Microsoft Windows (over a 10MHz
lan).  The previous version of mozilla (1.0) was quite usable in this
environment, but the latest version (1.2.1) is like treacle.

For example, as I type this, characters are being rendered at a rate of
approximatey one a second or slower!

On startup mozilla reports:
    Xlib:  extension "RENDER" missing on display "192.168.123.100:0.0".
This is only to be expected, but presumably this problem occurs because mozilla
has no practical fall-back.

Reproducible: Always

Steps to Reproduce:
1. Install X-Win 32 (or, presumably, some other X-server without RENDER support)
on machine a;
2. Run mozilla on machine b with X-server configured for display on machine a;
3. Use mozilla.

Actual Results:  
Ran like treacle.

Expected Results:  
Run about as fast as mozilla 1.0 managed to.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this an xft build?  If so, do you see the same problem with non-xft builds?

Comment 2

[Michael Abbott]

Yes, the build uses Xft (this seems to be the default build mode for the 
FreeBSD port).  I'll rebuild the port without Xft in a day or two and report 
back.

Comment 3

[Christopher Blizzard (:blizzard)]

Xft will use XGetImage/XPutImage if there's no RENDER extension on the server. 
It works, but it's slow as dirt.  I probably will end up WONTFIXing this.  Let
me know if it's something else, though.

Comment 4

[Michael Abbott]

I've rebuilt mozilla using the command:
 # portupgrade -fm '-DWITHOUT_XFT' mozilla
and performance seems to be considerably improved, probably back to the (usable
but slightly sluggish) level of mozilla 1.0.  (Doesn't look as pretty as the Xft
version, though :)

It'd be nice to be able to switch between the two display modes (with and
without Xft), perhaps with a command line switch.

This test is on a low spec W98/X-Win32 laptop with an 11MHz WLAN connection to
the machine running mozilla.  In this configuration mozilla is generally usable
if sluggish (whereas the Xft version was barely usable).

I don't know if it's worth observing this: if I'm viewing the BBC news front
page (http://news.bbc.co.uk) in another window at the same time, typing into
this window is desperately slow.

Comment 5

[Christopher Blizzard (:blizzard)]

If you've compiled with Xft use GDK_USE_XFT=0 in the environment or set
user_pref("fonts.xft.enabled", false); in your prefs.js in your .mozilla
prefs.js file.  That should turn it off and fall back to old-style X fonts.

Comment 6

[Michael Abbott]

I'm not convinced that "RESOLVED INVALID" is the correct fate for this report.

For a start, it seems that mozilla already *knows* how to handle the display in
the absence of the "RENDER" extension (see comment #5), so why doesn't it just
do so?

Secondly, and probably related, in comment #3, Christopher Blizzard offers a
"WONTFIX" resolution instead.

Comment 7

[Christopher Blizzard (:blizzard)]

For a lot of people, XGetImage and XPutImage are going to be fast enough.  It
depends on the speed of the client, the server and the network in between.  I
can't make the bits get pushed any faster, so there's nothing I can fix here.

You can fall back to the old font system if you want, but I'm not going to do
that for non-RENDER servers.  I'm going to allow people to get the AA fonts,
even if it's a bit slower and if they are really bothered by it they can take it
down an even farther notch.

That's why I marked it as INVALID.  There's nothing for me to fix here.