Use Skia Canvas instead of Surface where possible

[therealbnut]

Hey, I've made some changes to allow you to use Skia's Canvas wherever possible. This allows you to use resvg with PDFs 🎉.

https://skia.org/user/api/skcanvas_creation

The SkPDF backend uses SkDocument instead of SkSurface, since a document must include multiple pages.

Something like this:

let pdf_doc = skia::PDF::make_document(&pdf_stream);
let pdf_canvas = pdf_doc.begin_page(width, height);
resvg::backend_skia::render_to_canvas(&tree, &opt, size, pdf_canvas);

[RazrFalcon]

Well, it will create a pretty horrible PDF. There are plans on making a proper PDF target, but it will not be implemented any time soon.

As for the patch, C-API should be updated too. It requires Surface right now.

[RazrFalcon]

I've added a check for Skia C-API build. Turns out it was missing.

[therealbnut]

Well, it will create a pretty horrible PDF.

We're using it to render just graphics. Text, links and other things we do directly with Skia. It works really well, thank you for the awesome library!

I've just pushed a commit to update the Skia C-API.

I don't have a machine that can run ./testing-tools/run-tests.py, hopefully travis doesn't run into any issues :)

[RazrFalcon]

We're using it to render just graphics.

I see. As long as you are fine with results - it's ok. I just wanted to point out that it's quite limited. Especially when you have text and layers. But as long as you only have shapes without opacity - you should be fine.

[therealbnut]

I just wanted to point out that it's quite limited. Especially when you have text and layers.

Thanks for the info! We don't have text, although perhaps we will run into opacity, I guess if we can detect that we might rasterise those cases.

[RazrFalcon]

I think that build will fail, because there are no skia::Canvas::from_ptr. You should add

     pub unsafe fn from_ptr(ptr: *mut ffi::skiac_canvas) -> Option<Canvas> {
        if ptr.is_null() {
            None
        } else {
            Some(Canvas(ptr))
        }
    }

to the Canvas implementation in bindings/resvg-skia/src/lib.rs

[RazrFalcon]

@JaFenix Hi! Is this change fine for you? resvg_skia_render_to_canvas will accept a Canvas and not a Surface from now.

[therealbnut]

pub unsafe fn from_ptr(ptr: *mut ffi::skiac_canvas) -> Option {

Ah, good catch, thanks. I didn't realise I had to cd into capi/ when running cargo build to build it too, I thought it was part of the workspace.

[therealbnut]

@RazrFalcon what do you think about adding something like this:

typedef struct sk_canvas_t sk_canvas_t;

(matching their offical C API https://github.com/google/skia/blob/master/include/c/sk_types.h#L153)

 void resvg_skia_render_to_canvas(const resvg_render_tree *tree,
                                   const resvg_options *opt,
                                   resvg_size size,
-                                  void *canvas);
+                                  skia_canvas_t * canvas);

So at the call site you might know at compile time about a type mismatch.

[RazrFalcon]

It's C. The are not compile time guaranties. And you would call resvg via C++ anyway, so there is no difference.

[therealbnut]

Sorry about the failed builds. I'm having trouble running the tests locally, or building anything except the main package. Do they only work on linux?

[RazrFalcon]

No problem.

No, they should work on any platform.

[therealbnut]

Awesome, thanks for reviewing 🎉

I suppose we can merge it once @JaFenix gives the okay?

[RazrFalcon]

Yes, he added the Skia backend initially and I do not want to break it for him.

[JaFenix]

Hi, I don't think this will break anything, because the surface instance that's passed in doesn't seem to be used for anything, other than to deliver a canvas. Changing our C++ caller to pass in the canvas won't be a problem. OK to merge 👌

[RazrFalcon]

Thanks for a quick response.