search

fatteneder / SVGMakie.jl

SVG backend for Makie
MIT License
1 stars 1 forks source link

Optimize SVG file output - `Mesh3d` #1

Open fatteneder opened 1 year ago

fatteneder commented 1 year ago

Atm we mesh all points, but it would be sufficient if we mesh only points that are visible from the current projection. This could be done by generating one big raster image with all zeros (transparent) pixels, then traverse the meshes in reverse z depth (back to front) and merge the color_matrix with the one of the current layer, where the latter's values are prioritized.

To get straight edges we currently fill the color_matrix also outside the triangle region and then clip it in the SVG. For the above strategy I think we would have to already 'clip' the color_matrix before we merge them. But I fear that this might introduce zig-zag edges again. To fix the latter we could try to artificially extend the 'clipped' color_matrix by just duplicating the colors at the edges so that we have a fully colored area that we can clip again in SVG.

This leaves the problem of finding a non-trivial clipping path. Not sure if that is feasible though ...

All these optimizations will also effect performance/quality Surface, MeshScatter.

asinghvi17 commented 1 year ago

This optimization might help in CairoMakie as well! I think we could potentially shift a couple of these kinds of helper functions to Makie, so that all vector backends can benefit.

fatteneder commented 1 year ago

Yeah, was thinking about that already, also because I started writing a TikZ backend that could benefit too.

asinghvi17 commented 1 year ago

whoa, looks like Makie's going to get a lot of backends in the future!

How are you looking at solving the text problem (Makie wants to position its own text, these engines also want to position their own text)? I guess the solution would be similar for TikZ and SVG.

fatteneder commented 1 year ago

With SVG you can position glyphs one by one, which I currently do. But we really should use a tspan (or so) to position a group of glyphs so that you can easily copy paste (xref #10). From the MWEs I did it looked like the positioning already worked nice as it is, but I did not do much testing either.

For TikZMakie I stopped working when it came to implement text :laughing:, but because I got side tracked. But I would look at PGFPlots first to see how they do it and go from there.

asinghvi17 commented 1 year ago

Yeah, Plots is a lot looser on its text constraints, there isn't a standard interface to get text bboxes for instance. My intuition is that PGFPlots just relies on TeX's inbuilt layouting (which makes sense, given that it's literally built for that).

fatteneder commented 1 year ago

This optimization might help in CairoMakie as well! I think we could potentially shift a couple of these kinds of helper functions to Makie, so that all vector backends can benefit.

About this: If you compare SVGMakie and CairoMakie you will see that there is a very big overlap in their sources, except for primitives.jl, display.jl, screen.jl (or so). In fact, most of the stuff I just copied without modification. And the same would apply to a TikZMakie version. So I was thinking already thinking about writing something like VectorMakie that is a common base for all vector backends and from which the others would then derive. Obviously, that would cut down in maintenance effort, but we would also have to move it to the Makie mono-repo, because CairoMakie is also there.

What do you think about that idea?