Re: Gtk performance issues from a user's point of view
- From: Tero Huttunen <tero huttunen tut fi>
- To: Federico Mena Quintero <federico ximian com>
- Cc: performance-list gnome org
- Subject: Re: Gtk performance issues from a user's point of view
- Date: Tue, 03 Oct 2006 00:56:17 +0300
On Mon, 2006-10-02 at 15:17 -0500, Federico Mena Quintero wrote:
> On Sun, 2006-10-01 at 20:25 +0300, Tero Huttunen wrote:
> > > What evidence do you have that GTK+ probably isn't drawing through
> > > Render?
> >
> > I thought it wouldn't do solid fills through Render. However, I did a
> > new hack, by modifying R200SubsequentCPUtoScreenTexture to return
> > immediately. Result:
> >
> > http://www.students.tut.fi/~huttune2/accel2.png
> >
> > Clearly Qt can accelerate some of the Render-operations, since some of
> > the text is missing, however, Gtk doesn't seem to accelerate anything.
> > What other functions should I test?
>
> This is very interesting!
>
> Keep in mind that GTK+ draws everything to a Pixmap to avoid flicker,
> and then paints the pixmap to the final Window. I wonder if your hack
> contemplates this.
>
> That said, I don't know how pixmaps work when they fall outside of video
> memory. Does the X server just draw to them "by hand", to normal RAM?
>
> [ObFlame: if @#$% Mozilla would not fill VRAM with pr0n, then GTK+'s
> pixmaps may fit in VRAM...]
D'oh! My bad. I'm glad you brought this up, since I then became
suspicious and figured out that I had forgotten a XaaNoOffscreenPixmaps
turned on in xorg.conf after some aiglx testing (no wonder the
back-buffers weren't in VRAM). Turning it off seems to improve the
situation a lot. A new screenshot with both the red solid-fill and the
R200SubsequentCPUToScreenTexture turned off hacks on (accelerated
solid-fills red and everything that goes through R200..Texture should
disappear):
http://www.students.tut.fi/~huttune2/accel3.png
Those toolbar icons are probably already in VRAM pixmaps, and don't go
through CPUToScreenTexture when drawn on the toolbar.
It does seem, however, that contents of small windows, such as small
menus, or the gedit window (when small enough), are not accelerated. I
wonder why is that?
The fact that Qt seemed better at first, was probably because it didn't
do as much double-buffering, and thus it didn't use offscreen pixmaps.
> There's work-in-progress documentation about the GTK+ drawing model
> here:
> http://primates.ximian.com/~federico/misc/gtk-drawing-model/index.html
>
> Federico
>
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]