[cairo] Problem with cairo in windows
vladimir at pobox.com
Fri Apr 24 17:09:13 PDT 2009
Ah, Direct3D strikes again. I didn't realize that pixel toaster was
using direct3d at all, because we've run into that same problem all over
the place. For what it's worth, D3D seems to work fine with
FPU_PRESERVE. There's a pretty significant performance gain -- there's
actually no instability, the results of the conversion are perfectly
defined assuming IEEE floating point representation and semantics.
However, that's exactly what gets killed off when D3D puts the FPU into
"go fast at any cost" mode, and so the conversion fails.
We should probably put a check in cairo somewhere, maybe on every
cairo_t creation, to do a single double->fixed conversion with a known
result and verify that it's correct.. otherwise set an error.
On 4/24/09 2:21 PM, David Larsson wrote:
> Okay, I built cairo from source to figure out what went wrong.
> After some debugging I realized that the double to fixed point
> conversion always returned 0 if I had initialized pixel toaster before
> starting drawing.
> The problem lies in a combination of the function "static inline
> cairo_fixed_t _cairo_fixed_from_double (double d)" and the fact that
> windows changes some floating point precision flags when initializing
> a direct 3d device.
> Since the function relies on some shaky floating point math it
> suddenly stops working when computations are done with lower accuracy.
> These are some workarounds:
> Hand in the parameter D3DCREATE_FPU_PRESERVE as a behavior flag to the
> function CreateDevice when creating the d3d device. This however comes
> with this disclaimer:
> "Portions of Direct3D assume floating-point unit exceptions are
> masked; unmasking these exceptions may result in undefined behavior."
> It might be possible to do this more fine grained since I'm not
> interested in masking exception, but making sure the full precision is
> The other workaround was to change how the fixed point conversion is done to:
> return (int32_t)(d * 256.0);
> Anyway, has anyone benchmarked what performance gain you get with the
> unstable double to int conversion recently?
> It might be time to change to something more stable unless it really
> makes any difference.
> On Mon, Apr 20, 2009 at 10:28 PM, David Larsson<laserallan at gmail.com> wrote:
>> Cool, I didn't know about pastebin.
>> Here it is:
>> It's based on an example called stars.c which renders some stars, the
>> lines breaking the rendering is 50 and 51.
>> My speculation, which might be completely wrong, is that there is some
>> kind of hardware acceleration going on when rendering stuff in
>> windows. This stuff is somehow dependent on some kind of device handle
>> or so, that is affected by pixel toaster when it creates windows and
>> initializes direct x devices making it stop rendering properly.
>> On Mon, Apr 20, 2009 at 8:52 AM, Gerdus van Zyl<gerdusvanzyl at gmail.com> wrote:
>>> It would be useful to see your code, could you post it to a pastebin?
>>> On Sun, Apr 19, 2009 at 11:27 PM, David Larsson<laserallan at gmail.com> wrote:
>>>> I have a silly problem with Cairo for windows, that you might be able
>>>> to help me to figure out before I start doing some serious debugging.
>>>> I'm trying to use cairo to render to a image buffer that I want to
>>>> display on in a window using pixel toaster
>>>> (http://www.pixeltoaster.com/) which is a minimalistic cross platform
>>>> framebuffer library.
>>>> The rendering works perfect as long as I don't open a screen with
>>>> pixeltoaster, but only output the image as a png.
>>>> However, when I create a pixeltoaster display it seems likes cairo
>>>> just stops drawing. I've verified that not only my screen but png
>>>> output of the image rendered is black.
>>>> Can anyone see why a bunch of window creation code and directx 9
>>>> object creation code could make cairo stop drawing?
>>>> I'm getting no indication of errors by failing function calls etc.
>>>> I'm using the windows build of cairo 1.8.6 from gtk+ from
>>>> http://www.gtk.org/download-windows.html as suggested on
>>>> I know this is difficult to debug without all code in front of you,
>>>> but I just want to check if someone can see any potential problem here
>>>> before I build cairo from source code to be able to debug what's
>>>> actually going on.
>>>> Thanks in advance
>>>> cairo mailing list
>>>> cairo at cairographics.org
> cairo mailing list
> cairo at cairographics.org
More information about the cairo