• Content Count

  • Joined

  • Last visited

  1. The problem with these kinds of approaches are that the normals and extrusion direction have to be uploaded as part of the vertex data. As well it means computing the normals on the CPU if they are not known (i.e. drawing a triangle based on coordinates). It works fine for cases like this (single quad) but trying to apply it to complex data (i.e. PIXI.Graphics) could add a lot of overhead. The stencil buffer is useful for complex polygons with holes. In those cases triangulation can become expensive. The downside is that you lose the backbuffer anti-aliasing and have to apply FXAA or similar. Either way the hope is that WebGL2.0 should eliminate the need for these anti-aliasing workarounds due to the presence of multisampled renderbuffers (hopefully faster than these workarounds for complex shapes).
  2. renderer.view is just a regular canvas DOM element. So you may use CSS as you would for any other DOM element: var width = 1280;var height = 720;var baseWidth = Math.floor(window.innerWidth);var baseHeight = Math.floor(window.innerHeight);var aspectRatio = baseWidth/baseHeight;var renderer = PIXI.autoDetectRenderer(width*aspectRatio, height, {backgroundColor: 0xFFFFFF});// apply CSS to the DOM = "0 auto"; = "block";document.body.appendChild(renderer.view);var stage = new PIXI.Container();Because the margin is being used to center the element, the container will automatically move on window resize events.
  3. I don't delete it entirely - just graphics.clear() should be ok.
  4. Typically a node graph is similar to the following structure: The nodes are the circles which would be draggable. In my case the circles are Pixi sprite and the lines are drawn in a Graphics instance.
  5. I am working on something like this currently, but it's not generic enough to be shared. I'm using a single PIXI.Graphics instance to draw lines between nodes. Each time a node is dragged, I clear the Graphics instance and redraw the updated lines. This achieves the functionality you described. I do some optimizations here such as culling nodes outside of the viewport and lines that do not pass through the viewport. I also separate inactive lines (ie. lines that do not connect to the current node) to a separate container so I can continuously update active lines only (the lines that are moving with the current dragging action). My solution works very well for tens of thousands of nodes, but there is noticeable lag when 10,000+ pipelines are drawn on the screen at once (you may never have this problem). To improve this I plan to move away from the Graphics approach to draw thick lines in the shader directly, but you may never require this if your hierarchies are not very complex. If you want to share an example (either publicly or privately), I can try to assist.
  6. I'm trying to avoid re-implementing the entire Graphics object, because there are some features that probably necessitate the calculations to be performed outside of the GPU (such as use of earcut for polygon fills). Perhaps we could just begin with a fast Line Segment object (using WebGL shaders) as an extension. I don't use either of those services but you can email/add me on Google Chat at josh (at) joshgroves (dot) com. I'm also on GitHub at this username.
  7. I am working on an interactive data visualization in which thousands of graphic elements have to be updated continuously as the user drags an endpoint connected to each node. When render times are too slow the visualization feels sluggish and breaks interactivity. A simple (non-interactive) example can be found here, which replicates my issue with render times: A significant amount of time is spent in garbage collection. I've considered using object pools in the Pixi library for WebGLGraphicsData.points and WebGLGraphicsData.indices (ie. stop setting both of these to [] every time WebGLGraphicsData.reset is called). This means buildLine could add points as necessary by tracking the last index. Afterwards the arrays could be trimmed before the render call to remove old data from the end. I am mostly looking for feedback to this approach, and whether it could be implemented more elegantly. I've taken some steps to implementing it already, but it requires modification of most of the graphics drawing methods. I'm also not sure if there are any straightforward methods to realize performance gains here. Perhaps Pixi already has a better, native way to handle this. Eventually I do plan to try allowing the shaders to calculate the lines based on line width instead, which should decrease the amount of time spent in buildLine. However the garbage collection problem will remain, which is why I am targeting that first.