Consider splitting rendering and processing #590

gvheertum · 2019-10-15T07:30:53Z

In the light of the issue #576 (where the author indicated a .NET standard build might be helpful) we might consider splitting some of the parts from the SVG library. As far as I known part of the rendering (System.Drawing) is the main culprit for the library not being able to be built against .NET standard. From my understanding the SVG library can facilitate 2 things: processing and transforming SVG files (the XML part) and rendering an SVG to a bitmap.

The first part could classify for a .NET standard build. Downside however is that this might result in 2 libraries/packages, but it might help people that want to use the SVG part in .NET standard applications.

Just a random thought, but perhaps something to consider in the future.

wieslawsoltes · 2019-11-06T19:42:06Z

This would help a lot with my SkiaSharp port.

This is my current rendering interface used for SkiaSharp:
https://github.com/wieslawsoltes/Svg.Skia/blob/4ac1dfb7d58cf9121a472a1d086367b39ba0cf01/src/Svg.Skia/ISvgRenderer.cs#L9
https://github.com/wieslawsoltes/Svg.Skia/blob/master/src/Svg.Skia/SvgRenderer.cs#L11
and a lot of helper methods:
https://github.com/wieslawsoltes/Svg.Skia/blob/master/src/Svg.Skia/SvgHelper.cs#L16

mrbean-bremen · 2019-11-06T20:28:44Z

So, I understand you are volunteering for this? 😛

wieslawsoltes · 2019-11-06T20:53:23Z

So, I understand you are volunteering for this? 😛

I will not be easy to decouple the System.Drawing dependencies from current implementation.

Anyway I will have pretty good idea and some implementation (for Skia) for further discussion when I finish implementing basic support for rendering in the Svg.Skia library.

mrbean-bremen · 2019-11-07T17:32:29Z

Sounds good! 👍

tebjan · 2019-11-09T14:52:38Z

See the linked issue, we could evaluate whether we could join forces with the skia drawing repo.

paolofulgoni · 2019-11-09T17:47:24Z

As I wrote on Gitter yesterday, I was thinking about extracting the SVG manipulation part in a separate library too, and make it fully netstandard compliant.
My original idea was a completely separate lib, not a split of the this one. But the latter may actually make more sense. I'm just a bit afraid it would be harder and more constrained.

paolofulgoni · 2019-11-09T17:51:24Z

@wieslawsoltes do you think you could achieve the full rendering functionality of vvvv/Svg with your Svg.Skia implementation?

wieslawsoltes · 2019-11-09T18:56:21Z

@wieslawsoltes do you think you could achieve the full rendering functionality of vvvv/Svg with your Svg.Skia implementation?

I think we can, a lot of rendering functionality already there.

paolofulgoni · 2019-11-09T21:57:58Z

So creating the new svg parsing/manipulation library seems a good idea for many reasons.
If vvvv/Svg will use such libary, should it maintain backward compatibility?
I mean, splitting the library without breaking changes could be difficult.
What do you think @tebjan?

wieslawsoltes · 2019-11-10T11:36:58Z

@tebjan @mrbean-bremen

So my current approach in Svg.Skia for rendering using SkiaSharp and document processing from Svg library is:

Step 1 - load document

var svgDocument = SvgDocument.Open<SvgDocument>(path, null);
if (svgDocument != null)
{
    // ...
}

Step 2 - draw using SKCanvas

float width = svgFragment.Width.ToDeviceValue(null, UnitRenderingType.Horizontal, svgFragment);
float height = svgFragment.Height.ToDeviceValue(null, UnitRenderingType.Vertical, svgFragment);
var skSize = new SKSize(width, height);
var cullRect = SKRect.Create(skSize);
using (var renderer = new SKSvgRenderer(skSize))
using (var skPictureRecorder = new SKPictureRecorder())
using (var skCanvas = skPictureRecorder.BeginRecording(cullRect))
{
    renderer.DrawFragment(skCanvas, svgFragment);
    return skPictureRecorder.EndRecording();
}

Here I am also using SKPictureRecorder to record SKPicture. The SKPicture is nice class that records draw command and you can cheaply redraw the SKPicture without the costly processing and allocations.

My current custom rendering interface:

