On Fri, 17 Nov 2000, Jon M. Taylor wrote:
> On Fri, 17 Nov 2000, Christoph Egger wrote:
>
> >
> >
> > On Fri, 17 Nov 2000, Christoph Egger wrote:
> >
> > > > At a quick glance the code looks completely bogus, I'll have a look at
> > > > it this weekend. The extension-segfault problems are the major reason
> > > > why I said the extension system should be re-designed a while ago.
> > >
> > > I am just trying to get the X-target working. XMI_X_getapi() is called for some
> > > days. But XMI_X_setmode() not. Jon said, that this _have_ to happen to
> > > replace the drawing functions with the ones of the X-target.
> >
> > The libxmi has now a working X-target,
>
> Nice work!
TNX.
> > even the output of the accelerated
> > functions is a bit different in comparison to the default one. I can't
> > describe that in words... you have to run the libxmi-demo.
>
> If you mean the visual being cleared between each polygon or arc,
> that is because you have ggiFlush() calls inside your drawing functions in
> funcs.c.
Exactly.
> 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 |->.
Yes. It seems, that the X-server has an bug in the locking mechanism.
I just fixed that on my machine with an work around.
I promise that this fix also works for anyone else.
Patch is attached and is against the newest cvs-snapshot.
> > BTW: Anyone here to merge it in? Jon, what about you?
>
> Done.
TNX. Could you commit this one too, please?
Christoph Egger
E-Mail: [EMAIL PROTECTED]
diff -uNr 20001115/degas/lib/libxmi/display/X/funcs.c
degas/lib/libxmi/display/X/funcs.c
--- 20001115/degas/lib/libxmi/display/X/funcs.c Sat Nov 18 09:33:29 2000
+++ degas/lib/libxmi/display/X/funcs.c Sat Nov 18 09:35:03 2000
@@ -81,6 +81,8 @@
}
+ ggLock(priv->x.xliblock);
+
XSetForeground(priv->x.display, priv->x.gc, col);
XFillPolygon(priv->x.display,
priv->window, /* drawable */
@@ -92,7 +94,8 @@
free(points);
- ggiFlush(vis);
+ XFlush(priv->x.display);
+ ggUnlock(priv->x.xliblock);
return;
}
@@ -111,6 +114,8 @@
}
+ ggLock(priv->x.xliblock);
+
XSetForeground(priv->x.display, priv->x.gc, col);
XFillArc(priv->x.display,
priv->window, /* drawable */
@@ -119,7 +124,8 @@
parc->width, parc->height,
parc->angle1, parc->angle2);
- ggiFlush(vis);
+ XFlush(priv->x.display);
+ ggUnlock(priv->x.xliblock);
return;
}
@@ -128,6 +134,7 @@
void XMI_X_fillarcs(ggi_visual_t vis, miPaintedSet *paintedSet, const miGC *pGC, int
narcs, const miArc *parcs)
{
int i;
+
XMIDPRINT_CORE("XMI_X_fillarcs() called\n");
