Currently when the usage of surface sharing is broken on certain drivers, be block D3D11 entirely and fall back to Basic composition. There's no real benefit in this case from disabling D3D11 entirely, and we might as well just use it with software composition like we do when we don't have Direct2D, and in addition to that disable texture sharing for webGL, falling back to slow WebGL which again is no worse than the situation when using Basic or D3D9 composition.
This just copies the definition for the documented -[NSView addSubview:positioned:relativeTo:] method, which is the exact counterpart of this (undocumented) method. Using "long long" for the positioned: argument was wrong - the real type is NSWindowOrderingMode, which is typedefed to NSInteger, which is pointer-sized and thus doesn't match long long on 32 bit.
We have to create the websocket if it doesn't exist after enabling
Layerscope. Therefore, we don't have to reboot the device anymore.
1. Remove the Init and DeInit in CreateCompositor and DestroyCompositor
to prevent some unwanted deInits on the browser. (Our browser often
calls DestroyCompositor)
2. Initize websocket only when we need it.
This works around a race condition observed with GENERATED_SOURCES. A
global solution might be to make GENERATED_SOURCES part of the
'export' tier; this is a smaller fix.
--HG--
rename : widget/android/bindings/mediacodec-classes.txt => widget/android/bindings/MediaCodec-classes.txt
rename : widget/android/bindings/surfacetexture-classes.txt => widget/android/bindings/SurfaceTexture-classes.txt
extra : rebase_source : 073dadd8c1b48ea32f975b2232c2bdeafe315ab4
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