public interface ISvgRenderer : IDisposable
{
    void DrawFragment(object canvas, SvgFragment svgFragment);
    void DrawImage(object canvas, SvgImage svgImage);
    void DrawSwitch(object canvas, SvgSwitch svgSwitch);
    void DrawSymbol(object canvas, SvgSymbol svgSymbol);
    void DrawUse(object canvas, SvgUse svgUse);
    void DrawForeignObject(object canvas, SvgForeignObject svgForeignObject);
    void DrawCircle(object canvas, SvgCircle svgCircle);
    void DrawEllipse(object canvas, SvgEllipse svgEllipse);
    void DrawRectangle(object canvas, SvgRectangle svgRectangle);
    void DrawMarker(object canvas, SvgMarker svgMarker);
    void DrawGlyph(object canvas, SvgGlyph svgGlyph);
    void DrawGroup(object canvas, SvgGroup svgGroup);
    void DrawLine(object canvas, SvgLine svgLine);
    void DrawPath(object canvas, SvgPath svgPath);
    void DrawPolyline(object canvas, SvgPolyline svgPolyline);
    void DrawPolygon(object canvas, SvgPolygon svgPolygon);
    void DrawText(object canvas, SvgText svgText);
    void DrawTextPath(object canvas, SvgTextPath svgTextPath);
    void DrawTextRef(object canvas, SvgTextRef svgTextRef);
    void DrawTextSpan(object canvas, SvgTextSpan svgTextSpan);
}

You can see in all cases I am passing drawing context object canvas as object.

In each the draw method I am casting drawing context canvas to appropriate SkiaSharp canvas (it can be Graphics object when using System.Drawing).

if (!(canvas is SKCanvas skCanvas))
{
    return;
}

Example how draw SvgCircle element using SkiaSharp:

float cx = svgCircle.CenterX.ToDeviceValue(null, UnitRenderingType.Horizontal, svgCircle);
float cy = svgCircle.CenterY.ToDeviceValue(null, UnitRenderingType.Vertical, svgCircle);
float radius = svgCircle.Radius.ToDeviceValue(null, UnitRenderingType.Other, svgCircle);
SKRect bounds = SKRect.Create(cx - radius, cy - radius, radius + radius, radius + radius);
SKMatrix matrix = SkiaUtil.GetSKMatrix(svgCircle.Transforms);

skCanvas.Save();

var skPaintOpacity = SkiaUtil.SetOpacity(skCanvas, svgCircle, _disposable);
var skPaintFilter = SkiaUtil.SetFilter(skCanvas, svgCircle, _disposable);
SkiaUtil.SetTransform(skCanvas, matrix);

if (svgCircle.Fill != null)
{
    var skPaintFill = SkiaUtil.GetFillSKPaint(svgCircle, _skSize, bounds, _disposable);
    skCanvas.DrawCircle(cx, cy, radius, skPaintFill);
}

if (svgCircle.Stroke != null)
{
    var skPaintStroke = SkiaUtil.GetStrokeSKPaint(svgCircle, _skSize, bounds, _disposable);
    skCanvas.DrawCircle(cx, cy, radius, skPaintStroke);
}

if (skPaintFilter != null)
{
    skCanvas.Restore();
}

if (skPaintOpacity != null)
{
    skCanvas.Restore();
}

skCanvas.Restore();

When we would have spitted processing of documents from the rendering of them each SvgElement would implement simple interface with Draw method:

void Draw(object canvas, ISvgRenderer renderer)

Currently I have to have this ugly hack method as I did not wan;t to change Svg library yet:

