The attached 4-module (trivialized) DXcallm program demonstrates the problem, resulting in ABRs in Purify, and bad renderings and core dumps with larger fields.
I traced it through, and it appears the problem is this: the field
being rendered (see ASCII sky.dx attached) has 24-bit RGB colors associated
with every position. The rendering macros (SPLIT and ADDPT in zclip.h)
don't handle this, but don't check for it either, resulting in incorrect
behavior and memory problems.
In more detail, when Render is called _dxf_XColors is invoked to
create the struct xfield used for rendering. In it, DX notes:
xf->fcolors = <colors buffer, in unsigned char [3] format>
xf->bcolors = <colors buffer, in unsigned char [3] format>
xf->fbyte = 1
xf->bbyte = 1
xf->cmap = NULL
So far, so good.
But then when we get to rasterization and clipping down here:
DXRender -> ... _dxfPaint -> ... -> _dxf_Quad -> _dxf_zclip_quads
in _dxf_zclip_quads, the TRYCLIP macro (zclip.h) is used 6 times. It
invokes the other macros SPLIT and ADDPT (also zclip.h). These macros
assume that if there is no colormap (xf->cmap = NULL), then the colors
must be RGBColor structs (floats) which is not correct.
The work-around is not to Render anything with 24-bit RGB colors, but
to convert colors to floats first. But I suspect the right fix is for the
rendering pipeline to be extended to support 24-bit direct colors on a field.
Dave (or someone knowledgable with this area), what's your opinion?
Am I voilating an internal assumption, or is this a bug?
Thanks,
Randall
BTW, all this was tested with DX CVS from yesterday around 6:10pm.
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
sky_test.tgz
Description: application/tar-gz
