[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? ;-)
You can, by design, *never* accelerate the X-target!
The Xlib-target can and should be accelerated though.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 452062
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