private void Draw(object canvas, SvgElement svgElement)
{
    // HACK: Normally 'SvgElement' object itself would call appropriate 'Draw' on current render.
    switch (svgElement)
    {
        case SvgFragment svgFragment:
            DrawFragment(canvas, svgFragment);
            break;
        case SvgImage svgImage:
            DrawImage(canvas, svgImage);
            break;
        case SvgSwitch svgSwitch:
            DrawSwitch(canvas, svgSwitch);
            break;
        case SvgUse svgUse:
            DrawUse(canvas, svgUse);
            break;
        case SvgForeignObject svgForeignObject:
            DrawForeignObject(canvas, svgForeignObject);
            break;
        case SvgCircle svgCircle:
            DrawCircle(canvas, svgCircle);
            break;
        case SvgEllipse svgEllipse:
            DrawEllipse(canvas, svgEllipse);
            break;
        case SvgRectangle svgRectangle:
            DrawRectangle(canvas, svgRectangle);
            break;
        case SvgMarker svgMarker:
            DrawMarker(canvas, svgMarker);
            break;
        case SvgGlyph svgGlyph:
            DrawGlyph(canvas, svgGlyph);
            break;
        case SvgGroup svgGroup:
            DrawGroup(canvas, svgGroup);
            break;
        case SvgLine svgLine:
            DrawLine(canvas, svgLine);
            break;
        case SvgPath svgPath:
            DrawPath(canvas, svgPath);
            break;
        case SvgPolyline svgPolyline:
            DrawPolyline(canvas, svgPolyline);
            break;
        case SvgPolygon svgPolygon:
            DrawPolygon(canvas, svgPolygon);
            break;
        case SvgText svgText:
            DrawText(canvas, svgText);
            break;
        case SvgTextPath svgTextPath:
            DrawTextPath(canvas, svgTextPath);
            break;
        case SvgTextRef svgTextRef:
            DrawTextRef(canvas, svgTextRef);
            break;
        case SvgTextSpan svgTextSpan:
            DrawTextSpan(canvas, svgTextSpan);
            break;
        default:
            break;
    }
}

Please note that I have not yet implement drawing for some element, so there might be some changes, this is just some ideas from my work with Svg.Skia.

wieslawsoltes · 2019-11-10T11:41:25Z

I might add that I have some experience with abstracting rendering interfaces in my other projects:

One example is my Core2D drawing application:
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Model/Renderer/IShapeRenderer.cs#L12
and the custom renderers implementations:
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Renderer.Avalonia/AvaloniaRenderer.cs#L24
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Renderer.Dxf/DxfRenderer.cs#L24
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Renderer.PdfSharp/PdfSharpRenderer.cs#L19
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Renderer.SkiaSharp/SkiaSharpRenderer.cs#L20
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Renderer.WinForms/WinFormsRenderer.cs#L21
https://github.com/wieslawsoltes/Core2D/blob/86dc381798f5fbd03fb24fe0bc1e9f687f45ef80/src/Core2D.Renderer.Wpf/WpfRenderer.cs#L25

wieslawsoltes · 2019-11-10T11:45:53Z

Also for reference regarding usage of SkiaSharp, I have created recently pretty advanced drawing application based on SkiaSharp. Much of inspiration and design of Svg.Skia is based on this project as the Svg.Skia was meant to be used in my Draw2D app.

https://github.com/wieslawsoltes/Draw2D/blob/cc147f6b2980c391a610e27b505c9f664e4ea02d/src/Draw2D.Skia/Renderers/SkiaShapeRenderer.cs#L13

https://github.com/wieslawsoltes/Draw2D/blob/cc147f6b2980c391a610e27b505c9f664e4ea02d/src/Draw2D.Skia/SkiaHelper.cs#L23

wieslawsoltes · 2019-11-10T11:51:11Z

Here is current Svg.Skia implementation with above mentioned interface:

The SkiaUtil class is most important part of Svg.Skia code base. Basically here the Svg drawing model is translated to SkiaSharp way of drawing (except few things done in renderer class).

tebjan · 2019-11-10T19:26:39Z

You can see in all cases I am passing drawing context object canvas as object.

In each the draw method I am casting drawing context canvas to appropriate SkiaSharp canvas (it can be Graphics object when using System.Drawing).
if (!(canvas is SKCanvas skCanvas))
{
    return;
}

i'm wondering why you use object here? you could use ISvgCanvas with different implementations or just leave the parameter out. and pass an ISvgRenderer that manages the canvas.

wieslawsoltes · 2019-11-10T19:31:32Z

You can see in all cases I am passing drawing context object canvas as object.
In each the draw method I am casting drawing context canvas to appropriate SkiaSharp canvas (it can be Graphics object when using System.Drawing).
if (!(canvas is SKCanvas skCanvas))
{
    return;
}
i'm wondering why you use object here? you could use ISvgCanvas with different implementations or just leave the parameter out. and pass an ISvgRenderer that manages the canvas.

@tebjan

