Pixeltoaster in windows affects floating point precision. Causes problems with Cairo graphics

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a Display 
2. Do something that requires full precision floating point calculations

What version of the product are you using? On what operating system?
1.4.1 Windows

Code that relies on full floating point precision can break when opening a 
pixel toaster display since the D3D function CreateDevice messes with the 
FPU flags.
Specifically it means you can't use pixel toaster to display graphics 
rendered with Cairo (cairographics.org) since it uses some funky floating 
point math to do float to fixed point conversion.
A workaround on the pixel toaster side is to supply the flag 
D3DCREATE_FPU_PRESERVE as behaviour flag when creating the d3d device, 
however microsoft warns that this might cause undefined behavior!
I have some more info in this thread:
http://lists.cairographics.org/archives/cairo/2009-April/016995.html

I'm not sure whether I want this to be patched, but if this bug report 
saves someone the hassle of figuring out why Cairo won't render to pixel 
toaster displays I'm glad I could help :)

Original issue reported on code.google.com by laseral...@gmail.com on 24 Apr 2009 at 9:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I would like to advocate that this be patched in PixelToaster - I am forced to 
patch it  
locally at present.

The FPU_PRESERVE flag is unlikely to cause problems even in complex Direct3D 
applications, and at the complexity of PixelToaster, it is definitely all right.

Further, cairo is a fairly popular library, and ti would seem sensible to be 
compatible.

Original comment by swiftcoder on 1 Jun 2010 at 6:21

[GoogleCodeExporter]

Is it not possible to just force the FPU precision to the correct mode *before* 
rendering cairo graphics? This would seem the safest workaround for me, I doubt 
that 
every pixeltoaster user would want to set D3DCREATE_FPU_PRESERVE by default, 
especially 
if microsoft warns it may cause "undefined behavior" (!)

Original comment by glenn.fi...@gmail.com on 1 Jun 2010 at 6:41

[GoogleCodeExporter]

A compile-time switch (i.e. a #define) to enable the FPU_PRESERVE flag would 
also be 
reasonable - at least it would save us from having to manually hack the source 
code.

My feeling is that most users of PixelToaster aren't using Direct3D in their 
PixelToaster applications (though I may be wrong). If only PixelToaster is 
making 
Direct3D calls, then it should be perfectly safe to use FPU_PRESERVE, as 
PixelToaster 
doesn't do anything to trigger floating-point exceptions in the kernel. The 
"undefined behavior" refers to the possibility of floating-point exceptions, 
which 
with the Windows XP driver model could trigger a BSOD - on Vista and Windows 7 
this 
is no longer the case.

Keep in mind that DX9's default behaviour of forcing all floating-point 
operations to 
execute at single precision was considered disruptive enough that it was 
removed 
entirely from DX10/DX11 (not just disabled by default, but removed all 
together).

Original comment by swiftcoder on 1 Jun 2010 at 7:21

[GoogleCodeExporter]

Perhaps we should just upgrade PixelToaster to support DX10+ only, or is it too 
soon?

Original comment by glenn.fi...@gmail.com on 1 Jun 2010 at 7:46

[GoogleCodeExporter]

Shall we add a #define PIXELTOASTER_FPU_PRESERVE to control this option?
Because of the "undefined behavior" warning, I'm inclined to make this an 
opt-in.
Is that reasonable?

The upgrading to DX10+ part would break compatibility with pre-Vista, right?  I 
think
that's too soon.  At least, for me it is =)

Original comment by bram.deg...@gmail.com on 7 Jun 2010 at 7:36