On 18 Nov 2000, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > > Don't do that, let the GGI or the user program or the mansync
> > > helper decide when to flush. You are in effect forcing SYNC mode for
> > > those primitives by doing that.
> >
> > But when I remove it, then I get the same bug as you describe below:
> >
> > > There is still something else going wrong, to cause those
> > > screen-clears - I think it is because we still expose and use
> > > miCopyPaintedSetToVisual() (and the paintedSet type in general) outside of
> > > the stubs code. That needs to go away. When we use the X-target, we are
> > > no longer drawing onto our allocated PaintedSet, but we still draw the
> > > (empty) paintedSet to the ggi_visual anyway |-<.
> > >
> > > Anyway, when I removed those two ggiFlush() calls, I got a proper
> > > (and very fast) stream of polygons and arcs to the screen. I also began
> > > to trigger an Xlib bug quite often |->. It seems that demo.c is not only
> > > useful for stress-testing the stubs rasterization code (which still has
> > > one infinite-loop lockup bug which occasionally shows up in the rectangles
> > > test), but now that the XMI X-target is working, it is also useful for
> > > stress-testing the X-server itself |->.
>
> Umm, what are you guys doing? ;-)
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?
Christoph Egger
E-Mail: [EMAIL PROTECTED]
