I am using FireBreath 1.7 building a plugin for Safari 6 (and up) running on Mac OS X 10.8.5 (and up). The purpose of the plugin is to display video.
I have so far implemented support for CoreGraphics and CoreAnimation drawing models following the FireBreath example BasicMediaPlayer.
Performance is significantly better with CoreAnimation (which I implemented in OpenGL), and therefore my preferred choice.
The problem is that when using CoreAnimation, the plugin does not appear to honor the z-index, it just paints over everything. This is an issue because I would like to style my plugin video element (e.g. rounded borders).
I am aware of this post from 2012 (by one of the main authors of FireBreath), which basically confirms this being a limitation of CoreAnimation.
However, according to this article this should no longer be a limitation for NPAPI plugins in Safari 5 and up:
One caveat is that Safari 4, and Chrome up to at least Chrome 10, do not composite Core Animation plugins correctly. For those of you coming from a Windows or Linux NPAPI background, it's akin to windowed-mode plugins, drawing above all web content regardless of z-index. If that's deal-breaker, you'll need to use CoreGraphics and do a readback from an off-screen OpenGL buffer. Hopefully this will be fixed within a couple more releases of Chrome (it already works in Safari 5).
Which leads to my question: Does anyone know whether it is possible to achieve proper windowless behavior in FireBreath based plugins using CoreAnimation in newer Safari browsers on Mac?
Related
I am working on a project where we have a Mac desktop application that has an NPAPI based browser plugin that can be used to edit it's documents through a browser. The codebase is a mixture of Carbon and Cocoa UI code that is shared between the app and the plugin.
We've recently enabled retina support in the app by turning on the High Resolution Capable flag in the application plist and are in the process of porting the interface over to Cocoa. In the app things are displaying correctly with retina displays but in the plugin none of the windows are drawing in high dpi mode.
The document displayed in the browser window is drawing correctly as I can get the content scale factor using NPNVcontentsScaleFactor and apply it to the layers. The problem is with the extra windows that we create, dialogs and toolbars, which are not being drawn in high dpi mode.
Is there a way to get windows we create in the NPAPI plugin to draw at the high resolution?
Thanks.
I unsuccessfully searching for Unity3D plugin what implement WebViews for OS X and (optional) iOS, which contains events (such as page load complete, process link etc.).
I have tried:
uniwebview.onevcat.com (only mobile platforms)
https://github.com/gree/unity-webview (no events)
awesomium.com (it is good, but very hard for commercial use)
May be is exist another appropriate solutions?
uWebKit is an HTML5 WebView for Unity Pro on Windows and OSX: http://uwebkit.com/
I prefer google chrome in almost every way above IE10, but one thing I hate is that fonts just look much better in IE10. This especially visible with small math fonts. They look like pdf quality in IE10.
After searching a little bit, I found out that this is because IE10 use DirectWrite in windows 7/8 for font rendering. I was searching if chrome will support this in the future and I found this information:
Apr 24, 2013:
An update for everyone that's watching this one:
Our Windows font rendering is actively being worked on. Basic support
for DirectWrite is now in Skia (to update from comment #13). At the
same time, GDI was very deeply embedded in the Windows WebKit port and
is still being rooted out. We hope to have something within a
milestone or two that developers can start playing with. How fast it
goes to stable is, as always, all about how fast we can root out and
burn down any regressions.
We'll update the thread here when it's available behind a runtime flag
for y'all to try out.
Oct 8, 2013
The following revision refers to this bug:
http://src.chromium.org/viewvc/blink?view=rev&rev=159071
Changed paths: M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/skia/FontCacheSkiaWin.cpp?r1=159071&r2=159070&pathrev=159071
M
http://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in?r1=159071&r2=159070&pathrev=159071
Add runtime flag for using DirectWrite on windows
Add runtime enabled feature for using the DirectWrite skia backend on
windows.
BUG=25541 R=bungeman#chromium.org, eseidel#chromium.org
Review URL: https://codereview.chromium.org/26335002
I don't even know what a runtime flag is, but this sounds to me that it may be possible to somehow enable directwrite in chrome. Is this true ? Or should I wait a little longer before I can use directwrite font rendering in chrome ?
Sadly not yet (as of 2013-10-31, no Chromium channels supports this feature out-of-the-box).
If you look at the latest RuntimeEnabledFeatures.in, DirectWrite doesn't have any status assigned to it. According to Blink document, users cannot enable a feature via about:flags unless status=experimental is assigned.
But hopefully soon, so windows users may have a better time with web fonts :)
Update 2013-11-16: with latest issue 25541 comment, it seems we are very close to be able to enable DirectWrite in Canary.
Update 2014-01-04: Canary build now has a command line switch that can enable DirectWrite font rendering, but disabling sandbox mode are required (not safe for everyday browsing). There are also a few font rendering problem associate with it. Hopefully they can get them fixed and add this feature to about:flags soon.
Update 2014-05-09: latest Canary build (m36) now has proper support for DirectWrite within sandbox mode (implemented via issue 333029), which means developers can enable DW directly by going to about:flags#enable-direct-write. As for consumers, Google is targeting release on m37.
Update 2014-08-09: Chrome 37 beta enables DirectWrite by default, expect Chrome 37 official release to have it by default as well.
Update 2014-08-31: Chrome 37 stable release has DirectWrite enabled by default! Just note that users can still turn it off at about:flags (some of them use MacType instead).
Chrome 35 (beta) comes with an option to enable DirectWrite for Windows font rendering. Paste the following command in your address bar and click enable:
chrome://flags/#enable-direct-write
Reference: http://www.reddit.com/r/web_design/comments/22q9r9/chrome_35_beta_has_finally_fixed_windows_font/
It's currently in development for chrome on windows.
http://www.chromestatus.com/features/4725550652325888
Update: on August 26, 2014, Google updated the stable version of their Chrome browser to version 37.0.2062.94 on Windows, OS X, and Linux. With this release, Chrome move from Microsoft's Graphics Device Interface rendering method to Microsoft's DirectWrite text rendering API. Switching to DirectWrite has been requested for years by users on Windows, and Google has stated that it took significant rewriting of their font rendering engine which is why it has taken so long.
It's in Chrome as a flag as of 33 (and as of this time of writing), however from what I understand you still need to run it with the sandbox disabled via the command line --no-sandbox. This is not a recommended action for everyday use. You can enable the rendering flag, but it will only change if sandboxing is disabled.
(I would have added this as a comment to #chickenbooze, but I've switched SE accounts and don't have enough reputation yet :)
NPAPI in MacOs gives me CGrafPtr in NPWindow structure, I need a WindowRef.
Is there a way to get WindowRef from CGrafPtr ?
Thanks!
NPAPI only gives you a CGrafPtr if you are using the very, very deprecated QuickDraw drawing model (with Carbon event model). Writing a new plugin using the QuickDraw model would be a terrible idea: Firefox 64-bit doesn't support it, Safari 64-bit doesn't support it, and Chrome doesn't really support it (and soon won't at all). Your plugin wouldn't work for most users.
Instead, you should be using either Core Animation (drawing) + Cocoa (event), or CoreGraphics + Cocoa. In the Cocoa event model there is, deliberately, no way to get a reference to the browser window. Modern browsers almost all run plugins in a separate process, and you can't reference windows across processes.
In short, if you are trying to make a new NPAPI plugin that requires access to the browser window, your design is wrong.
I just upgraded my mac to Firefox 3.6, and now neither of my TIFF Viewing plugins work.
in 3.5, If I had Quicktime on, then I'd get the tiff, viewed through quicktime. If I had Quicktime disabled, but my own plugin, AcellViewTIFF enabled, then I would get ViewTIFF viewing the TIFF. Since I'm the author of ViewTIFF, That's how I had it most of the time.
After I upgraded to 3.6, if ViewTIFF is enabled, I just get a blank space. if ViewTIFF is disabled, no matter whether or not Quicktime is enabled, it goes straight to preview.
Has anyone seen this?
(This is programming related because I'm writing AccelViewTIFF, and if the framework for plugins changed, I need to fix it...)
Edit to add:
This is an NPAPI plugin, I've removed or commented out the main, so I don't think that this is a CFM plugin problem.
I looked at Mozilla's "basicplugin" (located in mozilla-1-9-1-f15a2686e9a6/modules/plugin/sdk/samples/basic/mac under the standard mozilla source) and it works. I compared all of my functions to the functions in BasicPlugin, and the only function that it has that I don't is the drawPlugin function, which appears to do the actual work. All equivalent functions have the same interface.
When I remove or disable AccelViewTIFF, Firefox downloads the image and gives it to preview. When I enabled it it does nothing. This tells me that Firefox IS seeing that I have a plugin, but it's not running it for some reason.
There are no errors either in Firefox's error console or in any of the console logs I can see...
any ideas?
For the record, the problem was that this is an OLD plugin that still uses Quickdraw routines. evidently, they didn't make it into 64b, and so they don't work in FF 3.6.
Lets hear it for progress.
Are you using Leopard or Snow Leopard?
TIFF files open fine with the QuickTime 7.6.3.0 plugin with Firefox 3.6.
Go to Firefox -> Preferences -> Applications. Search for "tif" and then you can choose how Firefox handles files with the image/tiff MIME type. Set it to the plugin of your choosing. QuickTime should work (is for me on Snow Leopard).