State of chromium integration about fastuidraw HOT 2 OPEN

Bunch of answers:

• The best way to integrate FastUIDraw into Chromium is to create a SKIA backend that maps to FastUIDraw. That work is essentially in the very, very early planning stages.
• Right now the only way to benchmark FastUIDraw is to create a demo and port that demo to each of the 2D renderers to benchmark against. As of now, the only benchmark that this is really done is for painter-cells that is ported to SKIA, Cairo at Qt's QPainter. However, that branch has gone a touch stale and needs to be updated too.
• At this point in time, there have been no benchmarks on power consumption.
• There is a proof of concept project at https://github.com/krogueintel/qtwebkit.fastuidraw/tree/5.212.fastuidraw-QOpenGLWidget that uses FastUIDraw to implement (most) of GraphicsContext of a quite old WebKit branch. The proof-of-concept though has some bugs and integration issues. These issues mostly stem from that it has both Qt's QPainter and FastUIDraw rendering supported and there are quite a few a square pegs mashed into round holes. Again, it is just proof of concept to demonstrate that FastUIDraw can draw what is needed to draw web-content.
• FastUIDraw supports stroking and filling of paths. For filling paths it goes beyond the standard odd-even, non-zero fill rules and their complements to support any arbitrary fill rule.
• FastUIDraw has first class support for rendering text with the GPU, see the classes GlyphSequence and GlyphRun along with GlyphRenderer
• CSS is essentially a bunch of rules and syntax to specify how to format and where to draw stuff. That belongs firmly in the world of a web-engine. FastUIDraw is for drawing only and is (hopefully) one day to be used by a major web-engine.

Roadmap is fuzzy some since 1.0 was the main target. However, there are some features and bits I'd like to do:

• Add a PainterSurface derived class that draws directly to the framebuffer of the window.
• Look into supporting MSAA. Currently, FastUIDraw has very high quality shader-based anti-aliasing for filling, stroking and rendering text. However, for some platforms, it might be better to not do shader based anti-aliasing and instead rely on MSAA.
• Optimize creating of FilledPath. A FilledPath represents all the data needed to fill a path against any fill rule. The catch is that it needs to triangulate a path and this is quite CPU expensive. Analysis indicates that lots of the cost comes from malloc/free pressure.
• Change how path filling does anti-aliasing. Currently, anti-aliasing of path fill's is done by drawing (essentially) a one pixel smudge around the boundary. This induces overdraw and when the path is drawn small also induces bleeding. In addition, how the anti-alias smudge is drawn is not really ideal because it uses up offscreen buffer area more than I'd like.
• Implement shader-based clipping anti-aliasing. Although FastUIDraw has shader based anti-aliasing for paths fill, path strokes and text rendering, it does not have shader based anti-aliasing for clip_in and clip_out.
• Consider implementing a Metal backend in FastUIDraw. Apple marked OpenGL as deprecated so for FastUIDraw to work reliably on Apple devices, means a Metal backend is the way to go. Indeed at this point, Apple platform is not even officially supported.

And the biggest item: implement a SKIA backend mapping to FastUIDraw which means filling in gaps in features and interfaces that such work would expose.

from fastuidraw.

Thanks for the Update! For providing support for Apple, would moltenVK be a valid option? It is now under the Khronos umbrella after all. If it is, investing in a Vulkan backend with moltenVK on top for Apple might make more sense to spend ressources on than on a solely Apple-focused API implementation.

from fastuidraw.