3D rendering plugin - Windowed or Windowless?

[John Dexter]

For something used for real-time 3D rendering (D3D, OpenGL) like the Unity web-player plugin, is there an obvious choice here?

[Andrian Nord]

On Sat, Jan 22, 2011 at 09:56:27PM +0000, John Dexter wrote:
> For something used for real-time 3D rendering (D3D, OpenGL) like the Unity
> web-player plugin, is there an obvious choice here?

You probably don't want to use supplied window, as it will not allow you
to process events correctly (you may try, though). I've got to XEmbed
windowing. In general it means - you create your own window, that is
under your full control, but it's parent should be browser-supplied
window. Don't know if it works on Windows, but for X11 it's a nice way to
go.

[Richard Bateman]

You should be able to get the events pretty much the same way, at least those you're concerned about. However, there is some serious question as to whether or not you can successfully initiate a D3D or OGL context in a windowless plugin. Anson's experiments (just in FireFox/win so far) seem to indicate that the only way to do this with a windowless plugin is to render off-screen and then blit it to the screen using GDI.

With a windowless plugin you only get a HDC, and it is not guaranteed to remain the same each time RefreshEvent is fired (which is the only time you're allowed to draw), just that when you get it you'll be able to draw to the HDC that the PluginWindowless object has at that point with the window sizes that it has.

Note that we still lack windowless support on Linux for the simple reason that I haven't a clue how it would work...

Richard

[John Dexter]

Richard, I think that leaves our decision pretty much cut & dried - I have no desire to do the research to get it working, unless we find substantial reasons a Windowed plugin is not adequate!

Thanks!

[Kamcheung Sham]

Hi folks,

I've a plugin that sends events back to JS. I use the registerEvent() calls in my JSAPI constructor. On the JS side, I've code that register the callback method to the events. Pretty much copy from the examples, where 'obj' is the plugin object element. I added to alert to make sure the handler is added successfully to the plugin object.

function addEvent(obj, name, func)
{
if (window.addEventListener) {
obj.addEventListener(name, func, false);
} else {
var res = obj.attachEvent("on"+name, func);
alert("Added 'on'" + name + "' handler. result = " + res);
}
}

It works on most windows browsers, but there is one client machine where it doesn't work on an IE7 with Win7 64bit. In that case, the event handlers are never triggered. From the plugin logs, the plugin performed all the functions that are requested and the logic to call FireEvent() were being invoked.

Any ideas in what would prevent events from triggering the handlers in IE?

Thanks,
kam

[Richard Bateman]

something to try that I've seen be a problem in IE7 before; put the addEvent call in a setTimeout of 500ms or so, see if that makes a difference.

Sometimes IE isn't real transparent as to how soon it will let you start using the plugin.

My thinking is that maybe you think you're attaching an event but actually it's being silently lost because you're doing it too early in the initialization (which shouldn't be possible, but that's IE for ya)

Richard

[Kamcheung Sham]

We set the event handler call way after the plugin is loaded asynchronously. The calls to addEvent() also return true. I noticed that not all Vista or IE7 failed. But it's consistently failing on specific machine.

I also tried a few different addEvent() implementation out there, and using prototypes to do $('pluginElement').observe() etc. None of the other mechanism works for me at all in any platform.

kam

[Richard Bateman]

How are you doing your install? Is there anything unusual about that machine that you can think of?

Without being able to reproduce this it's really hard to track it down; when you call attachEvent are the ConnectionPoint methods in JSAPI_IDispatchEx.h getting called?

One thing to try that I have seen before is that sometimes if the registry gets messed up somehow you may need to search for and remove all references to any of the 6 CLSIDs from PluginConfig.cmake and then try installing again.

:-/

Richard

[Richard Bateman]

This seems unlikely to have affected your issue, but there was an issue in IE with using "traditional" js event registering (i.e. plugin.onload = someFunction) which is now fixed in 1.4b4

Could you try that and let me know if it makes a difference in your case?

Otherwise I'm at a loss as to how to help you. If someone experiencing the IE event issue could give me remote access to a box, I could maybe track it down that way. If I can't see it, though, it's really hard to figure out what might be happening :-/

Richard

[Kamcheung Sham]

I'll try b4. It seems to be more like a Vista+IE7 issue. I've seen this on a couple of machines (both belongs to my client). Then I got a Vista install disk and created a fresh VM of it, the VM works. To recap, this is how the plugin is started:

1. <object> tag of the plugin is written to a <div> dynamically through prototype element update call.

2. <object> tag contains <param name="onload" value="pluginLoaded" />.

3. After plugin is loaded, event handlers are added to custom events by the attachEvent() or addEventListener() calls.

4. Application calls into plugin. Execution is handled asynchronously. Call is returned immediately.

5. After processing the request, plugin fire event by calling FireEvent("onsomethingdone", FB::variant_list_of()).

The 'pluginLoaded' method is invoked in all cases after the plugin is loaded, even for the Vista+IE7 that is not invoking my custom event handlers of 'onsomethingdone'.

Will report when I found the issue.

thanks,

kam

[Yom]

I call a (fake) DetachEvent just before AttachEvent and this seemed to help in some cases. This combined with a timeout solved my problem after experiencing similar issues on IE/W7 x64.