I have a WEBGL program running on "CanvasA" and I am trying to use "CanvasA" as a texture for a separate program running on "CanvasB".
Looking at Mozilla's docs it appears this can be done by supplying "CanvasA" as the final parameter of the "gl.texImage2D" function.
void gl.texImage2D(target, level, internalformat, format, type, HTMLCanvasElement? pixels);
So I tried doing that, and it works in Chrome & Firefox, Hooray!
However it only shows a blank texture on IOS Safari and Microsoft Edge.
Neither of the latter browsers have any errors in the console, and everything else seems to work. "CanvasA" shows what it should, and the rest of "CanvasB" looks correct, ignoring the blank texture.
The texture on "CanvasB" has it's filtering set to "NEAREST" and no mipmap's are being generated. Also I am using WEBGL 1.
Is this behavior expected? As in are not all browsers required to support using a WEBGL canvas as a texture, or are there any settings I should look for that may be causing the problem?
Related
A premise, in case it makes any difference: I've deleted the CEF folder, since with it the BrowserComponent didn't work for me, and installed the ZuluFX Java 1.8 (with later versions, like ZuluFX 1.11, BrowserComponent didn't work either; this, on a side note, might be related to the same issue that has Cordova when one tries to work with Java > 8).
The problem: using BrowserComponent.setPage with a string, I can create, indeed, programmatically and on the fly, a html page which is properly shown.
When I use an example from BabylonJS (a string containng a html file which loads a cube, loaded as asset, and shows it: the html page -of course- works when loaded in a normal browser) nothing happens, at least in the simulator.
Before to start to make hypothesis (maybe the problem is in loading the cube; maybe in loading the scripts; maybe it can't work in simulators, but will work in the app; etc.) I'd like to know if BrowserComponent is supposed to work with WebGL.
Font "DIN Condensed" letter spacing on ios is huge (exactly one previous letter width extra). This happens with all browsers (Safari and Google) on all ios devices, with original ttf, and with font-squirrel generated woff as well.
How can I fix this?
(Tried so far as well - renaming font-file to .otf)
This is the site: https://itstestlab.eu/
#font-face{font-family:'FontName';src:url('/f/f.woff2') format('woff2'),url('/f/f.woff') format('woff')}
This is the closest I got to importing fonts and having no issues with Chrome, Firefox, IE10, Edge, Safari back to version 5 upwards and iPhone 5S with original iOS, upwards.
It also solved Apple's DRM (copyright protection) issues with other font formats.
I use FontSquirrel to convert fonts into other formats, and also "normalize" them, inlcuding mis-sized, mis-defined glyphs. There are a lot of options, but going the pre-defined "usual" conversion should work.
EDIT: I have looked into your CSS and found that the last rule of /cms/css/cms_normalise.scss applies some non-standard stuff to your fonts. It looks like an overklill of a reset.css. I am not sure if that causes the problem, since I am unable to reproduce it, but you might want to check it out..
Included web version from Typekit CDN and it works from there.
Seems that this is some kind of a copy protection system. The original file client sent to me was for desktop use only.
I get a SecurityError: DOM Exception 18 when rendering textures in Three.js (gl.texImage2D.apply(gl,arguments) ) and the material appears black. I use phonegap 6.2.9 (cordova 6.1.1), Three.js (r78) on iOS WKWebView (platform version 4.1.1).
All worked fine as long as I build the app directly with a WKWebView component, based on this project.
After switching to phonagap I ran into this issue. I supposed it's caused by the Content-Security-Policy, but couldn't solve it this way. Taking images as base64 png is working, but I have multiple large images and the file size is not practical.
Now I fear it's the same issue as with local XmlHttpRequests.
But loading an image from an external Url also causes the SecurityError. And I can't follow, why there is a problem with phonegap/cordova and not with the naked WKWebView component (see above).
I have no idea furthermore and strongly need help please.
Thanks in advance.
You should probably look into CORS if you plan on serving the assets over http.
You need to set a Access-Control-Allow-Origin HTTP header for your assets, see this wiki article for more info:
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
I am using Howler.js on my PhoneGap application. Because my audio files are large (more than 10Mb) im an setting the buffer attribute to true (forcing HTML5 Audio).
var theSound = new Howl({
urls: ['assets/Sound.m4a'],
buffer: true,
sprite: {
scene0 : [ 1966000, 27000] }
When I test my application on the emulator and my iPad Mobile Safari everything works well. But when I run the application on the iPad as an app, the audio never starts. Using the web inspector I have noted that the audio file tries to load again and again like an not ending loop. You can see an attached screenshot of the resources tab on the web inspector both both the emulator and the iPad, running the same PhoneGap app.
Any idea on what could be the problem?
I've been looking into this for a while.
From what I've gathered, Howler defaults to Web Audio API, and this SO answer says you need a "user input event" to make it work on iOS, because by default it mutes everything. I even tried Howler's own interactive demo on my iPad 2 with iOS 5 (I still haven't updated) here and NONE OF THE SOUNDS WORK. My first link has a link to Apple's documentation, and I haven't tried it yet, but it looks like the convenience of Howler has to be replaced with a lower level implementation that takes about 5-10 lines with XMLHTTPRequest (see the Apple link), or another more versatile library. I'm still learning about what exactly I need, but I have a very similar problem I've been working on resolving today.
But then Howler falls back to HTML5 Audio. OK so I'm just googling that now, and this link comes up, and it's just reminding me of the pletora of compatibility considerations between OGG ACC MP3 etc on various browsers vs. browser layout engines vs. operating systems. So I'm left believing your file format M4A, related to MP3 as far as I can tell, isn't working in the target brower on the target iPad OS. I'm not familiar enough yet to give exact specifics but certainly since Howler doesn't work on my iPad that proves there's at least a problem with that.
The whole point I chose Howler to use was to abstract all the above away! I'm going to go look for another more comprehensive library now =D
the problem might be file size. IPad has a limited cache memory size and if you overflow it assets will not work. The only solution to this problem is smaller file size. Another possibility is html audio will not load or play except in a user event (touch). Web Audio will load but starts muted and only unmutes with a play call inside of a user event.
SoundJS is a library I help develop that handles as much of this stuff as possible. In particular I think you would find the Mobile Safe Approach useful. It is well tested on iOS and Android devices. Unfortunately we do not support sound sprites yet.
Hope that helps.
I'm writing an application using as3 and adobe air that loads external SWF files and plays them internally in the application. The container works just fine with android and the animation of the external swf file is very cool.
However, on the iOS (iPad 2), it runs very slow as if its playing only 1 frame per second.
Is there anyway at all to make it play faster.
My application configuration is as follow:
<initialWindow>
<autoOrients>false</autoOrients>
<aspectRatio>landscape</aspectRatio>
<renderMode>gpu</renderMode>
<fullScreen>false</fullScreen>
<visible>true</visible>
<softKeyboardBehavior>none</softKeyboardBehavior>
</initialWindow>
This is the part of code where I load the external swf:
public function set url(value:String):void
{
_url = value;
object.source = File.applicationDirectory.resolvePath(value).url;
object.addEventListener(Event.COMPLETE , onLoaded);
}
protected function onLoaded(event:Event):void
{
object.addEventListener(Event.ENTER_FRAME, onEnterFrame);
}
protected function onEnterFrame(event:Event):void
{
if((object.content as Object).currentFrameLabel == "stop")
(object.content as Object).stop();
}
I also tried to comment the Enter frame event listener but nothing changed.
Thanks in advance.
Edit:
I figured out something that is very strange actually. When I run the application from the application with the Fast configuration, it runs fast. But when I publish it or use the Standard option while running it runs really slow.
Tested with AIR 3.2
try setting your render mode to direct:
<renderMode>direct</renderMode>
Remember, when you are rendering exclusively to the GPU, it will slow things down if you are rendering animations. Although rendering to the GPU is fast, allocating Video Memory to the GPU is slow. If you render exclusivity to the GPU, on every frame, the video memory will need to be updated.
Another thing is that all vectors will be rasterized so some things will render pixelated.
A couple of things:
You aren't allowed to load SWFs that have any code in them, in AIR for iOS. This is forbidden by Apple.
You should only use swf at most as a library of graphics / resources when compiling for iOS. If a movieclip inside has stop(); on one of the frames, then this counts as an 'addFrameScript()' under the hood, which means that SWF contains ActionScript.
I suggest if you need functionality as such, create a list of predefined behaviours to be compiled into your main app, then run these behaviours based on the type or name of asset you are instantiating from your SWF library, attaching them at runtime.
Besides, if you are doing this to allow updates -- or the ability to modify the app, post-release, then you may as well compile it into the release build, and just republish next time you want an update to the app. This will help your ranking in the app store to some extent, and remove a lot of versioning issues down the line.