Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differential Render #67

Open
spencermize opened this issue Apr 22, 2020 · 2 comments
Open

Differential Render #67

spencermize opened this issue Apr 22, 2020 · 2 comments

Comments

@spencermize
Copy link
Contributor

I haven't looked too much into the source yet to see if this is possible, but here's what I have going on:

  • Streaming JSON from the server (very large data set)
  • Using oboe.js to parse that data as it streams in
  • Rendering to a single layer in glify. So far, the best way I've found to do this is to just trigger render() every few seconds, but it feels hacky.

Currently, I'm using the same instance of Points, but then modifying the settings.data and calling the render() function.

  1. Is there a faster / better way to do this? I want to update the layer as the data emerges from the pipe.
  2. Is there a way to merely add points to the context, rather than re-rendering the entire thing? I'd love to be able to ditch my entire huge array once its rendered.

Any thoughts on this? I'm happy to help change code if necessary, but I thought I'd stick a message here first as I have little / no experience with WebGL beyond using it via Glify. Thanks!

@spencermize
Copy link
Contributor Author

It appears I already (somewhat) posted about this in #24 😄

@spencermize
Copy link
Contributor Author

I've hacked around on this. By adding a parameter such as clearOnRender to settings and combining with the preserveDrawingBuffer option, I was able to convince Glify to maintain the previous canvas:

if (this.clearOnRender){ gl.clear(gl.COLOR_BUFFER_BIT); }

However, there are negatives to this action:

  1. Click events stop functioning
  2. Panning and zooming get all kinds of messed up
  3. I'm sure others I haven't found yet

For my particular use, these are acceptable tradeoffs. However, I don't think it's wise to implement this in the larger library unless we can find ways to mitigate at least 1 and 2, and without a better understanding of 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant