Under windows splitters are much faster... Both in browser in mailnews. Build 2001050521.

My personal view is that I don't notice a difference, except that the painting is slower (i.e., damaged areas are visible longer while dragging back and forth). This is on two equally powered 500MHz/128MB systems (win2k/rh6.1). Is there some particularly way to quantify "too slow"?

I can't tell, because my Linux build updates the content as I drag, but my Win98 build just drags a ghost-splitter, and updates when I drop it. I'm not sure why, since it updates live when I drag the scrollbar thumb. ->evaughan/future

This seems to depend greatly whether you are running Mozilla under Gnome or KDE. On build 2001072421 painting is clearly visible (~0.3 - 0.5 sec/paint with my subjective mental clock) under KDE, but under Gnome, the painting is almost realtime. Higher resolutions,such as 1600x1200 on 24 bit color depth, slow the painting remarkably on KDE. Setup: * Mandrake 8.0 * KDE 2.2 Beta 1 * QT 2.3.1 * Gnome 1.4 * Sawfish window manager under Gnome * GTK 1.2.10 * 1GHZ Athlon Thunderbird * Geforce 3 using XFree86 4.1.0 built-in drivers The difference between Gnome and KDE seems to be, that on Gnome, more painting events are supressed(?) resulting more visible damaged rects, but faster response, on KDE damaged rects are not visible, but the dragging is very choppy. Oddly enough, performance is almost same on my work setup (700Mhz PII, Matrox G200) and my home setup, both running KDE. Easiest fix for the responsiveness problem could be to enable ghost-splitter on Linux, but this doesn't help the original problem. I'm going to try and build a qt-version and see if it changes the performance. I also tried a quick hack and forced the GTK splitter code to use the ghost mode, and as expected, it helps the responsiveness much. However, it breaks the painting, and looks quite awful currently. As for splitters being too slow, I think that 2-3 paints/sec on my setup might qualify as "too slow" ;)

This seems to depend greatly whether you are running Mozilla under Gnome or KDE. On build 2001072421 painting is clearly visible (~0.3 - 0.5 sec/paint with my subjective mental clock) under KDE, but under Gnome, the painting is almost realtime. Higher resolutions,such as 1600x1200 on 24 bit color depth, slow the painting remarkably on KDE. Setup: * Mandrake 8.0 * KDE 2.2 Beta 1 * QT 2.3.1 * Gnome 1.4 * Sawfish window manager under Gnome * GTK 1.2.10 * 1GHZ Athlon Thunderbird * Geforce 3 using XFree86 4.1.0 built-in drivers The difference between Gnome and KDE seems to be, that on Gnome, more painting events are supressed(?) resulting more visible damaged rects, but faster response, on KDE damaged rects are not visible, but the dragging is very choppy. Oddly enough, performance is almost same on my work setup (700Mhz PII, Matrox G200) and my home setup, both running KDE. Easiest fix for the responsiveness problem could be to enable ghost-splitter on Linux, but this doesn't help the original problem. I'm going to try and build a qt-version and see if it changes the performance. I also tried a quick hack and forced the GTK splitter code to use the ghost mode, and as expected, it helps the responsiveness much. However, it breaks the painting, and looks quite awful currently. As for splitters being too slow, I think that 2-3 paints/sec on my setup might qualify as "too slow" ;)

I built qt version with configuration parameters from http://linux.ucla.edu/~dimator/qt-mozilla/ and I saw no noticeable gain.I suspect this is related to KWM (KDE window manager), since on Sawfish (GNOME) drawing works much faster.The nice -19 -trick described in some other bug (I couldn't find it, sorry) seems to speed up the dragging a bit, but it's still slower than on Gnome.

