Hi, maybe it's not intended to run on OSX but for now the errors look mostly like C++ errors:

mac-pro:fastuidraw robby$ make demos-GL-release
c++ -O3 -fstrict-aliasing -Wall -Wextra -Wcast-qual -Wwrite-strings -Iinc `freetype-config --cflags` -std=c++11 -D_USE_MATH_DEFINES -fPIC -c src/fastuidraw/util/static_resource.cpp -o release/src/fastuidraw/util/static_resource.o
src/fastuidraw/util/static_resource.cpp:52:15: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>,
      std::__1::allocator<char> >'
  std::string sresource_label(presource_label);
              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:193:33: note: template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
src/fastuidraw/util/static_resource.cpp:65:15: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>,
      std::__1::allocator<char> >'
  std::string sresource_label(presource_label);
              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:193:33: note: template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
In file included from src/fastuidraw/util/static_resource.cpp:21:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:438:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:16:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:604:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:258:9: error: implicit instantiation of
      undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
    _T1 first;
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:624:16: note: in instantiation of template class
      'std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<unsigned char,
      std::__1::allocator<unsigned char> > >' requested here
    value_type __cc;
               ^
src/fastuidraw/util/static_resource.cpp:70:11: note: in instantiation of template class 'std::__1::__value_type<std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > >' requested here
  if(iter != hoard().m_data.end())
          ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:193:33: note: template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
In file included from src/fastuidraw/util/static_resource.cpp:21:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:438:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:16:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:604:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:258:9: error: implicit instantiation of
      undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
    _T1 first;
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:625:21: note: in instantiation of template class
      'std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<unsigned char,
      std::__1::allocator<unsigned char> > >' requested here
    __nc_value_type __nc;
                    ^
src/fastuidraw/util/static_resource.cpp:70:11: note: in instantiation of template class 'std::__1::__value_type<std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > >' requested here
  if(iter != hoard().m_data.end())
          ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:193:33: note: template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
4 errors generated.
make: *** [release/src/fastuidraw/util/static_resource.o] Error 1
mac-pro:fastuidraw robby$
´´´

Hi, sorry for reporting it here, I'm not sure where else would be better.

I noticed link to video on https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ is wrong. It points to day 1 stream, while it should point to day 2 stream (https://www.youtube.com/watch?v=2ryvYS47V0E)

I occasionally encounter the error, that fail to emit sm_CallUnloadableFuntion to the result.
I guess this is due to the static member variables referenced in the header (HeaderCreator.hpp).

I saw the post in webkit-dev and started looking fastuidraw. That's super awesome!

Looking through the code, the use of the boost library is fairly limited.
If we can enable C++11, I think we can replace the part of them with the std's ones.
For example, threading primitives can be replaced.

What do you think of using C++11 in the fastuidraw code base?

On macOS <algorithm> needs to be included for std::fill.

These two lines break the build for mac.

I have sdl installed but build system does not see includes out of the box. Headers in Arch Linux are in /usr/include/SDL . I modified some "base" makefile to include it in include paths and I got one demo to go through, but then next example complains again :-). Which makefile is proper place to add sdl so the path is included in all demos, lib etc?

Just to let you know, I built this library with the following fixes under macOS High Sierra:

• add include for string in 'src/fastuidraw/text/glyph_selector.cpp'
• replace 'soname' in all the makefiles under make/ with 'install_name'

The first fix is trivial, the second one not so, I see you have already a CMake build in the process, so that might fix the soname issue also.

With this at least the base library libFastUIDraw target builds succesfully. The backends I did not get yet compiling due to different GL headers.

Would be interested in seeing this run on macOS too. Let's see if I get the macOs version running, I see you already had somebody do that on an older version, I'll try that.

As an enhancement, for build systems it would be good if "make check" would return with an error code if any dependency is missing.

I had to prefix the executables with ./ on Linux in order to have this work.

`diff --git a/src/fastuidraw/gl_backend/ngl_generator/Rules.mk b/src/fastuidraw/gl_backend/ngl_generator/Rules.mk
index c9439cb..455942f 100644
--- a/src/fastuidraw/gl_backend/ngl_generator/Rules.mk
+++ b/src/fastuidraw/gl_backend/ngl_generator/Rules.mk
@@ -6,8 +6,8 @@ d := $(dir)

NGL_DIRECTORY := $(d)
NGL_BUILD := build/ngl_generator
-NGL_FILTER := $(NGL_BUILD)/filter
-NGL_EXTRACTOR := $(NGL_BUILD)/extractor
+NGL_FILTER := ./$(NGL_BUILD)/filter
+NGL_EXTRACTOR := ./$(NGL_BUILD)/extractor`

