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

precise rendering for markers #18

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

JakkuSakura
Copy link

@JakkuSakura JakkuSakura commented Nov 13, 2020

fixes #16

@karlwessel
Copy link
Owner

Sorry for not reacting to this. You were correct that this is a problem of floating point precision and the solution is to calculate transformations on the CPU using 64 bit precision. However a correct fix is much more complex than this.

Firstly and mainly, the decision when to calculate the transformation on CPU should not be based on the number of points but on the magnitude (determinant?) of the transformation matrix, when zoom or translation is to large to be represented accurately by 32 bits it should be calculated on the CPU.

Secondly, even then the transformation should not be done for each render step, otherwise you lose the speed up from using the GPU.
Instead one can split the transformation into two steps. The first part is doing the transformation on CPU and caching the resulting vertex positions as well as the transformation. The second is to calculate the relative transformation from that cached transformation during each render step and only calculate that relative transformation on the GPU.
And every time the relative transformation gets to large for representing it with 32 bits we update the cached positions and transformation with the current transformation.
That way we only calculate the transformation once in a while on the CPU and can keep the GPU for handling most of the render calls.

This just for completeness if anyone would like redo this PR.

@JakkuSakura
Copy link
Author

I remember the PR was to use CPU to compute small number of points, but still use GPU for large number of points.
A fast, hacky workaround

@karlwessel
Copy link
Owner

Ah, I see now! Yes indeed a fast hacky workaround :).

Out of curiosity: Did you actually really end up using this library? I could never really get it useful enough for my use cases.

@JakkuSakura
Copy link
Author

Yes I ended up using the library for a while. It helped a bit. Later we switched our focus. When we revisit plotting, we decided to use streamlit, plotly and clickhouse(for downsampling)

@karlwessel
Copy link
Owner

Plotly sounds much more sensible, designed for interactive plots and with GPU acceleration built in. Maybe I should recommend it in my Readme as a better alternative.

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

Successfully merging this pull request may close these issues.

Markers not displaying properly on small intervals
2 participants