• Content Count

  • Joined

  • Last visited

About jasonsturges

  • Rank
  • Birthday December 21

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Des Moines, Iowa

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @bubamara, @ivan.popelyshev Thanks
  2. There's a TileSprite implementation in my project that seems to offset and distort on live production kiosks. this.tileTexture = PIXI.Texture.from(ConveyorAsset.RED); this.tile = new PIXI.TilingSprite(this.tileTexture, 491, 50); animate: function() { this.tile.tilePosition.x -= 0.51; if (this.enabled === true) { this.frameId = requestAnimationFrame(this.animate.bind(this)); } } I've let this animation run for 12-hours at a time on my development computer, and never seen an issue. However, at production facilities on kiosks running 24-hours a day, eventually there's some offset to the tile data that corrupts the animation. Any insight as to what might cause this, or how to debug it? Kiosks are Intel i5-7300, onboard Intel HD Graphics 620 Conveyor.mp4
  3. @bubamara Ah, `detach` - didn't see that for some reason. Thanks.
  4. How do you remove a `onComplete` handler from a shared loader? const loader = PIXI.Loader.shared; loader .add(...) .add(...) .load(); loader.onComplete.add(handler); My core application loads a standard set of textures; then, calls the complete handler. However later during runtime, new scenes can be loaded via a File -> Open operation that may contain new or custom texture assets. When I load those textures in a different area of the application via the shared loader, my original completion handler is called. This ends up chaining so that my first shared loader's `onComplete` is called twice. My workaround is to ditch the shared loader and create new instances: const loader = new PIXI.Loader(); Seems like I should be able to remove the handler, like: loader.onComplete.remove(handler);
  5. Logged at GitHub: https://github.com/pixijs/pixi.js/issues/6414 Basic gist: This Fabric.js app prevents default - I guess it's not a built-in feature, though:https://mudin.github.io/indoorjs/ Deck.gl has this built-in, I thinkhttps://deck.gl/showcases/gallery/icon-layer Nebula.gl or Kepler.gl express this from Deck.gl: https://nebula.gl/geojson-editor/ https://kepler.gl/demo Not sure what Three.js is doinghttps://threejs.org/editor/
  6. Having an issue on desktop where Pixi interaction manager doesn't appear to prevent default capturing pinch gestures. This is especially problematic with Pixi Viewport, where pinch zoom gesture is getting caught by the browser; therefore, zooming the browser's viewport (entire DOM). For example, as I pinch zoom the Pixi Viewport below, the browser intermittently zooms the entire view: https://codepen.io/jasonsturges/pen/BayMWxm Maybe no solution here - Chrome doesn't support the `user-scalable` meta attribute in html on desktop. By default, shouldn't the interaction manager of Pixi capture and prevent these events?
  7. Looking for some feedback on best practices for handling large texture data. On desktop, it seems I can easily load large textures exceeding 8k on a side; however, mobile fails to render past 4096 pixels on the longest side. Project I'm working on loads schematic views, of sorts - there's a background image on which components are placed. Zoom / pan is implemented from Pixi-Viewport project. These are available as vector, but prototyping as SVG seems to incur a significant performance loss. Not sure if there's a mipmapping approach, or some kind of level of detail such as TileMap. Roughly following the TileMap project... background image is sliced and loaded via multiple frames. Presume source code for the "webgl: zoomin and zoomout / retina webgl: zoomin and zoomout" examples are just https://github.com/pixijs/pixi-tilemap/blob/master/demo/main.js The canvas version doesn't appear to be working: main.js:104 Uncaught TypeError: Cannot read property 'flush' of undefined at update (main.js:104)
  8. @ivan.popelyshev This makes a lot of sense. Really appreciate the insight here. Need to digest this, and might have some follow up questions. Similar situation with a complex data visualization involving a few thousand sprites. Pixi.js performance is blistering fast, solid at 60fps, but I have some reservations about patterns I'm implementing. Thanks again for all the insight and support!
  9. A display object's `render()` method will call every frame, right? Is there a component lifecycle for validation built in to Pixi, akin to fl.controls usage of fl.core.UIComponent? As in, a way to trigger rendering / update only when needed per display object (not the entire Pixi application) when multiple properties are set on the same frame. For example, if I have several properties that determine state of a display object, should I calculate that in `render()`; or, should I set an invalidate flag to be handled on the next frame? Pseudo-code example: class MySprite extends PIXI.Sprite { set color(value) { // ... this.dirty = true; } set selected(value) { // ... this.dirty = true; } render(renderer) { super.render(renderer); // Calculate display state here? // Is there a better lifecycle hook? // Or, manually validate using the animation frame? this.validate(); } validate() { // Validate presentation state if dirty if (this.dirty === false) return; this.dirty = false; // ...calculate state based on properties // if color is red and selected is true, texture = red-selected.png } }
  10. @ivan.popelyshev Awesome - yes, that makes significant improvement. Have a few curved paths that become a little grainy with that scale mode, but that's minor. As always, really appreciate your help and insight! Thanks!
  11. Thought I've seen this topic before, maybe regarding alpha blending, but I'm failing to find an answer. My transparent PNG has fuzzy / blurry edges when zoomed using the pixi-viewport package. Original PNG: Pixi.js viewport when zoomed: The original source image does have a pixel bleed, but I'm wondering if there's any way to sharpen this up. This is a schematic viewer, where the user can zoom in to view details. Background image is fairly large, which might be a contributing factor.
  12. Interesting - my projects embed Pixi within React lately, but worked well in that ecosystem. Also interested in moving more to TypeScript... been slow to adopt, but I like the language features.
  13. Are there some examples of extending PIXI.utils namespace? Taking a look at Pixi's debugging and editor tools, the Free Transform Tool appears to extend PIXI.utils - cool library, looks pretty alpha without npm or webpack. Just references PIXI in a global scope and attempts to prototype utils. If I want to extend Pixi through utilities, or maybe just provide webpack module libraries through npm, any recommendations such as good example projects to follow?
  14. @ivan.popelyshev Minus multi-selection, that's a perfect match. Thanks! Really appreciate all the support you provide.
  15. Any recommendation for equivalent functionality of Fabric.js selection and transformation with Pixi.js? Anything like this been endeavored for Pixi.js? Maybe a similar library out there?