The idea is for all drawable Svg element to implement simple interface:

void Draw(object canvas, ISvgRenderer renderer);

example:

public class SvgCircle
{
    // ...
    public void Draw(object canvas, ISvgRenderer renderer)
    {
       renderer.DrawCircle(canvas, this);
    }
    // ...
}

tebjan · 2019-11-10T19:35:18Z

not sure if the canvas object is necessary, why not simply? or am i missing something?

public class SvgCircle
{
    // ...
    public void Draw(ISvgRenderer renderer)
    {
       renderer.DrawCircle(this);
    }
    // ...
}

wieslawsoltes · 2019-11-10T19:37:13Z

not sure if the canvas object is necessary, why not simply? or am i missing something?

public class SvgCircle
{
    // ...
    public void Draw(ISvgRenderer renderer)
    {
       renderer.DrawCircle(this);
    }
    // ...
}

Than you have to initialize ISvgRenderer implementation with canvas. In my experience I prefer to pass canvas as object and just cast to appropriate drawing context.

wieslawsoltes · 2019-11-10T19:38:16Z

The canvas in SkiaSharp is short-lived, but renderer can persist longer.

tebjan · 2019-11-10T19:40:37Z

before drawing renderer.BeginDraw() and after renderer.EndDraw() in those methods each renderer implementation can do what's necessary. then you can do svgDoc.Draw(renderer) and in Draw begin and end is called on the interface. this is cleaner design of the abstraction, i think, This also avoids the casting in each method.

wieslawsoltes · 2019-11-10T19:44:47Z

usually you have some drawing context that is used for drawing like SKCanvas in SkiaSharp and Graphics in System.Drawing that's why I like to pass object canvas as parameter

not sure how this would work in your example

wieslawsoltes · 2019-11-10T19:48:51Z

@tebjan ok I will update my proposal shortly, just need to test 😄

tebjan · 2019-11-10T19:57:30Z

using (var renderer = new SKSvgRenderer(skSize))
using (var skPictureRecorder = new SKPictureRecorder())
using (var skCanvas = skPictureRecorder.BeginRecording(cullRect))
{
    renderer.DrawFragment(skCanvas, svgFragment);
    return skPictureRecorder.EndRecording();
}

would become

//fields
SkCanvas canvas;
SKPictureRecorder skPictureRecorder;
...

//Begin
skPictureRecorder = new SKPictureRecorder())
skCanvas = skPictureRecorder.BeginRecording(cullRect))

//Draw
skCanvas.DrawSomething()

//End
canvas.Dispose()
skPictureRecorder.Dispose()
....

//and in SvgDocument.Draw(renderer)
try
{
    renderer.BeginDraw()
    renderer.Draw(this);
}
finally
{
    render.EndDraw()
}

wieslawsoltes · 2019-11-10T19:58:44Z

@tebjan ok I have refactored renderer interface in Svg.Skia and it working

public interface ISvgRenderer : IDisposable
{
    void DrawFragment(SvgFragment svgFragment);
    void DrawImage(SvgImage svgImage);
    void DrawSwitch(SvgSwitch svgSwitch);
    void DrawSymbol(SvgSymbol svgSymbol);
    void DrawUse(SvgUse svgUse);
    void DrawForeignObject(SvgForeignObject svgForeignObject);
    void DrawCircle(SvgCircle svgCircle);
    void DrawEllipse(SvgEllipse svgEllipse);
    void DrawRectangle(SvgRectangle svgRectangle);
    void DrawMarker(SvgMarker svgMarker);
    void DrawGlyph(SvgGlyph svgGlyph);
    void DrawGroup(SvgGroup svgGroup);
    void DrawLine(SvgLine svgLine);
    void DrawPath(SvgPath svgPath);
    void DrawPolyline(SvgPolyline svgPolyline);
    void DrawPolygon(SvgPolygon svgPolygon);
    void DrawText(SvgText svgText);
    void DrawTextPath(SvgTextPath svgTextPath);
    void DrawTextRef(SvgTextRef svgTextRef);
    void DrawTextSpan(SvgTextSpan svgTextSpan);
}

sample usage:

