MantisBT - VTK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006461VTK(No Category)public2008-02-28 11:562016-08-12 09:54
ReporterSebastian Schuberth 
Assigned ToKitware Robot 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Project
Type
Summary0006461: vtkDataArray::Size wrong after call to IDirect3DDevice9::CreateDevice
DescriptionThis is a follow-up to a problem I already reported to the mailing list in mid-2005, but got no helpful response:

http://public.kitware.com/pipermail/vtkusers/2005-June/080188.html [^]

In the attached example program,

pImageReslice->Update(); // Line 86

seems to put an invalid value (always 1) into its vtkDataArray::Size if CREATE_DEVICE_BEFORE_UPDATE is defined, which leads to a crash in

memcpy(data,output,width*height*sizeof(float)); // Line 96

as the array's size is not width*height*sizeof(float) but 1*sizeof(float). If only CREATE_DEVICE_AFTER_UPDATE is defined, or neither are defined, the program just works fine. So for some reason pImageReslice->Update() seems to do something different than it does if no D3D device is created before.

This was tested on Windows XP SP2, 32-Bit, using VS2005 and DXSDK 9.0c (June 2007) with VTK 5.0.4.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip VTKvsD3D.zip (3,093) 2008-02-28 11:56
https://www.vtk.org/Bug/file/6332/VTKvsD3D.zip
Issue History
Date ModifiedUsernameFieldChange
2008-02-28 11:56Sebastian SchuberthNew Issue
2008-02-28 11:56Sebastian SchuberthFile Added: VTKvsD3D.zip
2009-10-26 12:45Thomas ZhangNote Added: 0018240
2009-11-05 12:20Thomas ZhangNote Added: 0018345
2010-12-06 05:07Sebastian SchuberthNote Added: 0023728
2011-06-16 13:11Zack GalbreathCategory => (No Category)
2016-08-12 09:54Kitware RobotNote Added: 0036956
2016-08-12 09:54Kitware RobotStatusexpired => closed
2016-08-12 09:54Kitware RobotResolutionopen => moved
2016-08-12 09:54Kitware RobotAssigned To => Kitware Robot

Notes
(0018240)
Thomas Zhang   
2009-10-26 12:45   
Is there a fix for this?

I am using VTK 5.4.2. I can confirm that this is still a problem. This actually became a bigger problem after the recent Windows update KB958869.

I used to have a workaround for this issue. Now, after Windows update KB958869, the workaround failed too. The returned width and height is always 1.

Windows update KB958869 updated gdiplus.dll to prevent certain buffer overrun issues.
(0018345)
Thomas Zhang   
2009-11-05 12:20   
Update: I have just found another problem after the Direct 3D initialization. This time it has nothing to do with vtkImageReslice.

After the D3D call, the image data from vtkImageData is different and WRONG. I am still not sure which function call applied to vtkImageData gives different results. But if I just remove the DirectX call, everything is fine.

Can we change the priority of this issue to HIGH?
(0023728)
Sebastian Schuberth   
2010-12-06 05:07   
Credits got to Martin Seebass, who has found the cause of this bug. D3D's CreateDevice() by default sets the FPU to single precision (i.e. 24 bits of mantissa) and round-to-nearest mode [1]. While round-to-nearest is the default for C / C++, the default precision is 53 bits, and the magic numbers in vtkResliceRound() rely on it. If vtkResliceRound() is used to calculate the dimensions of an image after the call to CreateDevice(), it returns 0, which leads to the observed crash.

The easiest fix is to specify D3DCREATE_FPU_PRESERVE as a flag to CreateDevice() which "set[s] the precision for Direct3D floating-point calculations to the precision used by the calling thread".

Another fix would be to change vtkResliceRound() so it does not rely on the FPU precision, e.g. by using the SSE rounding instructions.

As a side note, the FPU precision mentioned here refers to the precision that is used by the FPU internally for its calculations. It does not depend on whether you are using "float" or "double" in your application. Even with "float", the FPU by default internally uses double-precision (i.e. 53 bits of mantissa) for its calculations. Only if you write "float" variables to memory, your numbers get truncated in precision.

[1] http://msdn.microsoft.com/en-us/library/bb172527%28VS.85%29.aspx [^]
(0036956)
Kitware Robot   
2016-08-12 09:54   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page.