Window-relative coordinates in NPWindow
stuartmorgan at chromium.org
Mon Feb 21 20:23:56 PST 2011
Le 20 février 2011 21:50, Simon Fraser <simon.fraser at apple.com> a écrit :
> To this end I'd like to see NPWindow and NPP_SetWindow deprecated, or
> changed to not make use of window-relative coordinates.
Mac Chrome essentially already did the latter, and it hasn't caused
any problems. All plugins are told that they are at 0,0, so all other
coordinates they receive are plugin-relative.
For the Cocoa event model this works out well because there's no
reference to a window. Under the Carbon model this doesn't work unless
you are providing a dummy window (or simulating one through
interposing), because event handling requires plugins to do a manual
global->window then window->plugin transformation themselves. (Yes,
NPN_ConvertPoint could do that too, but NPN_ConvertPoint was
introduced with the Cocoa event model, so doesn't really apply to
these plugins). Under QuickDraw it's particularly bad since it also
So from the Mac side deprecating a core plugin method and spec'ing a
new one just for clipping seems like overkill; it would suffice to put
a comment in the header and/or the Cocoa spec noting the reality that
browsers may always provide 0,0 for the Cocoa event model. Carbon is
deprecated anyway, so if the origin is only meaningful for Carbon then
it becomes deprecated by default.
If we're talking about all platforms, we'd probably need to start by
having a clearly spec'd, cross-platform description of what
NPN_ConvertPoint is supposed to do. Currently the constants seem very
Mac-oriented, and the exact behavior is not spec'd anywhere as far as
I know (it seems to have snuck in as part of the Cocoa event model). I
had to reverse-engineer it in order to implement it in Mac Chrome, and
it's not implemented on any other platform.
More information about the plugin-futures