111–119 of 119 posts
Earlier quoted context omitted.
That's the first question that occurred to me so I web-searched. Seems it is faster and has a broader API. I sort of expected that Raph Levien(1) might have contributed or that Cairo would be part of the base of Skia. But apparently not. (1) works at Google and wrote Cairo
I did not write Cairo, I wrote libart, and that was a long time ago. I'm good friends with several of the Skia authors, but don't actively work on it myself.
I've used it to create a desktop port of http://diep.io/ . It's great (easy to use, reasonably documented), but it's a pretty big dependency (I don't remember exactly, but I think like 20 MB or so?). Since diep.io uses the canvas 2d API, porting was pretty straight forward. The performance on desktop is unsurprisingly many times faster than the browser.
What motivated your choice of Skia over WebGL?
Earlier quoted context omitted.
This can't be intentional, right?
Google does not seem interested in making the NDK anything more than implementing Java native methods, 3D graphics, audio or porting code from other platforms. Everything else should be done at Java level. I understand from the point of view of security, but what is safer, provide bindings to libraries already validated and installed on the device or forcing devs to package something else? Also even though they imple…
It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries. They're a bit bigger (may God provide mercy, and huge amounts of free diskspace to those fools that enable debug), but the odds of them working flawless on a given device are much higher.
Earlier quoted context omitted.
Google does not seem interested in making the NDK anything more than implementing Java native methods, 3D graphics, audio or porting code from other platforms. Everything else should be done at Java level. I understand from the point of view of security, but what is safer, provide bindings to libraries already validated and installed on the device or forcing devs to package something else? Also even though they imple…
Java APIs ARE C APIs, for obvious reasons. There doesn't have to be any difference in security. It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries. They're a bit bigger (may God provide mercy, and huge amounts of free diskspace to those fools that enable debug), but the odds of them working flawless on a given device are much higher.
You lost me there. I wouldn't call JNI boilerplate a C API.
> It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries.
Polyglot dev here, including C and C++.
The way a library is linked is orthogonal to be made available on the SDK.
Somehow the text it renders looks worse than all the other common graphics libraries on Linux - which all use FreeType and Harfbuzz. I am not sure what QtWebEngine does differently, because it uses Blink and the text looks fine.
"looks worse" is a pretty nebulous statement. Can you go into detail? Do you think text in Chrome looks bad?
Aseprite switched to Skia a year or so ago ( https://github.com/aseprite/aseprite ). Regret it. Google doesn't care to maintain CMake support for it, so there goes pulling it in via source and building as a library dependency. https://github.com/aseprite/aseprite/issues/1598#issuecommen... You may ask, "why don't you just write your own CMake module like everyone else?" I've tried. I think the build system changed a…
This looks really useful! Does anyone know how this compares to something like Cairo?
Note that Skia is a C++ library and does not provide a stable C API.
The roadmap needs to be updated. It's for 2016-2017.
Earlier quoted context omitted.
It's true. Google has essentially made it as painful as possible to use Skia outside of the google ecosystem. The build system is what's mostly kept me from using it in personal projects.
Xamarins wrapper for C# made it a breeze to use from C# at least - just add the package. The same is likely true for all ecosystems with reasonable package management. It’s only ironic that C++ libs are hardest to use from...C++