Re: Scrolling performance

["Clemens Eisserer" <linuxhippy gmail com>]

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?