0
votes

I am working in safari, on top of OSX, using core graphics and I've got a plugin running two threads (main and rendering timer thread). The rendering timer thread invokes "NPN_InvalidateRect" while the main plugin thread handles the corresponding event and redraws itself. However this seems to work differently in safari 32 bit versus safari 64 bit:

  • 64 bit (cocoa event model): requires NPN_InvalidateRect + NPN_ForceRedraw = correct redrawing
  • 32 bit (cocoa if supported, otherwise carbon): NPN_InvalidateRect = correct redrawing however, doing both NPN_InvalidateRect + NPN_ForceRedraw (like 64 bit case) causes flickering image.

Questions:

  1. Is there a better way to force a plugin to render itself, while sticking to native NPAPI, core graphics and support for carbon&cocoa event models.

  2. If not, how can i detect, at runtime, if the browser is running as 32 versus 64 bit application so i can pick which NPN functions of call.

Thanks,

(cross-posted to firebreath, I will post responses in both places)

1

1 Answers

1
votes

First of all, this:

The rendering timer thread invokes "NPN_InvalidateRect"

Is a serious problem, unless you really mean that your rendering timer thread causes NPN_InvalidateRect to be called on the main plugin thread. NPAPI is explicitly not threadsafe, and you are required to call methods like NPN_InvalidateRect on the main thread.

Second, you should really just not call NPN_ForceRedraw. Chromium, Firefox OOP, WebKit2, and almost certainly Safari's OOP mode (which is what you are getting in 64-bit) treat NPN_ForceRedraw as a no-op; the concept of forcing an immediate redraw goes against the whole model of OOP plugins. In all cases you should just call NPN_InvalidateRect, and trust the browser to call you back. In the OOP-plugin world, you should not expect to be able to force the browser to render a plugin at any given moment.