Performance change from X in Fedora Core 4 to Fedora Core 5

Carsten Haitzler (The Rasterman) raster at
Thu Jul 13 03:24:33 PDT 2006

On Thu, 13 Jul 2006 01:38:44 +0100 Felix Bellaby <felix at>

> On Thu, 2006-07-13 at 07:52 +0900, Carsten Haitzler wrote:
> > > I must confess that it was a guess on my part. If nvidia have confided
> > > otherwise then bully for them. I wonder how they do it, and whether it
> > > is as fast as drawing to a stable drawable? 
> > 
> > it is give and take. you incur some extra expense for a temporary pixmap
> > allocation and de-allocation in return for not holding on to that video ram
> > permanently and thus eventually running out of video ram and needing to swap
> > things in and out of video ram and possibly force your os to start swapping
> > to/from disk. chances that you need all of that tmp pixmap space (the worst
> > case scenario is a whole window in size per window for all windows) all at
> > the same time for redrawing is very unlikely. so it is again a trade-off. i
> > would much sooner save the video ram as it is so incredibly easy to fill it
> > up and run out this way and then watch performance drop through the floor,
> > that you want to save the ram, if you can. the allocation expense, in my
> > experience with a range of x drivers and cards over a decade or so of
> > writing x code that loves to do this kind of stuff, is very minimal to the
> > point of "don't worry about it".
> I based my gloomy forecast on my recent experience of trying to allocate
> and deallocate GLXPixmaps on nVidia hardware. Even when the new
> GLXPixmap references exactly the same Pixmap (which remains X allocated)
> this process takes longer than copying the Pixmap. I can only presume
> that this is a synchronisation problem, but I do not really know.

i suspect it is a sync and lock/unlokc/round trip performance issue. alloc and
de-alloc of 2d pixmaps inside of x is fast.

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at
Tokyo, Japan (東京 日本)

More information about the xorg mailing list