When building for Wayland, demos/common/egl_helper.cppmust be compiled with -DSDL_VIDEO_DRIVER_WAYLAND. If the config could set that automatically, everything would work out of the box.

Output of make check:

(base) amandy@poppolop:~/Repos/WebTeam_2019/fastuidraw$ make check
Package SDL2_image was not found in the pkg-config search path.
Perhaps you should add the directory containing `SDL2_image.pc'
to the PKG_CONFIG_PATH environment variable
No package 'SDL2_image' found
/bin/sh: 1: Syntax error: end of file unexpected
/bin/sh: 1: Syntax error: end of file unexpected
Cannot build demos: Unable to find SDL2_image cflags from pkg-config SDL2_image:
Cannot build demos: Unable to find SDL2_image libs from pkg-config SDL2_image:

Since I have no idea what this is, I have no idea where to get it or install that.

Windows MSYS2

The static libs seem to be 32bit, I don't see an obvious way to change it, or any mention of x64 anywhere, but when trying to force a -m64 into the makefile I get "cc1plus.exe: sorry, unimplemented: 64-bit mode not compiled in".

What's going on? Is this not possible to compile in 64bit mode? Or is my environment messed up?

Hi! This project is fascinating.
I was wondering when will we be able to test it on chromium?

I've seen no update from this https://groups.google.com/a/chromium.org/forum/m/#!topic/graphics-dev/h6BZF5nPdQw

Additional questions:
Is the chromium integration made with or without skia?
Are there new benchmarck since the recent 1.0 release?
How much does this compare to blend2d, skia, NV path, direct2d, and webrender performance wise?
Are there benchmarcks on power consumption too?

How much is fastuidraw feature complete?
Can it fully implement canvas? SVG? Text ?
CSS ?

Also what is the roadmap?
New performance ideas? (Vulkan, AVX 512, OpenMP 5 / openacc?)

Hello! I'm currently evaluating replacing NanoVG with fastuidraw in VCV Rack v3, scheduled for development in late 2020 and release early 2021. (Yes, we plan that far ahead.)
I haven't seen a lot of talk about fastuidraw in the wild, but it looks beautifully designed, and at first glance delivers what it "advertises".

It would be greatly appreciated if anyone can answer any or all of these questions.

• Does this project have any funding sources? (Intel funding?)
• Does this project have a funding sink? (A place where I can throw money for maintainers to solve problems or push the project in some direction)
• What is the future of this project? NanoVG's maintainer Mikko seems to have moved on, and while NanoVG can be adopted by someone (re-adopted by Mikko) with enough funding, my first impression of fastuidraw is that it may be years ahead of NanoVG's rendering performance and capability.
• Who maintains this project? @krogueintel or a manager at Intel? I don't see a lot of discussions anywhere, so it seems like most planning is in @krogueintel's mind. (No problem with that at all. VCV operates smoothly this way.)
• 25-50 of the ~170 plugins for VCV Rack, each maintained by a different developer, call the NanoVG API directly (because I include nanovg.h in the Rack SDK), so functions as simple as nvgRect(vg, x, y, w, h) and as complicated as nvgRadialGradient(vg, cx, cy, innerradius, outerradius, innercolor, outercolor) would need to be wrapped to fastuidraw, to avoid breaking those plugins. Since both libraries attempt to follow HTML5's canvas API loosely, this would probably take at most a week. I guess this isn't a question but just a comment.
• An open ended question: VCV Rack renders a huge number of paths per frame, and everything else is rendered to framebuffers to reduce this number (which are then rendered as images in the scene graph along with the other non-cached paths). VCV Rack runs on Mac/Windows/Linux and currently has graphics performance problems for users with weaker GPUs (e.g. pretty much any Macbook). Is fastuidraw an appropriate choice this project in your opinion?

Apologies if I come across as a bit pushy with all these questions.

Steps to reproduce:

1. run one of the demos with ./painter-path-test-GL-release fill_alpha=0.5
2. press f key to toggle filling on
3. hold [ key until the stroke width is set to 0

Then one can see the following:

While searching for graphics libraries and lightweight GUIS for C++ I found your library and I wonder if you could give me some information :

• Do you know if there is any open source project using fastuidraw for rendering a GUI ?
• Are there plans to support other backends such as DirectX , Vulkan or Metal ?
• Will the 1.0 release have support for CMake ?
• The demos use SDL, but I think it will work with GLFW, right ?

When I built fastuidraw and run the demos, I noticed some artifacts.

Is this expected? Thanks.

Trying a test I have previously done with the nanovg library I found that the cpu usage of fastuidraw is about 7 times higher in this particular test. Please see the attached screenshots. Both tests were compiled with gcc 7.4.0 in release mode (-O3) and I am using fastuidraw release libraries.

The fastuidraw test code is here.
The nanovg test code is here.

It was curious that the fastuidraw cpu load started low but after a few seconds it stabilized in about 29%. Both tests were executed with no major applications running in the machine (only system services).

Any ideas on how to modify the test to lower fastuidraw cpu load ?

A make target for static library builds would be great!

I am not sure if you care about osx at this early stage but i tried to build it and had some errors the first of which

src/fastuidraw/painter/painter_brush.cpp:268:36: error: no member named 'min' in
namespace 'std'; did you mean 'fmin'?
static_cast(std::min(im->slack() + 1,
^~~~~~~~
fmin

This can be resolved by including in painter_brush.cpp (or in painter_brush.hpp)

Since commit ad07575, the shader stops to compile. Failed shader is at
bad_shader_2.txt

https://www.phoronix.com/scan.php?page=news_item&px=Intel-IGC-Vector-Backend

https://github.com/intel/llvm/pull/1612/files

This could revolutionize 2D rendering performance (and/or efficiency) on Intel igpus (most of the market) so you should keep an eye on it :}

While I was doing Travis-CI build enabling I encountered very strange issue:

No rule to make target `build/demo/debug/GL/demos/atlas_tests/image_test/main.o