Ok, some progress on this one... Painting speed is not related to window manager, since I tried KDE with Sawfish and noticed no difference in painting speed. However, I just upgraded my kernel to 2.4.7, to troubleshoot NVIDIA drivers (which seem to have something against my setup ;), and after upgrading I noticed HUGE improvement in painting speed. In this case, HUGE means that the splitter paints, which used to take around 0.3 - 0.5 seconds now refresh in realtime. (i.e. just like under Gnome). Damaged rects are more visible, but the splitters move very fast. This would also explain the different results people are getting, since most of Netscape people are running Mozilla under Redhat 6.2 (if I'm correct?). However, I seem to be getting a lot of painting errors, which may be caused by incorrect setup on my part, but that's another story... Any educated guesses what caused the splitter lag in 2.4.3? It probably hits a lot of people, since Mandrake 8.0/Geforce -combo is probably quite common.

I have now tried several different things: - new MGA G450 graphics card - new XFree 4.0.? and 4.1 - several different 2.4 kernels (2.4.8,2.4.9 last) No improvement noticed. Still extremely slow (specially the mailnews) CPU=Celeron433 RAM=384M WM=icewm

Hmm. This is quite odd. It seems that the lag might not be related to display drivers at all. Also, the speed seems to vary greatly depending on the desktop environment and kernel version. I did a double check on the nvidia drivers, and the speed seems to be same whether I use Xfree standard drivers or nvidia's own drivers. Marco, could you give some details about your system, i.e distribution, version and the exact desktop setup (are you running standalone icewm) and if possible, run checks on Gnome or KDE? For me, the Gnome setup ran very well when KDE was absolute pig... The painting hotspot *might* be outside mozilla, and I for sure would like to know what causes this slowdown on some setups. I will check the Gnome and IceWM performance on my work-setup tomorrow to get some idea how the mozilla performs on G200/2.2.18 kernel -combo (KDE is very slow).

Ok, confirm the lag on IceWM, Gnome and KDE, system 650MHz PIII, Matrox G200, kernel 2.2.18, XFree 4.03 Mandrake 7.2. Very choppy behaviour.

I also tried sawfish and the kwin. No visible difference. Time to do some profiling.

There was an issue raised in newsgroups about the XFree and write-combining in drivers. This is a good theory, but unfortunately on my work setup the write-combining is on and the splitters still lag. IIRC, write-combining means that the driver collects paint operations to a bunch (instead of sending them separately to the bus) and then sends the bunch to graphics card. (use cat /proc/mtrr to check the status) <speculation> What if the write-combining tries to combine too many operations, resulting a choppy paints as huge paint-operations are sent to card in slow intervals? Could the painting do a flush to force the driver to send operations to card in smaller packets? I have no applicable knowledge of X internals, unfortunately. </speculation> Other speculative guesses are drivers that do not work well with a large number of small paints (which mozilla apparently does a lot =) or slow implementations of XCreateGC... (I did simple xmon profiling during the summer and compared the operation profiles of Konqueror and Mozilla and only major difference I found was the difference in gc creation calls... Mozilla did ~10x more creategc calls than konq) Need to start combing thru the code again...

I posted the profiling run using my hacked eazel-profiler (instrumenting profiler using gcc -O0 -finstrument-functions. Full mozilla was instrumented) It is possible that nsGCCache is not getting enough hits. Unfortunatelly I disabled all logging, tracing etc... so I can't verify this immediatelly.

If the gc creation is the root of the problem, then I would blame nsImageGTK... For me it seems, that nsImageGTK doesn't use the GCCache at all, and there are temporary gc's created all over the place... http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsImageGTK.cpp (search for "gdk_gc_new") I don't know whether nsImageGTK defeats the cache on purpose, but all other classes seem to use cache for gc allocation.

I just noted, that running X on 24bit colordepth bogs down the painting for me. On 16bit colordepth splitters paint fast enough. Nvidia driver issue prevented me from running X on 24bit, so I didn't notice this earlier. I try to get some profiling data for both cases with eazel profiler, but I haven't got the profiler working yet...

ryanvm, andrew, do you see this ?