Keith Whitwell wrote:
>
> Brian Paul wrote:
> >
> > Keith Whitwell wrote:
> > >
> > > The real problem with this is that changing to flat shade & back again
> > > means a buffer flush per rectangle. This is masked by the fact that in
> > > the current model we have to do a buffer flush inside the
> > > ASSERT_OUTSIDE_BEGIN_END() command, although this hopefully won't
> always
> > > be the case. The real problem that you are addressing is the large
> > > performance differential between smooth and flat shaded primitives in
> > > the X driver. It shouldn't be too great an effort to attack the
> problem
> > > at its heart & it would certainly be a bigger win.
> >
> > Naturally, smooth shading is a bit slower than flat shading. However,
> > I think the current code is fairly efficient. You'd probably have to
> > resort to assembly language to make it substantially faster.
> >
>
> Actually I had a look at this. I think I am sitting in the worst
> performing graphic mode, because it looks like the truecolor modes are
> the only ones which use XPutPixel. I think we can get a good speedup
> for at least the most common 16-bit XImage formats by writing directly
> into the XImage memory.
The following TrueColor (and DirectColor) visuals use optimized code
which directly pokes pixels into the XImage instead of using XPutPixesl:
32bpp, Rmask=0x0000ff, Gmask=0x00ff00, Bmask=0xff0000
32bpp, Rmask=0xff0000, Gmask=0x00ff00, Bmask=0x0000ff
24bpp, Rmask=0xff0000, Gmask=0x00ff00, Bmask=0x0000ff
16bpp, Rmask=0xf800, Gmask=0x7e0, Bmask=0x001f (5-6-5 mode)
8bpp, Rmask=0xe0, Gmask=0x1c, Bmask=0x3 (HP Color Recovery visual only)
Perhaps you're using a 16bpp, depth=15 (5-5-5) visual?
In X terms, bpp and depth are not the same.
-Brian
----------------------------------------------------------------------
Brian Paul Avid Technology / Softimage [EMAIL PROTECTED]
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
