ZYandu

Members
  • Content Count

    39
  • Joined

  • Last visited


Reputation Activity

  1. Like
    ZYandu reacted to ivan.popelyshev in Performance Tips for Large-scale 2D graphing   
    >  ~100k Nodes/Edges
    Its not easy to join the club of 100k bunnies - you need your own high-level algorithms to work with pixi low-level smoothly.

    As an example - I'm working on complete implementation of Adobe Flash using PixiJS and mozilla shumway.
    My scope is ~500 vector elements with filters that can be cached and ~10000 animations played on GPU.
    `renderAdvanced` in PixiJS Container takes 50 lines, and its relatively sparse. Mine version of element renderer is about 2000 lines if I count all extra components I added for it. Its covered with hundreds of tests.

    Cache that tracks whether particular subtree wasnt changed is like React,except  it can work on 60FPS and doesn't allocate memory like crazy. I implemented it based on all experience of Mozilla Shumway that was coded by~ ten people by 3 years and failed.

    Super-fast scene tree that doesn't iterate through all elements each frame to check if matrices has to be computed and which elements belong to which layer (z-indexing) - that's a huge problem. I made it using my algorithm expertise, which i trained in programming competitions.
    z-culling is another thing that is difficult architecturally, you can just take random gpu optimization and put it inside a scene tree. I don't know any other projects besides mine that use z-culling in 2d which seriously helps on old graphics cards like Intel HD 3000.

    There's also antialiasing for graphics - it doesn't exist in WebGL on RenderTextures, it exists only on WebGL2 and requires serious architectural changes to avoid huge memory consumption. I solved it due to undocumented feature that suddenly exists in all browsers, and I also implemented all that architectural nightmare on top of other optimizations - caches, filters, e.t.c. PixiJS version https://github.com/gameofbombs/pixi-blit/ will be released in a month or so, I focused on my private fork, cant share it yet.
    Interaction optimizations are based on bounds which based on super-fast scene tree. One step sideways and you'll have so many bugs that'll take year to debug. PixiJS bounds bugs exist after 8 years of coding. They are usual problem. I know how to make effective pixel-perfect interaction based on injection of mouse coords in shaders, but i dont know how to add something better like quad-tree without affecting code style badly, which, again, leads to big number of bugs.
    Now, you want 100k Graphics on scene with all those features, where Adobe Flash dealt with 10000. I think, with the scope you are asking, your project costs 1M$  
    Most of my work will be open-source, it will open doors for projects like you asking for, but right now you need to hire a team and spent more than a million $ on 2 or so years to get the product.
    > I guess what I am asking is, what are the communities recommendations when they need to show a large number of potentially interactive objects (Sprites/Graphics) on the screen at once? 
    Write your own stage tree, its not that hard to just copy @pixi/display ,  @pixi/sprite , @pixi/graphics and pixi5-svg and go on.
    > but scaling to ~1M+ later on is not out of the question
    In your dreams. Ask https://phase.com/ how is their project going
  2. Like
    ZYandu reacted to ivan.popelyshev in iOS 13: WebGL: INVALID_VALUE: uniform1iv: invalid texture unit   
    The difference is in number of vertices.
    We use either Sprite BatchRenderer if its small
    or "Graphics.renderDefault" for big number.
    That code will use "renderDefault" for all graphics, and you'll have that error always! 
    PIXI.GraphicsGeometry.BATCHABLE_SIZE = 1; Make that number big enough - all your shapes will fit in batcher instead and it'll be ok.
    That narrows the code segment but i dont have iOS devices to test. Gonna call rest of the team on this.
    I think its possible critical issue, need to reproduce and fix it ASAP.
  3. Like
    ZYandu reacted to Sawamara in Myths and realities of canvas / JavaScript performance   
    Hello!
     
    In the past year, I have decided to do a HTML5-based game, and I kept going at it ever since. Full production is something that is still a bit far ahead, but I managed to squeeze out every single little detail of canvas-related performance that I could find.
     
    Here are my experiences, tips, and all that jazz.
     
    1.On buffers
    Simply using a buffer canvas (an invinsible one) and then drawing that to the screen instead of using image-> canvas is really, at first glance, not faster.
    The applications of this is not meant to be as simple as that, however.
     
    You want parallax scrolling? You want fancy effects generated from a multi-layered spritesheet? You can predict that is going to be needed? Then you can save processing time by using buffer canvases.
     
    There are all sorts of clever tricks to this. Imagine if you need to compile a 4-layered parallax background scroll in about...240 frames (4 seconds). You can process the picture, add the layers to a hidden canvas, frame by frame, in small parts. No single frame will make this buffering draw more than, say....50*50, once per frame.
    And then once it is completed (pre-painted), you can just draw parts of the buffered image, showing the user the parallax scroll in all its glory, by rendering it only once per frame.
     
    If you omitted this process, you will need to draw the bacgkround as it is moving N times, where N is the number of layers.
    This is just one trick. You can build animations from multiple layers, buffer it, and only draw one square (frame) instead of requiring multiple layers of composition and different draws over and over.
     
    Conclusion: buffer-canvases are good, when used with preparation. Just using them natively (for the sake of using them) is not a performance benefit.
     
    2. Canvas size matters, especially (but not only) in mobiles.
    Never use bigger sized canvases than you would truly need. There is a directly testable performance gap between canvas sizes. Sounds like a no-brainer initially, but it is not. Logic would dictate that if I redraw an x*y size area of an 1200*800 canvas, that would be similar if I did the same redraw of an 1000*600 canvas, but it is not. Use clever positioning, CSS, background images if you want to be as optimal about this as you  want to be.
     
    3. The most important canvas optimization #1: Be smart about redraws.
    There has been many tutorials describing this. You should not redraw everything all the time. Multiple canvases are good because you do not need to clear/redraw stuff when one object moves.
     
    In my rpg game, there are currently 5 layers used. Background, UI-BG (frames) layer, character layer,puzzle layer, text layer. When the character moves around, it does it in a different canvas than the background.
    - 1) Only redraw animation frames when you need them to. Non-moving object? No redraw.
    - 2) Only clear (clearRect) when you need to. Be very precise about the areas needed to be cleared. Doing 5*(40*100) clears is usually better than doing one 400*100 clear.
    - 3) This has yet to be carefully tested - more like anecdotal evidence, but you need to organize your drawing like.....canvas 1: Perform all clears, all draws. canvas 2: perform all clears, all draws. DO not do canvas1 clear, canvas 2 draw, canvas 1 draw canvas1 clear canvas 3 draw canvas 2 draw canvas 1 clear canvas 4 clear. It is a performance loss.
     
    My own "camera" framework gets draw/clear commands thrown at it, and it keeps separate clear/drawQueries, and at the end of an animFrame, it draws all queries and clears all queries. Goes from canvas to canvas. I was afraid it is going to be convulted, but in a HTC Desire 310, I can achieve 30-60fps on my game, even without further resolution adjustments. And it has constant animations, parallax scrolling, moving puzzle, five layers. I am almost satisfied with it. Before I started optimizing the game, it crawled in single digits.
     
    4. The main culprit behind slowdowns is usually the garbage collector.
    Seriously. I have looked at so many HTML5 Canvas/webGL games in the past few months, looking for answers, and most of them have the quick sawtooth performance that is painful to watch. Let us assume your game runs at 60fps. Theoretically. Now, with regular GC, you can get a visible slowdown every seconds, even if it is just a hitch to lower 50's. (60->57->51->60->51->etc.). You need to have a VERY carefully written code to eliminate this. Basically, no anonymous functions, no var declarations hundreds of times per frame, no spamming of new objects per frames. I could write pages on this - and if there is a relevant topic for it, I might. -,but this is the main part of it.
     
    5. Be aware of smaller performance traps.
    Text rendering is one like that. Changing alpha value of a canvas again is. Doing translations is once again. (Better buffer both of these on a hidden canvas in a loading stage, and keep the alpha intact!). Do not use console.log on mobile versions, they will just throw exceptions sometimes multiple times per frames. What you started with is true: aim for the lowest amount of redraws and clears every frame. Find tricks to average these out and manage them that way instead of having busy and calm periods.
     
    I am right now at the end of my canvas "patience". I still love this little tech, but I am at a point where I am looking at just porting all that to webGL. Canvas support will stay in the game just in case, but it is clearly not going to be flawless on low-end mobiles for a few more years. It is going to be "fine" in better-than-average mobiles, average or better tablets and excellent on iPads/iPhones, viable on most modern desktop PC's. But you have to be careful about the resource uses.
  4. Like
    ZYandu reacted to ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    ok, i dont know  need to replicate it somewhere but i dont have apple devices
  5. Like
    ZYandu reacted to ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    do you use ParticleContainer? try just Container. If it works, we have a bug in particles. again.
  6. Like
    ZYandu reacted to ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    Tthat means we have a problem with texture locations, like using 32 instead of MAX 16 that is allowed. Do you use any pixi plugins?
  7. Like
    ZYandu reacted to ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    > what type of PIXI texture uses Webgl 2.0's uniform1iv call
    Oh, right, its not your shader, its pixi problem. uniform1iv is used even in webgl1 for samplers.
    I think its not about integers. I think its something about MAX_TEXTURES. Whats the minimal demo that fails? Just a bunch of sprites?
  8. Sad
    ZYandu reacted to ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    yep, exactly.
  9. Like
    ZYandu got a reaction from ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    I am getting this error in my game only on IOS with Cordova on PIXI 5.1.1 with Webgl 2.0 (It works on Google Chrome perfectly fine). All my sprites and graphics get loaded to the screen but when the RAF should start it gets this error and doesn't continue. https://imgur.com/a/lqVDzdA
    Maybe it's something my IOS with Cordova is lacking from the requirements for Webgl 2.0 Specifications? https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.4
    Thanks for any advice! 🙂
  10. Like
    ZYandu got a reaction from ivan.popelyshev in Webgl uniform1iv error on IOS with Cordova   
    It looks like it might just be that Safari doesn't support Webgl 2.0. https://caniuse.com/#feat=webgl2 
    Cordova uses webkit 2 which is based upon the Safari browser...
  11. Like
    ZYandu reacted to nicknack23 in Aliasing artifacts using DisplacementFilter   
    I wasn't aware that you guys had done this in 5.1.1. So I enabled PIXI.SCALE_MODES.LINEAR and went back to the default DisplacementFilter and ... it worked perfectly. The new shader code I was so happy about is completely unnecessary (on desktops at least - maybe I'll still use it if I want to be ambitious about mobile support). Oh well, at least I learned a lot the past few days.
    Don't worry about missing my issue, I'm sure I'll manage to wear you down with a million other questions in the next few months. In fact, I already have a tricky one in mind - I'll start a new thread right away.
     
  12. Like
    ZYandu got a reaction from ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    Yes good idea! I turned off all my plugins for Chrome on my Macbook Pro and I haven't gotten a profile with a RAF failure in 3 separate 60 second profiles.
    However, I still see it happen in my game 😛 My guess is that since an RAF is supposed to sync with the browser, Chrome is saying that it's not ready to draw yet and holds the RAF up until it is ready. Or maybe my Macbook Pro isn't giving Chrome the resources it wants to be able to draw again too when the temp rises and fans start up.
    To test this, I did a profile on my Chromebook with the Pixi playground example and saw many slowdowns, most of them GPU related or caused by large spaces between frame executions. Also some GC. It is obvious that a Chromebook should perform much worse, but maybe it's highlighting the main problem to be with the Chrome browser itself or more of a device specific GPU + CPU available resources type of issue. 
    https://imgur.com/a/0r7KhJ9
    https://imgur.com/a/fAJpMID
    https://imgur.com/a/D4ItbY8
  13. Like
    ZYandu reacted to Exca in Long RAF execution behavior in Chrome devtools   
    I think the first few GC's are something related to loading of the pixi playground as those I can get too. After the GCs though the rendering continues without a problem.
    For some reason I cant upload a screenshot of the profiler. But here's a link to my profiling: https://imgur.com/wtTMvqX
    Do you have some plugins installed?
  14. Like
    ZYandu reacted to Exca in Long RAF execution behavior in Chrome devtools   
    Very mysterious indeed. Especially the second animation frame delay. Do you have lots of console.logs? Though if that was the case, then the problem would disappear when dev tools is closed (at least on windows).
  15. Haha
    ZYandu reacted to ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    I have no idea
  16. Like
    ZYandu reacted to ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    There's nothing to collect in that app
  17. Like
    ZYandu reacted to Exca in Long RAF execution behavior in Chrome devtools   
    Yeah, but heap size looks like it changes in that frame on the memory graph. So something happens with memory. Though it should have a node with carbage collection if actual gc happens.

    @ZYandu Can you take a profile of the posted example when stutter occurs?
  18. Like
    ZYandu reacted to Exca in Long RAF execution behavior in Chrome devtools   
    Can you take a profiler dump/screenshot of profiler page of the page running? That could show what is happening. Example runs without problems on win10/chrome with nvidia 1060.
  19. Like
    ZYandu got a reaction from ivan.popelyshev in Pixi.Text v5.1.1 doesn't work   
    import myBitmapTextFont from "myFontsFolder/myBitmapTextFont.fnt"; let loader = PIXI.Loader.shared; loader.add([{name: "bitmapTextFont", url: myBitmapTextFont}]) .load(setup); function setup (loader, resources){ let text = new PIXI.BitmapText("abcdefg", { font: "50px Arial", //Arial is the face attribute located inside the .fnt file align: 'center' }); } Here's my quick code example made with a custom .fnt file from bmGlyph. You really need to follow the instructions closely in the instructions link Ivan shared! 🙂 https://www.adammarcwilliams.co.uk/creating-bitmap-text-pixi/
  20. Like
    ZYandu got a reaction from Magia in Pixi.Text v5.1.1 doesn't work   
    import myBitmapTextFont from "myFontsFolder/myBitmapTextFont.fnt"; let loader = PIXI.Loader.shared; loader.add([{name: "bitmapTextFont", url: myBitmapTextFont}]) .load(setup); function setup (loader, resources){ let text = new PIXI.BitmapText("abcdefg", { font: "50px Arial", //Arial is the face attribute located inside the .fnt file align: 'center' }); } Here's my quick code example made with a custom .fnt file from bmGlyph. You really need to follow the instructions closely in the instructions link Ivan shared! 🙂 https://www.adammarcwilliams.co.uk/creating-bitmap-text-pixi/
  21. Like
    ZYandu got a reaction from ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    Dang... are you seeing any of the visual stutters I mentioned? It still looks like it slips up on my MacBook Pro. Are you using a computer with a nice GPU?
  22. Like
    ZYandu reacted to ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    I meant that i dont see problems with your code.
  23. Like
    ZYandu reacted to ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    no, its clear
  24. Like
    ZYandu reacted to ivan.popelyshev in Pixi.Text v5.1.1 doesn't work   
    Found it here: https://github.com/pixijs/pixi.js/wiki/v4-Resources
    https://www.adammarcwilliams.co.uk/creating-bitmap-text-pixi/
    the only difference is that "BitmapText" is not in extras anymore.
  25. Like
    ZYandu reacted to ivan.popelyshev in Long RAF execution behavior in Chrome devtools   
    Congratulations! Now I really dont know what can it be. Except profiler itself.