float width = svgFragment.Width.ToDeviceValue(null, UnitRenderingType.Horizontal, svgFragment);
float height = svgFragment.Height.ToDeviceValue(null, UnitRenderingType.Vertical, svgFragment);
var skSize = new SKSize(width, height);
var cullRect = SKRect.Create(skSize);
using (var skPictureRecorder = new SKPictureRecorder())
using (var skCanvas = skPictureRecorder.BeginRecording(cullRect))
using (var renderer = new SKSvgRenderer(skCanvas, skSize))
{
    renderer.DrawFragment(svgFragment);
    return skPictureRecorder.EndRecording();
}

paolofulgoni · 2019-11-12T10:28:52Z

@wieslawsoltes

When we would have spitted processing of documents from the rendering of them each SvgElement would implement simple interface with Draw method

If we split the library, then the new manipulation-only library shouldn't have any method related to drawing.

I think it's not so bad to have those methods in the ISvgRenderer interface. But maybe I'm missing something...

Another option could be the extension methods, such as:

public static class SvgCircleExtensions
{
    public void Draw(this SvgCircle svgCircle, object canvas, ISvgRenderer renderer)
    { }
}

wieslawsoltes · 2019-11-12T10:47:55Z

@wieslawsoltes

When we would have spitted processing of documents from the rendering of them each SvgElement would implement simple interface with Draw method

If we split the library, then the new manipulation-only library shouldn't have any method related to drawing.

I think it's not so bad to have those methods in the ISvgRenderer interface. But maybe I'm missing something...

Another option could be the extension methods, such as:
public static class SvgCircleExtensions
{
    public void Draw(this SvgCircle svgCircle, object canvas, ISvgRenderer renderer)
    { }
}

The renderer interface depends on backanends and functionality needed to implement complete and correct rendering of supported SVG specification (or parts of spec.).

Each rendering backend (e.g. Gdi, SkiaSharp etc.) have different concepts and may require some additional abstraction in renderer. For example how do you handle transforms, layer, clipping etc..

In my library for now (as its not complete) I have abstract all of internals and above interface in enough, but in my experience it may require some tweaks.

tebjan · 2019-11-12T13:06:47Z

public interface ISvgRenderer : IDisposable
{
    void DrawFragment(SvgFragment svgFragment);
    void DrawImage(SvgImage svgImage);
    void DrawSwitch(SvgSwitch svgSwitch);
    void DrawSymbol(SvgSymbol svgSymbol);
    void DrawUse(SvgUse svgUse);
    void DrawForeignObject(SvgForeignObject svgForeignObject);
    void DrawCircle(SvgCircle svgCircle);
    void DrawEllipse(SvgEllipse svgEllipse);
    void DrawRectangle(SvgRectangle svgRectangle);
    void DrawMarker(SvgMarker svgMarker);
    void DrawGlyph(SvgGlyph svgGlyph);
    void DrawGroup(SvgGroup svgGroup);
    void DrawLine(SvgLine svgLine);
    void DrawPath(SvgPath svgPath);
    void DrawPolyline(SvgPolyline svgPolyline);
    void DrawPolygon(SvgPolygon svgPolygon);
    void DrawText(SvgText svgText);
    void DrawTextPath(SvgTextPath svgTextPath);
    void DrawTextRef(SvgTextRef svgTextRef);
    void DrawTextSpan(SvgTextSpan svgTextSpan);
}

i would even simplify this into:

public interface ISvgRenderer : IDisposable
{
      void DrawElement(SvgBaseClass svgElement);
}

in general it's good to keep interfaces as small as possible.

you can then have this switch in the DrawElement:

