Raitch Posted March 5, 2017 Share Posted March 5, 2017 Currently in my project I've ended up using around 10 ScreenSpaceCanvas2D class and controlling them with the .levelVisible boolean. I'm curious on if this is bad practice or not. Does it drain a lot more from Babylon even though they are hidden? I am currently considering remaking a part of my project to only use 1 ScreenSpaceCanvas2D and have Group2Ds instead for each part with relevant caching. Is that considerably superior to do? Thanks! Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted March 6, 2017 Share Posted March 6, 2017 ping @Nockawa Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 7, 2017 Share Posted March 7, 2017 Ok, if you're brave you can read this document: http://doc.babylonjs.com/overviews/Canvas2D_Overview_Architecture But I'll TL;DR for you: If you have more than one canvas visible at the same time, it should be faster to deal with only one Canvas with x Group2D instead of x Canvas. Why? The Canvas2D library was built to take advantage of the Instanced Array extension of WebGL, to issue the fewest draw calls possible. For instance, if you have several Text2D instances using the same font or BitmapFont, all these instances (inside a given Canvas2D object) will be drawn in one single call. The same apply to Rectangl2D/Ellipse2D with the same kind of Brush2D (solid or gradient, whatever the colors you use): one draw call will be issued for any Rectangle2D instances using SolidColorBrush, whatever the color is used for each instance (i.e. red, blue green rectangles will be drawn in a single Call). Same thing for all instances of Sprite2D sharing the same texture. But this apply to instances inside a given Canvas2D. If you have two instances of Canvas2D, then the calls will be doubled. I hope this is clear enough, tell me if it's not. Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 7, 2017 Author Share Posted March 7, 2017 Makes sense. Will try to use one instead for all Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 I tried grouping up instead of using ScreenCanvases but that caused too many weird behaviors I couldn't make sense of. Feels like transparencies and/or caching overlaps each other or scaling and/or position inside groups instead of screen canvas creates some rather odd behaviors for me. This is through the 2.4 Canvas. Every attempt I've tried with a later version has had even wonkier behavior so far. Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 I'm not sure I understand which version of Canvas2D are you using? The latest preview I've published few hours ago? Best in this situation is to provide a PG example that demonstrate the issue. (but mind that the PlayGround is still no up to date)... Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 I can't provide a PG or the entire behavior right now. If this image makes any sense, it should cover the entire screen and for some reason the .png's transparence goes through the intended blackness behind it. in 2.4 the Canvas covers the entire screen with no transparency bug, but this happens in the hours old version. Have any new measurement become the new standard than pixels? Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 You don't use a CACHE mode for the Canvas ? I mean it's the default one "DONT_CACHE" ? You didn't answered my question about which version of C2D you were using? Try to code/repro in the playground, I can't help you otherwise, or send me the code in private, but PG is definitely better. Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 Looks like I could solve the alpha issue by adding `.hasAlpha = true` to the texture. Wasn't required before but it makes sense. About the scale/sizing, I used to fetch the canvas.width and canvas.height but that doesn't seem to be the max size in the newest versions. How is max width and height of canvas supposed to be calculated? Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 Multiplying `canvas.width` and `canvas.height` by 4 seems to "solve" that as well. Weird, but can't complain about result. Or it seems I can. Having it cover the entire screen by multiplying seems to cause a lot of lag. @Nockawa, do you have an example on how you would calculate something 100% across the screen? How would you calculate a ScreenCanvas or Rectangle to cover the entire screen? It's quite funny. When I try to use `size`, it's 1/4 of actual size. When I try to use `width` and `height`, it's 1/8 of actual size. I can't get the canvas element in Playground either to replicate it. Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 @Nockawa I made a simple playground. It seems to work fine, but I'm pretty sure it's scaled down in the latest release: http://www.babylonjs-playground.com/#DRHQM#0 Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 If you don't specify the size of the Canvas it will cover the whole viewport, I've changed your PG, take a look at these two versions: http://www.babylonjs-playground.com/#DRHQM#1 http://www.babylonjs-playground.com/#DRHQM#2 Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 So how would I position 75% of width? Doing canvas.width * 0.75 gives me less than a 1/4th of the screen in the newest case. Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 I tried using your examples in the Playground but I still only get the lower left corner covered: Can't really tell why the Canvas2D limits itself to only a 1/4th of the screen. The behavior reminds me a bit of the optimize function I experienced problems with before. Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 I'm not sure if it's relevant, but I don't properly add a camera until a couple seconds after the Canvas2D is set up. Could that be a possible cause? I'm trying to recreate it, but Playground requires a camera to be set. Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 explain me what do you need to do exactly, I'll do a quick PG Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 I've made a lot of Canvas2Ds that I have in my game. They work perfectly with size and all in the 2.4 Babylon JS version. When I try the update from today they all get shrinked a 1/4th of the screen for some reason. Most of my Canvas2D design is based on percentage of canvas.width and canvas.height. I want them to be scaled and positioned as they were in 2.4, but maybe I'm missing some essential information since 2.4 which creates this difference? As you see in the 2 above images the entire Canvas2D area is limited to the bottom left corner when they're supposed to be covering 100%. I can bypass this by multiplying canvas.width and canvas.height by 4, but that seems to make it lag a whole lot more. I can't reproduce the behavior in PG which makes me wonder if it's caused by the lack of cameras or something else upon load. I have already built everything and it works as intended of the older version and I don't see why it wouldn't on the newest one. Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 ok, call this and tell me what value you have: engine.getHardwareScalingLevel() Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 I get 4. Doesn't Sounds like a coincidence Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 yep...doesn't sound..... Damn, I thought I had it taken care of! Let me check... Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 engine.setHardwareScalingLevel(1); Wops I meant it sounded like. I tried running above code but it seems the browser went slow of it. Is it some auto balancer to make slower computer run smoother? Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 definitely weid! take a look at this: http://www.babylonjs-playground.com/#DRHQM#3 I set the hardware scaling to 4 after 2sec and change the rect color, and it works... Quote Link to comment Share on other sites More sharing options...
Nockawa Posted March 8, 2017 Share Posted March 8, 2017 Same thing with setting before AND after, still no issue: http://www.babylonjs-playground.com/#DRHQM#4 Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 Is there any more ways I could troubleshoot in my project? I suspect some wonky behavior because I start with Canvas2D before loading and adding 3D stuff. Quote Link to comment Share on other sites More sharing options...
Raitch Posted March 8, 2017 Author Share Posted March 8, 2017 If it matters anyhow I get "4" both before and after the scene and a lot of other stuff is rendered. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.