Re: Scrolling performance



Hello again,

I did some further testing and found that even the gtk-demo part
"paned widgets" show such low performance if the panes are as large as
the whole screen.

I further talked to an nvidia driver developer which also analysed the
situation and got a profile very similar to mine.
This is what he replied:
[quote]So I guess I didn't reproduce your problem. In my case, the
reason so much time is spent in software solid fills and copies is
that GTK seems to create and destroy pixmaps at a fantastic rate. In
fact, it creates and destroys a pixmap every time it blinks the
cursor. Pixmaps start out in system memory and are only migrated to
video memory after they've been used for a while. This means that
creating pixmaps, doing two or three rendering operations, and then
destroying them is a sure-fire way to make your rendering fall back to
software. Future drivers will have an InitialPixmapPlacement
nvidia-settings attribute so people can try tweaking this behavior. If
I use that to force pixmaps to start in video RAM, then profiling
shows that most of the time is spent waiting for the GPU.[/quote]

Does even the default theme uses pixmaps for all and everything?

Any ideas where to look into this?

Thank you in advance, lg Clemens

2006/6/21, Valdis Kletnieks vt edu <Valdis Kletnieks vt edu>:
On Wed, 21 Jun 2006 00:41:31 +0200, Clemens Eisserer said:

> I did some oprofiling, however I don't have a vmlinz-file handy so its
> quite a bit useless:
>      5558 39.2930 no-vmlinux

Bummer. With a system time *that* high, I'm wondering if there's something
odd going on here...  a vmlinux to help split that out would certainly
help a lot in debugging here..

>      2116 14.9593 libfb.so
>      1319  9.3248 nvidia_drv.so
>      1031  7.2888 Xorg
>       603  4.2630 libqt-mt.so.3.3.5
>       550  3.8883 libc-2.4.so
>       470  3.3227 libgobject-2.0.so.0.800.5

Was this your Eclipse test, or gftp?  What I'm seeing on the 'wiggle the
dividing bar on gftp till it saturates the CPU' is this: (and yes, it's a
generic GTK issue, not gftp, unless the 3 other apps I tested did the same
wrong thing with it.. ;)

samples  %        image name               app name                 symbol name
10597    13.6788  libgdk_pixbuf-2.0.so.0.903.0 libgdk_pixbuf-2.0.so.0.903.0 scale_line
7797     10.0645  libgdk_pixbuf-2.0.so.0.903.0 libgdk_pixbuf-2.0.so.0.903.0 pixops_process
5232      6.7536  libfb.so                 libfb.so                 (no symbols)
4834      6.2398  Xorg                     Xorg                     (no symbols)
3318      4.2829  libgdk_pixbuf-2.0.so.0.903.0 libgdk_pixbuf-2.0.so.0.903.0 .loop
3152      4.0687  nvidia_drv.so            nvidia_drv.so            _nv000194X
2591      3.3445  libc-2.4.90.so           libc-2.4.90.so           memcpy
2172      2.8037  vmlinux                  vmlinux                  get_page_from_freelist
2067      2.6681  libpthread-2.4.90.so     libpthread-2.4.90.so     pthread_mutex_unlock
1570      2.0266  libpthread-2.4.90.so     libpthread-2.4.90.so     pthread_mutex_lock
1359      1.7542  nvidia                   nvidia                   (no symbols)
1064      1.3734  libgdk_pixbuf-2.0.so.0.903.0 libgdk_pixbuf-2.0.so.0.903.0 process_pixel
953       1.2302  libglib-2.0.so.0.1102.1  libglib-2.0.so.0.1102.1  g_hash_table_lookup

(or, done by shared library:

    23907 30.8597 libgdk_pixbuf-2.0.so.0.903.0
    10538 13.6027 vmlinux
     5594  7.2209 libc-2.4.90.so
     5377  6.9408 libgobject-2.0.so.0.1102.1
     5232  6.7536 libfb.so
     4953  6.3934 Xorg
     4784  6.1753 nvidia_drv.so
     3933  5.0768 libpthread-2.4.90.so

At least in my case, the top hog appears to be too much work done scaling
theme pixmaps over and over, when they're likely to be invalidated by another
resize before the scaling is completed....

You probably mentioned it before, but what GTK2 theme are you using?






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]