Fix lines #2843
Fix lines #2843
Conversation
Compile Times benchmarkNote, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than the base branch. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running: using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))
|
|
I'm also trying to fix #2826 and #1129 here (or at least not make it worse again) but I keep finding issues with my solutions. The last I tried was adjusting the number vertices/triangles used in the line segment.
This helps with overdraw somewhat, but when the inner triangle inverts you get some overdraw at each corner:
The fix for #2842 should be fine as is. |
|
I pushed the above now. It's decent enough for reducing overdraw I think, and I don't think I can come up with a better solution atm. So maybe we just take this as is for now? Full scale of #1129: Detail of #1129: Full scale of #2826: Detail of #2826: And here:s another chunk of code to simulate line join issues: https://gist.github.com/ffreyer/0875fceb4ba80c6779f5ff14b5f24f2d |
|
Ok nvm, I think I have a better solution now. I still need to test with patterned lines and shallow corners again though. Once I'm done I'll mark this ready again. The approach I've switched to now uses 4 vertices/2 triangles in the normal case again, but splits the segment into 2 independent triangles (6 vertices) when it starts drawing over itself. For the triangle at p1 I'm adding p2 as an AA border, and vice versa. That should stop the triangles from drawing outside other triangles.
#1129 now looks like this when overdrawing occurs: (this is a ⨅ corner) #2826 now looks like this: |
|
Things get a bit fuzzy when points get super dense, but I think that's fine. (Starts at around 2^18 ~ 260k points)
For fun, this is the before for solid lines (dashed is similarly fuzzy, dot is fine in either. Probably because it doesn't try to bend around corners.) |
|
Closes #2855 as well. Line start/ends in corners now fill out the corner in GLMakie: line_ends.mp4Not sure if that's the best way to handle this, but I think it at least looks cleaner than before. CairoMakie doesn't deal with this well either, but I'm not gonna bother with it here line_ends_cm.mp4 |
Description
Fixes #2842. The issue is what I wrote in the issue - due to extending the linesegments with AA borders without adjusting the depth values of the those translated vertices, the depth values become slightly off across the line. This then causes the line to dip behind the mesh in the issue. To fix this we just need to consider depth for adjustments along the line directions.
Fixes #2826 which is a result of the fix for #1129. See below.
Type of change
Checklist