I can not reproduce this on my local machine.

Here is the link to Travis build.

Any ideas?

Hi,

It's not a bug, just an info.
I've tried to use fastuidraw with intel software rasterizer (SWR / Mesa 17.0.5), and it works.
It works well enough to run the benchmark, but it probably needs more tests to see if swr could be used as a fallback.

Tested on a i3 4160, with remote acces via X2Go (so, probably the worst configuration), with a 1280x1280 screen resolution :
Cairo : 32.7 FPS
FastUI+swr : 1.9 FPS

swr use 2 CPU cores and Cairo one CPU core.

I am trying to run tests with fastuidraw using GLFW.
I have based my test runner on this document.
The platform is Linux Mint with gcc 7.4.0, glfw-3.2 and fastuidraw 1.0.
The test seg faults apparently inside PainterSurfaceGL::blit_surface();
Please see the test code here.
Any hints would be appreciated.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff710fd49 in fastuidraw::gl::PainterSurfaceGL::dimensions (this=0x5555559f87b0) at src/fastuidraw/gl_backend/painter_engine_gl.cpp:358
358 get_implement(fastuidraw::gl::PainterSurfaceGL,
(gdb) backtrace
#0 0x00007ffff710fd49 in fastuidraw::gl::PainterSurfaceGL::dimensions (this=0x5555559f87b0) at src/fastuidraw/gl_backend/painter_engine_gl.cpp:358
#1 0x00007ffff710fbe3 in fastuidraw::gl::PainterSurfaceGL::blit_surface (this=0x5555559f87b0, filter=9728) at src/fastuidraw/gl_backend/painter_engine_gl.cpp:326
#2 0x000055555555a3b7 in Runner::renderLoop (this=0x7fffffffdd50) at /home/leonel/s/fastuidraw_tests/runner.cpp:107
#3 0x000055555555ac3b in main (argc=1, argv=0x7fffffffde78) at /home/leonel/s/fastuidraw_tests/rects.cpp:23

Hi,

I build fastuidraw in Linux (Manjaro) and all build processes finished successful but when running demos, all of them failed and write below message to terminal output.

inc/fastuidraw/util/reference_counted.hpp:194: Assertion 'm_p' failed
Aborted (core dumped)

I am adding the FastUIDraw project to the Yocto build system. The FastUIDraw library build completes but I think the GLES build is broken in my case. I am not seeing where the build fails yet, but it seems the NGL generated gles2 backend files did not get created with the function foo. I am submitting an other issue because I do see a typo in the NGL HeaderCreator.

make -j 1 BUILD_GL=0 BUILD_GLES=1 painter-simple-test

x86_64-oe-linux-g++ --version x86_64-oe-linux-g++ (GCC) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

x86_64-oe-linux-g++ -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2 --sysroot=build/tmp-glibc/work/corei7-64-oe-linux/fastuidraw/1.0.0-r0/recipe-sysroot -O3 -fstrict-aliasing -Wall -Wextra -Wcast-qual -Wwrite-strings -Iinc -Isrc/fastuidraw/internal -Isrc/fastuidraw/internal/3rd_party -DFASTUIDRAW_GL_USE_GLES -Ibuild/tmp-glibc/work/corei7-64-oe-linux/fastuidraw/1.0.0-r0/recipe-sysroot/usr/include/freetype2 -std=c++11 -fPIC -MT build/release/GLES/src/fastuidraw/gl_backend/gl_binding.o -MMD -MP -MF build/release/GLES/src/fastuidraw/gl_backend/gl_binding.d -c src/fastuidraw/gl_backend/gl_binding.cpp -o build/release/GLES/src/fastuidraw/gl_backend/gl_binding.o In file included from inc/fastuidraw/gl_backend/ngl_header.hpp:21, from src/fastuidraw/gl_backend/gl_binding.cpp:26: src/fastuidraw/gl_backend/gl_binding.cpp: In function 'std::__cxx11::string {anonymous}::gl_error_check()': inc/fastuidraw/gl_backend/ngl_gles3.hpp:17:67: error: 'get_function_ptr_glGetError' is not a member of 'fastuidraw::gl_binding' #define FASTUIDRAWglfunctionPointer(name) fastuidraw::gl_binding::get_function_ptr_##name() ^~~~~~~~~~~~~~~~~ src/fastuidraw/gl_backend/gl_binding.cpp:34:14: note: in expansion of macro 'FASTUIDRAWglfunctionPointer' auto p = FASTUIDRAWglfunctionPointer(glGetError); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ make/Makefile.gl_backend.lib.mk:117: recipe for target 'build/release/GLES/src/fastuidraw/gl_backend/gl_binding.o' failed make: *** [build/release/GLES/src/fastuidraw/gl_backend/gl_binding.o] Error 1 ERROR: oe_runmake failed WARNING: ../temp/run.do_compile:1 exit 1 from 'exit 1'

Hi,

In my tests after generating the drawing commands for several rectangles,
the framebuffer is cleared to white, but the background of my window remains black.
Please see the screenshot.

Commands executed after drawing the rectangles:

...
mPainter->end();
// Make sure we are rendering to the default fraembuffer of GL
fastuidraw_glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);

