Trick <[EMAIL PROTECTED]> writes:
> Hi, i'm new to this list, and know little about X, so excuse me if i
> ask stupid questions =)
>
> If i understand correctly, X does not support neither double
> buffering or hardware surfaces _at all_. That sounds like a Very Bad
> Thing (tm) to me, since that would decrease possible performance in a
> lot of applications, specially games.. If *nix is to beat windows, we
> need those things!
>
> Now, do i understand this wrongly, or will this be implemented in the
> future ? If not, why not ?
For all practical purposes, it's been supported forever:
XDrawLine (display, pixmap, gc, x1, y1, x2, y2);
[...]
XCopyArea (display, pixmap, window, ....);
As long as your pixmap is allocated inside video memory (a reasonable
thing to expect on today's 32 and 64 meg cards), there is no
significant penalty for doing this as compared to drawing directly
to the window.
(And is, anyways, as fast as you can do double buffering unless you
are drawing the whole screen at once and can just offset the
framebuffer start offset.)
While there is a X double buffer extension, it doesn't really offer
any significant advantages over using pixmaps on normal hardware.
Toolkits may provide some higher level abstractions for doing double
buffering ... for instance, GTK+-2.0 has:
gdk_window_begin_paint (window, &rect); /* offscreen pixmap created */
/* draw to window, drawing is redirected to offscreen pixmap */
gdk_window_end_paint (window); /* pixmap is copied to window */
But that's just a convenience API, and not really intended for
game-style applications.
Regard,s
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
