Thanks David. As I was tracing through it, it appeared the
translation could be done in several places, but my limited knowledge of
this area of the DX code didn't indicate a best choice. Could be that byte
colors in a DX field should never even get to this point without
conversion, or maybe the rendering macros should have a if-case to handle
byte colors at render time, or...
Randy
David Thompson:
|I agree that this would fix the problem, but we should look at fixing
|it to automatically do this if the type is coming in as unsigned
|char. I will look at this.
|
|David
|
|>Randall Hopper:
|> | 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,
|>
|>By way of confirmation, this unsigned char[3] -to- float color conversion:
|>
|> Mark("colors") ---> Compute("$0/255.0") ---> Unmark()
|>
|>inserted before the data gets to render seems to avoid all encountered
|>memory problems.
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
