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@xxxxxx <Valdis.Kletnieks@xxxxxx>: > 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? > > > _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
