• Content Count

  • Joined

  • Last visited

  • Days Won


AshleyScirra last won the day on June 12 2014

AshleyScirra had the most liked content!

About AshleyScirra

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Location
    London, UK

Recent Profile Visitors

1191 profile views
  1. If Opus is now mandated in WebRTC, all modern browsers already have to ship an Opus decoder, right? So could the standard now also mandate Opus for <audio> / Web Audio? Would there still be opposition based on the WebM container?
  2. Hi all, As discussed on our call today, I said I'd bring together a list of bugs I've filed relating to the quality of the web platform (i.e. the kinds of things causing developers headaches when they run in to them). To get the ball rolling, here are a few. Please feel free to add your own, but I think we should try hard not to throw in our full bug lists - I for one have quite a few filed over the years! Let's try to keep this focused on things which will affect web development in general, cross-platform gotchas, and the like. Chrome OffscreenCanvas works in Chrome, but is not supported in the WebView: Audio playback sometimes has unexpectedly high latency on Android: WebView performance is sometimes unexpectedly worse than in Chrome. It's a difficult issue to track down and it's not clear what the cause is or if there are multiple causes, but two issues related issues are and Sometimes we see GPU driver crashes, e.g., and it seems really hard to get the graphics vendor to respond or act on it Firefox Options for createImageBitmap aren't implemented (or fully implemented - hard to tell from the tracker) - related issue: issue 1367251. It's useful for preparing textures for WebGL upload, but because of this you have to deal with three paths: no ImageBitmap (current Safari), ImageBitmap but no options (Firefox), ImageBitmap with options (Chrome) You can't draw an SVG to a 2D canvas, even with the overload that specifies the width and height: issue 700533 Support for OffscreenCanvas: issue 1390089 Safari createImageBitmap (issue 182424) and options (issue 202458?) Safari is the last browser that does not support WebM Opus audio. This is the sole reason we have to use dual encoding or ship our own WebM Opus decoder with the game. If they supported this, we would at last have one audio format that plays in all browsers. Issue 183852 We find pretty much every iOS release breaks something. Here's the latest in our case - switching tabs breaks audio playback in iOS 14: issue 217606 Support for OffscreenCanvas: issue 183720 Support for WebGL 2: issue 126404 - seems to be on the way though, latest tech preview enabled it!
  3. You should run a web server for testing. For security reasons, some browsers treat files on disk as if each file came from a different domain. CORS (Cross Origin Resource Sharing) is the security mechanism that allows resources from different origins to be used, but the default is that resources from other origins are blocked (hence "blocked from loading by Cross-Origin Resource Sharing"). The easiest way around this is to test with your own local server, and the browser will understand that everything comes from the same origin. If you don't run your own server you will continually run in to problems with images, audio, video and more.
  4. IE and Edge support MPEG-4 AAC. Construct 2 games have used it for a long time for IE support. You probably did not encode the audio correctly.
  5. This is terrible. iOS 9 appears to basically break all existing content using Web Audio. I found an existing WebKit bug for this and posted more information in it including test cases: Please vote/comment on it to raise awareness! I found a workaround (which will be integrated in to the next Construct 2 release). Unblocking the Web Audio API has typically been done in touchstart like this: document.addEventListener("touchstart", function (){ if (had_touch) return; // play empty buffer to unmute audio var buffer = context.createBuffer(1, 1, 22050); var source = context.createBufferSource(); source.buffer = buffer; source.connect(context.destination); source.start(0); had_touch = true;});Now you need to do that in a touchend event instead, and it works again. However, all content ever published using this technique needs to be updated! Safari should definitely be fixed.
  6. It's really about saving memory. Some GPUs only support square power-of-two textures (although I think this proportion is falling over time). If you make a 513x513 image, it could be bumped up to a 1024x1024 texture for storage and waste memory. Some WebGL 1 features like mipmapping and tiling also only work for power-of-two textures, although this restriction is lifted in WebGL 2.
  7. To do this properly, the browser needs to schedule requestAnimationFrame calls at half v-sync rate, which it's not currently possible to do - but Google are interested in supporting it:
  8. This is hardware-specific, not a blanket issue that always affects IE. All browsers have hardware blacklists, and if your graphics drivers are known to be unstable, it turns off WebGL support. Some browsers (IE, Chrome on Windows) actually fall back to a software-rendered WebGL implementation in this case so content can keep working, but slowly. If you're rendering a 2D game, canvas2d is likely faster. So for this case you can pass the "failIfMajorPerformanceCaveat": true parameter to the context attributes when you're getting your WebGL context. Browsers quite rightly consider a software renderer as a "major performance caveat", and will fail to return a WebGL context in that case. Then your code can fall back to canvas2d, which may still be GPU-accelerated. I don't know if Pixi does this, it sounds like it doesn't and it really should, but that's how the C2 engine works.
  9. Visit chrome://gpu in Chrome and it will tell you what features are hardware-accelerated. If a feature isn't hardware accelerated and there's no OS update for your phone, there's not a lot you can do other than change the flags in chrome://flags to force hardware acceleration, or just use a different browser...
  10. I assumed you were using the canvas2d renderer. I'm not sure why drawImage would turn up in a profile for a WebGL renderer? It's a canvas2d function.
  11. Actually based on our work on Construct 2's engine, if you're using the canvas2d renderer with a large number of small sprites, drawImage will tend to bottleneck on the CPU before the GPU. Every single drawImage call requires a relatively expensive transition from the JS engine back in to native code, and then when it returns a transition back from native code to the JS engine again. For maximum performance you need to use a WebGL renderer, which with a well-written batching engine can submit hundreds or even thousands of drawImage-equivalents in just a handful of calls, minimising the JS-to-native CPU bottleneck. I don't know much about Phaser or PIXI, but for this reason they should render with WebGL by default. Why are you still using canvas2d?
  12. I don't think it's a fair test. This type of test is extremely difficult to write fairly. Your C++ code mostly uses ints, but there is a sqrt call. sqrt takes a float and returns a float but you pass it an int and assign the result to an int, so you have explicitly introduced an int->float conversion followed by a float->int conversion. These conversions can be surprisingly slow, I remember seeing Visual C++ call a helper function to do the conversion for standards compliance reasons, and the helper function could come up high in profiles. Javascript does not have typed variables. Numbers are specced as doubles (there are no other number types in the language!) but optimisers are allowed to use other types for optimised code based on runtime profiling. Although you may expect/intend i_sqrR to be an integer, the JIT can probably see it's faster to leave it as a float. I'm simply speculating, but the JIT may propagate that to making the loop indices both floats as well, and then there is never any type conversion necessary. So the JS code does not have to do some of the work the C++ code does - it can probably figure out how to circumvent the conversions entirely. The JIT may also take advantage of CPU features it identifies are supported at runtime, e.g. SSE4, whereas compiled code may conservatively fall back to something like SSE2 for widest hardware support. The JIT might also have a better opportunity to auto-vectorize the code since it can observe it running. For the same reason it may be able to generate more efficient branching code by identifying hot/cold paths at runtime, like profile-guided optimisation in C/C++. I don't think this particular test is comparing apples to apples. But it is true that very carefully written JS, using knowledge of how the JIT will examine types, can be approximately as fast as native code in some cases.
  13. The solution is batching, which is like you say: write a single buffer and pass it to drawArrays, or better yet drawElements, in one go. If you keep calling uniform4f followed by drawing a single triangle, that is still very inefficient. If the colors really change for every triangle, you should create a new buffer for colors, and feed that in to the vertex shader. Then you can simply fill the buffers and make a single draw call again. Basically every WebGL call has a performance penalty, so try to get it down to a fixed set of calls every frame, even for a variable amount of content to draw.
  14. Yep, NW.js does this for Construct 2 and it's the best I've found.
  15. I just checked, and an empty Construct 2 project exported and zipped excluding the optional icons is 79kb.