Jump to content

dmko

Members
  • Content Count

    101
  • Joined

  • Last visited

About dmko

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. hehe - seems I had a few tabs open and got a bit confused about which thread I was responding to It's totally relevant here though! I'd like to get the scene shown at http://editor.babylonjs.com/ as a glTF file w/ assets, would be great if someone had that available
  2. I'm playing around with glTF and the babylon demo scene in that editor looks great (plastic, metal, spheres, fast load time...) Has anyone got a glTF version of it available for testing outside of babylon? I'll look into converting it myself, just thought someone might have already done it
  3. In this sense nothing changes. You're not adding/removing elements from the page, you're wrapping all the imperative canvas calls up in a declarative framework. The same way React-DOM deals with all the element.innerHTML stuff, your react renderer (or components) deal with all the canvas.draw (or rather, PIXI.*) type calls - but on the app level you don't touch any of that, you just write the changes declaratively.
  4. @caymanbruce Thanks for bringing this thread up - I should note that my experiments here were superseded at this other thread: I don't know anything about Angular. With React, essentially, there's two approaches 1. Using React as-is with the built-in React-Dom renderer. With this approach, there's nothing really special going on, you just handle all your imperative PIXI updates in render() or one of the other lifecycle methods. To make it worthwhile, you'd probably want to create some boilerplate components that do this for you and expect certain props to exist. E.g. a Sprite
  5. dmko

    Vue js hot reload

    Also just to add if you call app.render() directly, you should setup the PIXI.Application with `autoStart: false` I'm not sure if it makes a difference practically (e.g. double-render somehow), but it can only help
  6. I created a very early, very alpha React renderer for PIXI. There's some other projects out there but I wanted to start from scratch. You can get it at https://github.com/dakom/react-pixi-renderer However, be warned, performance kindof sucks if you use it for lots of nodes. See this test/demo I wrote that tries to figure out where the bottleneck is: https://dakom.github.io/react-renderer-test/ Turns out that the bottleneck is basically React itself and the size of the tree. The React-pixi-renderer could be really useful for declaratively describing a few of a small number of ite
  7. Okay I added a clean baseline version: https://github.com/dakom/baseline-pixi-bunnymark No comparison (it takes me like 100,000 bunnies to get to where react crawls at 8,000 and it’s still more responsive) :\
  8. Yeah, for this context I'm focused really on using it with react (or as I'm now looking into, maybe Inferno) Cool stuff though and reminds me that I'm missing a baseline comparison hehe... will write that now Right on, that's what I meant by like "built-in ability to "removeChild" when the JSX changes" but you nailed the overall idea in that sentence. It would be super awesome if that were possible imho, I don't think it would be rubbish unless it introduced a bunch of restrictions like specific props you have to pass in etc (kindof like in my implementation, where you have
  9. Yeah - everything you're saying is spot-on @mattstyles The performance killer here is definitely React as far as I can tell. This attempt to use React as-is and simply render `null` does rely on lifecycle methods so stopping propagation via shouldComponentUpdate isn't going to work completely. I did change everything except `withPixi` to be PureComponents just now though - negligible gains. I'm not aware of how to bypass all that evaluation stuff... I looked at react-pixi and couldn't make heads or tails of what's going on there and I'm not immediately convinced without seeing
  10. FYI here's a screenshot of some random-ish stats from a long frame in development mode:
  11. Just pushed an update - might take a little bit for Travis/github, but testing locally - it didn't seem to fix it, I think it's probably something with React itself :\ Btw I suck with profiling, when you have a minute can you take a couple screenshots to show me where you see that 19% GC stat? Shutting down for the night, thanks for taking a look
  12. Sorry - yeah Fuse-Box doesn't have source maps working with minification yet :\ Hmmm that's interesting about the GC - just for fun I'll see what happens if the update objects are made mutable
  13. OK here is my attempt at it: https://github.com/dakom/react-pixi-bunnymark Performance is awful. Very happy to know if there's some key thing I missed to optimize (though maybe prove it with a fork or something... of course there's lots of things that can be made better but might not add real big numbers)
  14. Ah - so I'm looking at more for describing the PIXI scene itself, not for additional UI. I'll try to mock up the bunny-mark test and put it on github for all to fork and tinker with. I actually may need to use this approach for an upcoming project so I'm very interested in any gotchas
  15. I haven't done a ton of React stuff but I am tinkering a lot more lately Here's a little JSFiddle to benchmark - it doesn't include PIXI stuff but just to see how long it takes to get from a render on a parent to an update on a child, and I think this is roughly the way I'd structure a React+PIXI app (the pixi updates happen in the child's componentWillReceiveProps() - and the render() from child would just always return null) https://jsfiddle.net/dakom/e65tbxsy/ I'm getting less than .1ms between the parent's render() and the child's componentWillReceiveProps(). Assuming I benchm
×
×
  • Create New...