// Clear the framebuffer
fastuidraw_glClearColor(1.0, 1.0, 1.0, 1.0);
fastuidraw_glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);

// blit the contents of m_surface to the default framebuffer with nearest filtering
mSurface->blit_surface(GL_NEAREST);
...

Any ideas of what could be wrong ?

Hello
sorry this isn't issue but
can you share source code of your benchmars that you use in your XDC2016 presentation
As I would like to see why Qt scenegraph is slower then fast ui draw
Thx

Innocent typo?

grep -rne laodAll

grep -rne loadAll

I hoped it would be related to issue #40 but it seems not, because if it seems consistent everywhere.

Currently, FastUIDraw is very low level concerning text rendering (which is a major requirement for a Canvas like API). It's storing a cache of Freetype's generated glyphs, and if I understand correctly, expect the user to provide the sequence of glyphs to render.

As a potential user of the library, the amount of work from "text" to glyph is a real nightmare to make right. One should take into account the language the text is in, the font's script to run to figure out which glyph to display at what position, and the glyph transformations. I'm not even speaking of font fallback when a glyph is missing in a font or a language.

The current best open source lifesaver is Harfbuzz that does the mapping from text run to glyphs run. However, having a working code with Harfbuzz is tricky, and I think it would be better if, instead of having all users implement their "something that work with harfbuzz but full of bug", the fastuidraw code implemented a working harfbuzz wrapper, so we could call rectangle Painter::draw_textRun(string, style, justification, double fontSize, rectangle src_rect) and also have a rectangle Painter::get_glyph_pos(string, style, justfication, double fontSize, size_t characterIndexInString) would be a real lifesaver and improve usability a lot.

The makefile does not detect MinGW64 on Windows.
After manually overriding compiler detection it fails to link the dll.
The link command exceeds the windows command line limit of 8192 characters.