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.shee...@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, <cecas...@aol.com> 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@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
