Re: Windows GTK+ 2.24.10: Cairo contexts not rendering to surface

[Jeffrey Sheen <jeffrey.sheen00@xxxxxxxxxxxxxxxxxxxxx>]

This behaviour is a result of an incompatibility between the Direct3D 9 API (DirectX SDK March 2009) and Cairo Graphics API (1.10.2).

The following mailing list thread from 2006-10-16 details how creating a Direct3D 9 device alters the FPU to single-precision mode, and that this version of the Cairo API assumed a higher level of precision when making its colour calculations:

http://cairo.cairographics.narkive.com/L9XYWFkQ/cairo-direct3d-interaction-bug-and-fix-x86-fpu-precision

A fix for this bug was introduced immediately:

https://bugs.freedesktop.org/show_bug.cgi?id=7497

Cairo v1.10.2 was released 2010-12-25, which postdates this fix by 4 years, but the erroneous behaviour is still present.

However, the fix must have made it into the Cairo code base at some point, as there is no evidence of the bug in Cairo v1.14.6, which can be downloaded from the HexChat project:

https://github.com/hexchat/gtk-win32

A massive thank you to the mystery friend who used their search-fu to find the original thread concerning the Cairo bug.

On 1 February 2017 at 17:38, Jeffrey Sheen <jeffrey.sheen00@xxxxxxxxxxxxxxxxxxxxx> wrote:

N.B. I have removed the original Stack Overflow question, and created a new question with this new information:

http://stackoverflow.com/questions/41986105/idirect3d9createdevice-prevents-gtk-2-cairo-rendering

On 1 February 2017 at 17:10, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk> wrote:

After trying different VS 2015 Solution configurations (and abundant breakpointing), I have established that it is not the .EXE->.LIB->Cairo API call structure that is breaking Cairo surface rendering in my project.

The black test square can be rendered before, but not directly after, this D3D9 API call:

Direct3DCreate9(D3D_SDK_VERSION)->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, WindowHandle, D3DCREATE_HARDWARE_VERTEXPROCESSING, &PresentParameters, &PDevice);

N.B. The object parameters are as follows:

WindowHandle 0x001b07f8 {unused=13111204 } HWND__ *

unused 13111204 int

PresentParameters {BackBufferWidth=0 BackBufferHeight=0 BackBufferFormat=D3DFMT_UNKNOWN (0) ...} _D3DPRESENT_PARAMETERS_

BackBufferWidth 0 unsigned int

BackBufferHeight 0 unsigned int

BackBufferFormat D3DFMT_UNKNOWN (0) _D3DFORMAT

BackBufferCount 1 unsigned int

MultiSampleType D3DMULTISAMPLE_NONE (0) _D3DMULTISAMPLE_TYPE

MultiSampleQuality 0 unsigned long

SwapEffect D3DSWAPEFFECT_DISCARD (1) _D3DSWAPEFFECT

+ hDeviceWindow 0x001b07f8 {unused=13111204 } HWND__ *

Windowed 1 int

EnableAutoDepthStencil 0 int

AutoDepthStencilFormat D3DFMT_UNKNOWN (0) _D3DFORMAT

Flags 1 unsigned long

FullScreen_RefreshRateInHz 0 unsigned int

PresentationInterval 0 unsigned int

PDevice 0x00000000 <NULL> IDirect3DDevice9 *

+ IUnknown <struct at NULL> IUnknown

As a reminder, the code for rendering the black test square is as below, and the status of each Cairo API call returns "no error has occurred":

cairo_surface_t *surface;

cairo_t *cr;
cairo_status_t status;

surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 390, 60);
status = cairo_surface_status(surface);

cr = cairo_create(surface);
status = cairo_status(cr);

cairo_set_source_rgba(cr, 0, 0, 0, 1);
status = cairo_status(cr);

cairo_rectangle(cr, 175, 10, 40, 40);
status = cairo_status(cr);

cairo_fill(cr);
status = cairo_status(cr);

cairo_surface_flush(surface);
status = cairo_surface_write_to_png(surface, "f:\\cairo_test_pos_lib_member_function.png");

cairo_destroy(cr);

cairo_surface_destroy(surface);

Can anyone suggest how to proceed from here?

Cheers,

Jeff.

On 27 January 2017 at 11:07, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk> wrote:

Thanks for taking a look Eric.

The status value after all of the Cairo API calls are all "no error has occurred", in both the EXE implementation and LIB implementation, so no information there.

I noticed this output during the execution of the EXE:

'Loaded 'F:\filestore\development\gtk+\gtk+-bundle_2.24.10-20120208_win32\bin\libcairo-2.dll'. Module was built without symbols.

'Loaded 'F:\filestore\development\gtk+\gtk+-bundle_2.24.10-20120208_win32\bin\libfontconfig-1.dll'. Module was built without symbols.

'Loaded 'F:\filestore\development\gtk+\gtk+-bundle_2.24.10-20120208_win32\bin\libexpat-1.dll'. Module was built without symbols.

'Loaded 'F:\filestore\development\gtk+\gtk+-bundle_2.24.10-20120208_win32\bin\freetype6.dll'. Module was built without symbols.

'Loaded 'F:\filestore\development\gtk+\gtk+-bundle_2.24.10-20120208_win32\bin\libpng14-14.dll'. Module was built without symbols.

'Loaded 'F:\filestore\development\gtk+\gtk+-bundle_2.24.10-20120208_win32\bin\zlib1.dll'. Module was built without symbols.

Only the GTK+ DLL files are reported as missing symbols, where others have theirs loaded. Is it possible that the dynamic linkage is broken for API calls made from the static LIB because of this?

On 26 January 2017 at 18:47, <cecashon@xxxxxxx> wrote:

Hi Jeffrey,

I am probably not much help here. Your code works on Ubuntu16.04 and GTK2.24.30. It does seem strange that there isn't an error popping up someplace. Have you tried getting the status of that function to see if it returns an error?

    cairo_status_t status;
    status=cairo_surface_write_to_png(surface, test_dir);
    g_print("%s\n", cairo_status_to_string(status));

Maybe it might offer a clue to what is going on.

Eric

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list