Re: Unidentified subject!

[David Benson <daveb idealab com>]

Actually in double-buffering X one usually uses
server-side pixmaps.  Only in rare apps that
want to render pixels themselves into XImages (like doom)
are pixels transmitted.

Another key point is that windows apps gain speed by doing
the scrolling copy in hardware (in X one uses via XCopyArea...).
This is what makes it so generally speedy, and would
generally be hampered by double-buffering, esp if the
buffer winds up in main memory as opposed to on card memory.

- Dave

On Mon, 22 Nov 1999 pbg1854@garnet.acns.fsu.edu wrote:

> On Mon, Nov 22, 1999 at 02:37:46AM +0100, Antonio Campos wrote:
> > Certainly we have beaten Windows in a lot a questions, but the
> > smoothness of Windows is not only due to the graphics chipset (it's
> > an important factor obviously). I think that Windows is not using
> > GDI on a few applications. I think is really using DirectDraw to
> > write directly to video memory. If it is so, I don't like this way
> > of doing things, because DirectDraw is a focus of security problems
> > (no restrictions over who writes to video memory...).  Nevertheless,
> > I expect GTK to include double buffered widget in future releases...
> 
> Don't forget that sometimes X programs are run over a network link.
> Smooth scrolling would be slow as hell if it has to be transfered over
> that, even if it's 100 BaseT ethernet. It doesn't matter *what* you
> use for graphics hardware in this case. And wouldn't double buffering
> be *slower* over a network link? If you use standard X calls, only the
> commands for those calls are transmitted, but if you use a buffer, you
> have to send every pixel in the region over the link, right?
> 
> Pete
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.
> 
>