intel / fastuidraw Goto Github PK
View Code? Open in Web Editor NEWLicense: Mozilla Public License 2.0
License: Mozilla Public License 2.0
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.
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.Apologies if I come across as a bit pushy with all these questions.
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 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)
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.
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`
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 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?
Since commit ad07575, the shader stops to compile. Failed shader is at
bad_shader_2.txt
When building for Wayland, demos/common/egl_helper.cpp
must be compiled with -DSDL_VIDEO_DRIVER_WAYLAND
. If the config could set that automatically, everything would work out of the box.
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 :}
As an enhancement, for build systems it would be good if "make check" would return with an error code if any dependency is missing.
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?
Output of make check:
Since I have no idea what this is, I have no idea where to get it or install that.
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)
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,
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 ?
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'
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 ?
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?
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.
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
On macOS <algorithm>
needs to be included for std::fill.
fastuidraw/src/fastuidraw/text/glyph.cpp
Line 92 in ccce055
These two lines break the build for mac.
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
A make target for static library builds would be great!
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).
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?)
While searching for graphics libraries and lightweight GUIS for C++ I found your library and I wonder if you could give me some information :
Just to let you know, I built this library with the following fixes under macOS High Sierra:
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.
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$
´´´
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.