public void DrawElement(SvgElement svgElement)
{
    switch (svgElement)
    {
        case SvgFragment svgFragment:
            DrawFragment(canvas, svgFragment);
            break;
        case SvgImage svgImage:
            DrawImage(canvas, svgImage);
            break;
        case SvgSwitch svgSwitch:
            DrawSwitch(canvas, svgSwitch);
            break;
        case SvgUse svgUse:
            DrawUse(canvas, svgUse);
            break;
        case SvgForeignObject svgForeignObject:
            DrawForeignObject(canvas, svgForeignObject);
            break;
        case SvgCircle svgCircle:
            DrawCircle(canvas, svgCircle);
            break;
        case SvgEllipse svgEllipse:
            DrawEllipse(canvas, svgEllipse);
            break;
        case SvgRectangle svgRectangle:
            DrawRectangle(canvas, svgRectangle);
            break;
        case SvgMarker svgMarker:
            DrawMarker(canvas, svgMarker);
            break;
        case SvgGlyph svgGlyph:
            DrawGlyph(canvas, svgGlyph);
            break;
        case SvgGroup svgGroup:
            DrawGroup(canvas, svgGroup);
            break;
        case SvgLine svgLine:
            DrawLine(canvas, svgLine);
            break;
        case SvgPath svgPath:
            DrawPath(canvas, svgPath);
            break;
        case SvgPolyline svgPolyline:
            DrawPolyline(canvas, svgPolyline);
            break;
        case SvgPolygon svgPolygon:
            DrawPolygon(canvas, svgPolygon);
            break;
        case SvgText svgText:
            DrawText(canvas, svgText);
            break;
        case SvgTextPath svgTextPath:
            DrawTextPath(canvas, svgTextPath);
            break;
        case SvgTextRef svgTextRef:
            DrawTextRef(canvas, svgTextRef);
            break;
        case SvgTextSpan svgTextSpan:
            DrawTextSpan(canvas, svgTextSpan);
            break;
        default:
            break;
    }
}

tebjan · 2019-11-12T13:09:48Z

If we split the library, then the new manipulation-only library shouldn't have any method related to drawing.

the question is then, who is responsible for traversing the element tree correctly and calling the draw methods? the render library shouldn't have to do that, since it is the same for all rendering backends.

paolofulgoni · 2019-11-12T13:21:43Z

the question is then, who is responsible for traversing the element tree correctly and calling the draw methods? the render library shouldn't have to do that, since it is the same for all rendering backends.

In this case, the manipulation library should expose methods to traverse the elements tree. But still it is something not strictly related to rendering.

I mean, the traversal methods shouldn't have any IRenderer parameter. It's the renderer itself to traverse the tree and do the job.

mrbean-bremen · 2019-11-12T13:41:25Z

Agreed. A generic traversal method shall probably live in the manipulation library and be called from the renderer.
We could pass it a generic delegate that can be used to do the drawing, or put the recursive drawing code in some rendering base class, that uses the interface for drawing.

paolofulgoni · 2019-11-12T14:14:12Z

I see there has been another attempt to use SkiaSharp for rendering in #291

paolofulgoni · 2019-11-12T21:27:48Z

Back to my question in a previous comment: should we maintain backward compatibility after the lib split?
I would say no, as there are methods which are tightly coupled with the current GDI rendering, such as:

public GraphicsPath Path(ISvgRenderer renderer);
protected void Render(ISvgRenderer renderer);

One option could be to extend the classes of the manipulation-only library in the GDI rendering library to add those methods, but is it worthwhile?

paolofulgoni · 2019-11-12T21:43:21Z

oh, interesting, this is a WPF-based rendering: https://github.com/ElinamLLC/SharpVectors

wieslawsoltes · 2019-11-13T11:52:04Z

Back to my question in a previous comment: should we maintain backward compatibility after the lib split?
I would say no, as there are methods which are tightly coupled with the current GDI rendering, such as:
public GraphicsPath Path(ISvgRenderer renderer);
protected void Render(ISvgRenderer renderer);
One option could be to extend the classes of the manipulation-only library in the GDI rendering library to add those methods, but is it worthwhile?

Also we should consider if we want/can remove dependency from System.Drawing, and it's not just rendering part, also processing part may be affected.

dittodhole · 2019-11-13T14:19:29Z

This change would be awesome!

Given that rendering isn't based on GDI, I would happily migrate my contrib-project (https://github.com/dittodhole/dotnet-Svg.Contrib.Render) on that new approach :)

paolofulgoni · 2019-11-13T21:56:52Z

Also we should consider if we want/can remove dependency from System.Drawing, and it's not just rendering part, also processing part may be affected.

From my point of view, reducing the dependencies as much as possible is a goal.

gvheertum · 2019-11-20T07:30:33Z

Nice work all. When creating this item I thought it would take a while and it was something nice to have in the future. Seeing you all working on this item and seeing the results I am really amazed, nice work!

