Closed Bug 80561 Opened 23 years ago Closed 10 years ago

dragging splitters too slow on linux

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: Marko.Macek, Unassigned)

References

Details

(Keywords: perf)

Attachments

(1 file)

.html.bz2 tweaked-eazel-profiler profiling run
305.45 KB, application/octet-stream
Details 
Under windows splitters are much faster...

Both in browser in mailnews.

Build 2001050521.
Keywords: perf
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
Assignee: trudelle → evaughan
Target Milestone: --- → 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...
Blocks: 91351
ryanvm, andrew, do you see this ?
Assignee: eric → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
QA Contact: jrgmorrison
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: