Note that this has been practically unmaintained since Kevin Rogovin (fastuidraw's principal author) left Intel. It's also very suspect, my recollection from testing it before is that it was not up to the quality and fidelity standards of other libraries.
They wouldn't, IMO. Skia is robust, has a large feature set, has exhaustive automated tests, is well maintained, and portable. Even if this library is "faster" (for its specific use cases), Skia is well optimized and used in lots of performance-sensitive software.
I concur. The documentation is very incomplete. I know it can do a lot of stuff, but I wouldn’t know how to make it do it. It doesn’t seem to be intended for wide use, more like “here’s what we use, it’s open source, do whatever, but we’re not going to help you.”
Fair criticisms but it's not like Fast UI Draw is any different on any of those. Unless you're calling its API stable because the library has been abandoned, but in that case you could also just never update your copy of Skia, too.
As a Linux user, it unfortunately doesn't have a definitive anything.
Say you want to write a GUI app.
On Windows, you've got Win32. It's old, but it'll still work and look new.
MacOS you have Cocoa.
Linux, you have Xlib. Wait, that doesn't provide enough. We have to use a toolkit, like Gtk or Qt. Which one if we want to look integrated? How do we integrate 3D APIs?
Then there's Wayland. You want to use that instead because X is deprecated. But there's no extensive API--it's basically only a way of putting rectangles on the screen. You have nothing to get you started unless you stick hard to Gtk, Qt, or do really rudimentary graphics, and cross-compatibility is really ugly.
A few years ago there was talk of the Cairo API (not necessarily the Cairo library implementation of that API) being adopted as part of a C language standard.
That seems not to have happened. Consequently, if you program in C or in a language that depends on C libraries to get stuff done, there's still no go-to library/API for 2D drawing.
Also, the scope of "2d graphics" is not fixed either. Does it include a scene graph or not?
Cairo is great, but apparently “dead”. I absolutely grant that Cairo would be fine.
Skia works well but has an unstable api, hard to interested build, and limited language bindings, is poorly documented and is controlled/developed by Google.
QT has a giant set of dependencies and no independent graphics library.
Note that the test scene would benefit heavily from draw batching, but was setup in such a way that may have just defeated the batching logic in Skia but not the one in FastUIDraw.
It wasn't a very common UI scene, so it wouldn't be expected that other libraries had optimizations for that type of content (specifically with the "everything is slightly rotated" part)
It was also a scene that curiously didn't involve any paths or shapes other than rectangles, which is where GPU-accelerated canvas' all really run into trouble.
Also note that the presentation was from 2016, and many of these libraries (such as Skia) see heavy ongoing work so that data is all quite outdated and unreliable at this point.
Afaik a canvas interface is where you draw to a bitmap by issuing calls in a procedural style (eg web canvas, cairo graphics etc). This is in contrast to vector graphics where you build an object hierarchy to be rendered.
Vector graphics: drawing stuff by issuing commands to render specific simple geometric elements (lines, rects, triangles, circles)
Canvas: a context in which to place "objects" in 3 dimensions (x, y and z), and have them appropriately re-rendered when necessary (motion, object addition/removal)
It seems to refer to the "rendering backend" used to paint user interfaces, as in actual/native elements.
The PDF linked to by @DuncanMak compares it performance-wise to things like Cairo (the canvas library used by GTK+), Qt Raster, and SKIA GL). It seems to perform very well in comparison.
The standard Canvas API is probably your best option. So if some library claims to have better performance than Canvas 2D, I would love to see a benchmark on that. Anyone would assume WebGL is faster, but as you know "assumption is the mother of all fuckups". Let me explain.
A year ago, I had to make a proof of concept for drawing Gantt charts on a Canvas. Coming from a game development background, my assumption was that some things would be too slow on a canvas:
- rotating graphics
- drawing an insane amount of rectangles
- filling surfaces with a certain repeating texture
So I also included a benchmark of Canvas vs WebGL. The conclusion was that for most things, Canvas was faster:
- rotating graphics
- texturizing
- etc.
This really amazed me, because as an old school game developer, I know all limitations of 2D rendering. The thing is, all modern browsers heavily optimize their Canvas to the GPU. Even the older Edge. Do some heavy Canvas 2D drawing, and see your GPU usage spikes.
Plus, rendering text on WebGL is not as straightforward.
However, there was a tipping point when drawing an insane amount of rectangles (which basically become dots), where WebGL would take over.
So for this project, the simplicity of the Canvas API, the text rendering, and the performance were definitely a sure way to use that one instead of a more complex, slower WebGL.
(Disclaimer: Not a lawyer, but a number of my projects are licensed under MPL)
As I read it, the only time the MPL requires you to share source code is when you modify files belonging to the MPL-covered library. Even then, it only requires you to share the changes you made to the library - you don't have to share any of your proprietary or non-MPL code.
From TL;DRLegal: "You must make the source code for any of your changes available under MPL, but you can combine the MPL software with proprietary code, as long as you keep the MPL code in separate files."
So - did you install a MPL library using a package manager like npm or pip? You do not have to share your project's code.
Did you copy/paste a MPL library into a /vendor/mpl-library/ directory? You do not have to share your projects code.
Did you copy/paste functions from a MPL library directly into your source code? In this case, you may have to share the file you pasted into, but not any other files in your project.
Overall, I think the MPL strikes a great balance between the "do what you want" crowd and the "people should give back to projects that help them" crowd, which is why it's my go-to license for most libraries these days.
From my understanding, it's not a UI library but a library to make UI libraries with; therefore, it does not have any visual / interaction design or anything clickable to work with.
That said, a video demonstrating the performance difference would be nice.
Sorry, I included the Acid tests as an example of demonstrating tricky situations—not that this should be implementing the acid tests themselves. So like, what is the equivalent of the Acid tests for drawing libraries?