(nothing really to add to the ticket itself, and unfortunately I'm a bit swamped at the moment, so I am also not able to help in the development, but just wanted to say I really love the work that's happening 😄 )

Almis90 · 2019-11-20T08:01:49Z

Also we should consider if we want/can remove dependency from System.Drawing, and it's not just rendering part, also processing part may be affected.

I think it's very important to remove dependency of System.Drawing. UWP doesn't support System.Drawing, for some Xamarin developers (as myself) that would be a problem.

alexeid1337 · 2019-11-27T16:46:09Z

@wieslawsoltes

I salute you for your effort, and I believe it's the correct choice. SVG library is great for working with SVG tree, SkiaSharp is great for rendering. Should we have the bridge between them - awesome.

Recently I've been busy with the task of parsing big SVG files, updating and displaying them live based on some conditions (updating mostly includes property changes, like "fill", "stroke", "display", etc.)
So far I had to settle down with updating SvgDocument tree, converting SvgDocument to bitmap, then to bitmap stream, then to SKBitmap, to paint it to SKCanvas later. But this solution has its cons, plus it's not really great performance wise.
So I've tried Skia.Svg, and it worked great. I'm using the "FromSvgDocument" method and converting SKPicture to SKImage, to paint it to SKCanvas later. This solution is much-much more performant. Plus I get better image quality (especially with texts, which are much more crisp with Skia).
The downside is the library is not production-ready (which I can see in the source code), not all the styles are supported (from the first glance, "display" style isn't used, some text styles too), etc. But still it's a great magnitude of work in such a small time, you're doing great, sir. When I get some spare time in the following weeks, I sincerely hope to contribute to the case too.

paolofulgoni · 2019-11-27T21:54:02Z

@wieslawsoltes wrote:

Also we should consider if we want/can remove dependency from System.Drawing, and it's not just rendering part, also processing part may be affected.

Yes, unfortunately the processing part depends on System.Drawing too.

Here are some examples:

SvgPath is based on System.Drawing.Drawing2D.GraphicsPath
Many classes and interfaces use primitives such as PointF, RectangleF, etc.
The colors are based on System.Drawing.Color

So removing the System.Drawing dependency looks quite hard to me... 😞
It may be a second step to do later

Almis90 · 2019-11-30T22:16:45Z

I got it partially working on UWP with Xamarin.Forms

Made new build of this library but replaced everywhere System.Drawing* with System.DrawingCore* (https://github.com/zkweb-framework/ZKWeb.System.Drawing)
Updated Fizzler to 1.2.0
Made new build of Svg.Skia that reference the new build of this library
And finally used SkiaSharp to render the picture that was made from Svg.Skia

I used 12mb file, didn't notice any performance issue but it was missing the fill colors.

As you can see the library is deprecated now but maybe someone can resurrect it again and continue supporting it? at least only for platforms that don't support System.Drawing.

chucker · 2019-12-05T21:47:40Z

Yes, unfortunately the processing part depends on System.Drawing too.

Here are some examples:

SvgPath is based on System.Drawing.Drawing2D.GraphicsPath

Many classes and interfaces use primitives such as PointF, RectangleF, etc.

The colors are based on System.Drawing.Color

So removing the System.Drawing dependency looks quite hard to me... 😞
It may be a second step to do later

Note that System.Drawing.Primitives exists as a separate package, and does include Color, PointF, etc.

Not GraphicsPath, though.

And SkiaSharp comes with its own incompatible set of primitives regardless, so maybe that isn't going to help.

yoshiask · 2020-05-16T07:20:31Z

It's been a few months now, are there any updates on this?

AraHaan · 2021-11-06T01:41:52Z

I am tempted myself to make another fork of this, and decouple from System.Drawing using stuff like:

public struct SvgColor
{
    // alpha component of this color.
    public int A { get; set; }
    // Red component of this color.
    public int R { get; set; }
    // green component of this color.
    public int G { get; set; }
    // blue component of this color.
    public int B { get; set; }
}

// struct that simulates a pixel in an rasterized image (basically it simulates using System.Drawing to "rasterize" it)
public struct SvgPixel
{
    public SvgColor Color { get; set; }
    public int Location { get; set; }
}

public struct SvgBitmap
{
    public SvgPixel[] Pixels { get; set; }
}

Only issue however would be converting each thing to SvgPixel instances for an instance of SvgBitmap. But I am trying to find a way to return the information that they would need to then implement the rendering themselves.

mrbean-bremen added enhancement platform-support labels Oct 17, 2019

tebjan mentioned this issue Nov 9, 2019

Try drawing with Svg.Skia #607

Closed

tebjan mentioned this issue Nov 9, 2019

Join forces with SVG.NET? mono/SkiaSharp.Extended#87

Closed

tebjan pinned this issue Nov 12, 2019

charlesroddie mentioned this issue Nov 25, 2019

[QUESTION] What is the status of the svg nuget package? mono/SkiaSharp.Extended#68

Closed

wieslawsoltes mentioned this issue Feb 10, 2020

Enable checking if PatternUnits or PatternContentUnits was actually set #669

Merged

paolofulgoni mentioned this issue Feb 11, 2020

Write SVG file UkooLabs/SVGSharpie#2

Open

mrbean-bremen mentioned this issue Aug 23, 2021

Filters (e.g. Gaussian blur) do not work #43

Open

mrbean-bremen mentioned this issue Jan 6, 2022

Enable building code without System.Drawing.Common dependency #931

Merged

This was referenced Jan 6, 2022

Split drawing code into separate files #934

Merged

Split drawing code into separate project #937

Closed

Consider splitting rendering and processing #590

Consider splitting rendering and processing #590

Comments

gvheertum commented Oct 15, 2019

wieslawsoltes commented Nov 6, 2019

mrbean-bremen commented Nov 6, 2019

wieslawsoltes commented Nov 6, 2019 • edited Loading

mrbean-bremen commented Nov 7, 2019

tebjan commented Nov 9, 2019

paolofulgoni commented Nov 9, 2019

paolofulgoni commented Nov 9, 2019

wieslawsoltes commented Nov 9, 2019

paolofulgoni commented Nov 9, 2019

wieslawsoltes commented Nov 10, 2019

Step 1 - load document

Step 2 - draw using SKCanvas

wieslawsoltes commented Nov 10, 2019

wieslawsoltes commented Nov 10, 2019

wieslawsoltes commented Nov 10, 2019

Rendering interface ISvgRenderer

SkiaSharp Rendering interface implementation

Utilities for SkiaSharp

tebjan commented Nov 10, 2019

wieslawsoltes commented Nov 10, 2019

tebjan commented Nov 10, 2019

wieslawsoltes commented Nov 10, 2019

wieslawsoltes commented Nov 10, 2019

tebjan commented Nov 10, 2019 • edited Loading

wieslawsoltes commented Nov 10, 2019

wieslawsoltes commented Nov 10, 2019

tebjan commented Nov 10, 2019 • edited by mrbean-bremen Loading

wieslawsoltes commented Nov 10, 2019

paolofulgoni commented Nov 12, 2019

wieslawsoltes commented Nov 12, 2019

tebjan commented Nov 12, 2019

tebjan commented Nov 12, 2019

paolofulgoni commented Nov 12, 2019

mrbean-bremen commented Nov 12, 2019

paolofulgoni commented Nov 12, 2019

paolofulgoni commented Nov 12, 2019

paolofulgoni commented Nov 12, 2019

wieslawsoltes commented Nov 13, 2019 • edited Loading

dittodhole commented Nov 13, 2019

paolofulgoni commented Nov 13, 2019

gvheertum commented Nov 20, 2019 • edited Loading

Almis90 commented Nov 20, 2019

alexeid1337 commented Nov 27, 2019

paolofulgoni commented Nov 27, 2019

Almis90 commented Nov 30, 2019

chucker commented Dec 5, 2019

yoshiask commented May 16, 2020

AraHaan commented Nov 6, 2021 • edited Loading

wieslawsoltes commented Nov 6, 2019 •

edited

Loading

Rendering interface `ISvgRenderer`

tebjan commented Nov 10, 2019 •

edited

Loading

tebjan commented Nov 10, 2019 •

edited by mrbean-bremen

Loading

wieslawsoltes commented Nov 13, 2019 •

edited

Loading

gvheertum commented Nov 20, 2019 •

edited

Loading

AraHaan commented Nov 6, 2021 •

edited

Loading