wxWebControl always black (not painted ?)

[catalin]

Hi,

I've added a wxWebControl to an existing app but it is always black. The URIs are being loaded and the proof is the mouse cursor that changes when hovering links and buttons, and even blind select-copy-paste reveals text contents of the loaded web page. So initialization should be ok, but what is preventing the component from being painted!?
The app is very big and cannot strip it down or anything that could actually help. I've put the containing dialog in another simpler app and everything is ok, so it should not be because of the OS, compiler, wxW version. My thoughts are that some events are mistreated in the main app, or the component and this blocks repainting. But what could influence the painting? I couldn't find anything in the code about painting the component...

Win7 64, wxW 2.8.10, VS9.

Thank you,
c

[Aaron]

Hi,

Are you compiling your application in 32-bit or 64-bit mode?

Best,
Aaron

[catalin]

32-bit

[jdx]

Hi, I'm the tech lead on this project. Some more information:

It's a 32bit app running on Windows, I think we both happen to have W7 64-bit but the test app works when compiled, and our custom dialog works fine in one of our applications, but not others.

The only difference we know so far is that the problem app uses Ogre, a rendering library which is using Direct3D to render in a (totally separate) wx window. All other parts of wx are working absolutely fine, except this.

I tried in 3 separate apps of ours which use Ogre, and the same result is found... however they all use some of our shared base-code which cannot be ruled out totally. My next idea is to check compiler/linker settings closely - anything to watch out for?

However, the thought occurs that wxWC might be using DirectX or some more advanced rendering functionality than plain Win32 on our systems, which is conflicting with our use of Direct3D (D3D 9 to be precise).

If anyone can help, it'd be really appreciated as we're a bit stuck proper HTML/JS support would make a big improvement to our app!

[jdx]

Update: It definitely seems to be a D3D issue. I switched our render engine to use OpenGL and suddenly it worked. Sadly this isn't a real solution for us, but I surmise XULRunner is somehow conflicting with our app over D3D usage.

[andy4us]

I have an app which uses DX9 directly, and it is working fine. In fact I have one window which is rendered using DX9 and another window using wxWC on the screen at the same time. It may be an issue how your wx library for DX is initialising DX.

One thing which is tricky is if you are using threads. I have an IPC mechanism which runs in it's own thread, and is used to control the app which is using wxWC. You can't directly call functions for wxWC in the thread of the IPC. You must set events, and allow the events to call the functions you want, as they operate in the main app thread. This is a generic problem with wx and Windows, caught be out a couple of times over the years.

Andy

[jdx]

Andy, your use-case sounds pretty similar to ours - rendering D3D to one window and using a wxWC control in another. We actually use the Ogre rendering engine which handles the DirectX specifics.
Have you tested your software on Windows7 out of interest, or Vista SP1?

Since it's the rendering specifically which is messed up I'm a little unsure how to proceed in terms of threads and such-like, since we're not controlling those calls directly. Do you do anything special when initializing D3D - what do your COM calls look like for instance? And do you init wxWC before or after D3D

Can anyone confirm, that wxWC runs XUL as a separate process? Or does it load DLLs as part of the same overall app?

[jdx]

Update:

I have continued to dig into this, most recently I have tested adding D3D initialization code to the wxWebConnect test-app, and the problem is still reproduced.

I've attached a modified testapp.cpp which can be dropped into an existing project (you'll need to set project include & library paths for D3D if they don't already exist as global VC++ paths - try building and see).

Also attached is a pre-built release EXE. Simply run and press the new "D3D" button to the right of the URL-bar, and you'll hopefully be told it succeeded. Now move the mouse over the loaded web-page and watch as links turn black. Or enter a new URL and watch the whole thing turn black on load.

This problem is really screwing us about, I'd even consider a cash reward or donation to kirix/open-source if someone can fix it!

[MrD]

Wow, that is bizarre.

Since you said you're using Ogre, does the drawing issue still happen if you use their OpenGL render as opposed to their D3D one?

I did a PIX scan on the application, but it didn't actually call any D3D render functions. This is normal since you're not doing any drawing using D3D, just creating the device, however this also suggests that XulRunner isn't using D3D to render itself either. I also did a windows message scan using Spy++, and moving around on the wxWebConnect frame just showed it to be using standard Win32 messaging; all in all it seems that XulRunner doesn't touch D3D (or anything fancy) at all.

[jdx]

