Fast UI Draw is a library that provides a higher performance Canvas interface
github.com
github.com
Furthermore they have some bad incentives around portability.
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.
Just that ‘use skia’ isn’t a particularly good answer either.
I’m somewhat dismayed that Linux doesn’t seem to have a solid 2d graphics library.
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.
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?
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.
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.
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's referring to that broad concept, not a specific Canvas interface.
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.
This is not about HTML5 Canvas vs something WebGL based.
A browser could theoretically use this tough to implement Canvas elements. See this issue: https://github.com/intel/fastuidraw/issues/50
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.
That said, a video demonstrating the performance difference would be nice.