Closed Bug 194511 Opened 21 years ago Closed 21 years ago
Window painting on remote X server without "RENDER" extension painfully slow
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.
Is this an xft build? If so, do you see the same problem with non-xft builds?
Assignee: kmcclusk → blizzard
Component: GFX → GFX: Gtk
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.
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.
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
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.
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.
You need to log in before you can comment on or make changes to this bug.