On 18 Nov 2000, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > On 18 Nov 2000, Marcus Sundberg wrote:
> >
> > I have hacked a working X-target for libxmi. Jon tested it and merged it into
> > CVS. He also gets a stream of filled polygons and arcs so fast, so that the
> > libxmi-demo can be used for stress-testing the X-server itself. ;)
> >
> > He detected a locking bug in X and I made a workaround for it (see the last
> > patch I sent, which isn't in CVS yet).
> >
> > > You can, by design, *never* accelerate the X-target!
> > > The Xlib-target can and should be accelerated though.
> >
> > Umm... I don't get you. Can you explain what you mean, please?
>
> Read the description of the X and Xlib targets in doc/targets.txt.
>
> For the X-target all drawing is done by the client into a virtual
> framebuffer in RAM, which is copied into an X window when ggiFlush()
> is called (either directly or by mansync).
>
> Any drawing into to the X window done by the X-server will be erased
> by the next ggiFlush(),
Ah! That's why the screen is cleared after I called ggiFlush() in the
target-code.
> so if you think you have added acceleration
> to the X-target the only thing you have actually done is to break it
> completely.
>
> The Xlib target on the other hand can be accelerated just fine by
> any extension.
Err... If I get you right, then wrote a Xlib-target and not a X-target,
right?
So I have just to rename it into Xlib, right?
Christoph Egger
E-Mail: [EMAIL PROTECTED]