Since you said you're using Ogre, does the drawing issue still happen if you use their OpenGL render as opposed to their D3D one?

Nope, it works fine then. But I don't think we can switch to GL, I've seen problems with support on some PCs

I did a PIX scan on the application, but it didn't actually call any D3D render functions. This is normal since you're not doing any drawing using D3D, just creating the device, however this also suggests that XulRunner isn't using D3D to render itself either. I also did a windows message scan using Spy++, and moving around on the wxWebConnect frame just showed it to be using standard Win32 messaging; all in all it seems that XulRunner doesn't touch D3D (or anything fancy) at all.

Good digging around there, thanks - do you know any details how XUL/Gecko is embedded? I tried asking about this issue on the Mozilla mailing list but obviously wxWC isn't something they know about and I have no idea what question to ask!

The wxWC control probably is just win32 as you say but it seems once D3D is initialized, any render screws up... I have no idea how XUL/Gecko actually does its rendering.

I've reproduced this on XP-32bit as well as W7-64bit now, I had a slight thought maybe that might be a factor but it appears rather consistent.

[MrD]

do you know any details how XUL/Gecko is embedded?

No, sorry. I don't.

I had another look to see if there were any calls from an OnPaint event, but wxWebConnect doesn't seem to be handing that at all. I would guess that XulRunner sub-classes the HWND given to it on creation and handles the Win32 messaging internally rather than relying on the embedding code to tell it when to do things.

Just out of chance I added an OnPaint event handler that called m_ptrs->m_base_window->Repaint(true), but that just made the problem worse

[jdx]

One thing which is tricky is if you are using threads. I have an IPC mechanism which runs in it's own thread, and is used to control the app which is using wxWC. You can't directly call functions for wxWC in the thread of the IPC. You must set events, and allow the events to call the functions you want, as they operate in the main app thread. This is a generic problem with wx and Windows, caught be out a couple of times over the years.

I didn't really understand this... anyone care to go into more detail?

[MrD]

One thing which is tricky is if you are using threads. I have an IPC mechanism which runs in it's own thread, and is used to control the app which is using wxWC. You can't directly call functions for wxWC in the thread of the IPC. You must set events, and allow the events to call the functions you want, as they operate in the main app thread. This is a generic problem with wx and Windows, caught be out a couple of times over the years.

I didn't really understand this... anyone care to go into more detail?

In wxWidgets, only the main should mess with UI elements (see this FAQ entry, and the Multithreading overview). This means that if you need to update your UI from another thread, you actually have to have some kind of thread-safe event queue in the main thread that you can post update events to from any additional threads so that the main thread can pick-up the event and do the required UI changes on the main thread (see wxEvtHandler::AddPendingEvent and wxPostEvent).

[jdx]

So do you think this is potentially to blame for the D3D stuff, or does that sound like a red herring to you?

[MrD]

Sorry, I never noticed your reply.

Considering the fact that this can be reproduced using the wxWebConnect TestApp (which doesn't use threading), I'd say quite certainly that threading isn't your issue here.

[jdx]

I'm a bit stuck how to progress here... if I should be chasing the XUL guys at Mozilla or looking into the kirix stuff more.
My understanding is that wxWC launches XUL/Gecko in a separate process, considering XUL is a standalone product in its own right.

[jonmmorgan]

Just to be clear, wxWebConnect does not launch a separate process. It loads the XUL/XPCOM DLLs and works with them in the current process. However, it is also possible that it is working with multiple threads. From memory (having debugged threading problems with Python) the main XULRunner thread can be different from the main process thread.

[jdx]

OK thankyou for that clarification.

[jdx]

I believe I've found the problem: IDirect3D9::CreateDevice() changes the FPU settings by default unless you pass the flag D3DCREATE_FPU_PRESERVE in the BehaviorFlags parameter.

Now what?!

[MrD]

Nice find. I can confirm this fixed your test app on my machine as well, and also from a quick search on Google, that the global overriding of the FPU settings is no longer done in DirectX 10 & 11 due to the issues it caused when using DirectX in non-game situations.

I take it by "now what", you are referring to what to do since you're using Ogre and not DirectX directly?

Well I would think you have two options:

1. Get the Ogre source code, modify it to use the D3DCREATE_FPU_PRESERVE flag and then build it yourself.
2. Raise a bug asking for a render system flag in Ogre to tell DirectX to use the D3DCREATE_FPU_PRESERVE flag.