2D Vector Graphics Engine Powered by a JIT Compiler

I find one problem. Firstly, I use red color to draw a rect, the color's alpha is 255, then I draw image, the image has zeor alpha, but rgb has value in same pixel, the draw result is the region of source image is transparent, I hope it display background image. I want to why?

The systematic use of uint32_t instead of the enum type is making the API very painful to use. I do not care much that the compiler cannot check that I am using the right enum but I am spending far more time than acceptable trying to figure out which enum type I should use for each function parameter.

I do not now why that was done like that but I assume that there must be a reason (backward compatibility? consistency with the C api? make bindings easier? ...)

If keeping uint32_t is really important then I propose the following approach that should solve the problem for the C++ api by providing the required information to Doxygen without changing the ABI.

1. Declare the following template type

    #include <type_traits>
    template<typename T> using bl_enum = typename std::underlying_type<T>::type;
   

or if you know that all enums are uint32_t

    template<typename T> using bl_enum = uint32_t;

2. And replace each uint32_t by bl_enum<XXX> where XXX is the required enum type.

What is the intention for multi-threading? I am currently contemplating having several BLContext objects connected to the same BLImage. This is to support multiple "windows" on the same "framebuffer". The challenge for the window manager will be in some way controller the ordering of blits into the framebuffer. Of course, having each window with its own backing store, and just bliting in z order will do the trick.

Is the intention of multi-threading to simply deal with multiple threads within a single drawing context? Or is there any intention of helping to manager multiple contexts? I assume the former (multi-thread within single context).

Just want to be clear so I don't waste time creating something that's already on the roadmap.

A lot of library functions can be accessed only using "internal" mecanics like casting from "_d.impl" pointers to actual implementation. Using such code in application may be huge problem if some internals changes in future. I think its needed to add all such functional to system headers and make them looks like functions.

F.i. to get current stroke width value now I need to use something like this:

BLContextCore *core;
double old_width = ((BLContextImpl*)core->_d.impl)->state->strokeOptions.width;

I think its much better to have something like:

#define blGetStrokeWidth( ctx ) ((BLContextImpl*)(ctx)->_d.impl)->state->strokeOptions.width

in system header for ANSI and inline function for C++ mode.

Blend2D has problems when the CPU's FPU is set to flush denormals to zero. This is mostly related to our quadratic and cubic roots functions where we compare with tMin and tMax.

This issue originated from https://github.com/blend2d/blend2d-samples/issues/2

This issue is provided for C-API users.

If you think that something in C-API is not documented well please add a comment here and we will try to update the documentation.

Hello again

Blend2D suggest to use Clang, so I did generate the build project files for MSVC 2019 with clang installed using the following command:

cmake -T ClangCL .. -DBLEND2D_STATIC=True

It did generate project with LLVM (clang-cl) as Platform Toolset, but there are some warnings:

2>clang-cl : warning : unknown argument ignored in clang-cl: '-fno-exceptions' [-Wunknown-argument]
2>clang-cl : warning : unknown argument ignored in clang-cl: '-fno-rtti' [-Wunknown-argument]
2>clang-cl : warning : unknown argument ignored in clang-cl: '-fno-math-errno' [-Wunknown-argument]

Which I suppose might be crucial for those optimizations mentioned on the website regarding choosing compiler.

The project does compile fine though.

I am getting lost between font, metrics, glyph buffers and the like. Is there an obvious way to measure the size of a string?

More specifically, the text bounding box for some text. I know it's an obviously complex thing, but looking for the Cairo equivalent "toy" interface.

The following operation:

var region = BLRegion()
region.combine(box: BLBoxI(x0: 20, y0: 50, x1: 260, y1: 270), operation: .or)
region.combine(box: BLBoxI(x0: -56, y0: -169, x1: 185, y1: 52), operation: .or)
region.combine(box: BLBoxI(x0: -46, y0: -134, x1: 29, y1: -118), operation: .or)

results in an invalid region.

Context: The combine method invokes blRegionCombineRB(this, this, &box, operation), like the combine method from BLRegion::combine.

After these operations, the BLRegion pointer seems to be filled with garbage from the memory, but I'm not sure what exactly could be happening.

Visual Studio 15 2017 CMake creates project and all that. ultimately cl compiler will report error: D8016: '/Ox' and '/RTC1' command-line options are incompatible. I'm compiling for 32-bit also. Last time around I just went into the project and disabled either or both of these and moved along, but I think it's worth reporting if you want to fix this at the source.

The following code triggers an assertion in region.cpp line 1595:

var region = BLRegion()
region.combine(box: BLBoxI(x0: 174, y0: 92, x1: 506, y1: 463), operation: .or)
region.combine(box: BLBoxI(x0: 189, y0: 466, x1: 482, y1: 478), operation: .or)
region.combine(box: BLBoxI(x0: 189, y0: 478, x1: 482, y1: 484), operation: .or)

// Bang!
region.combine(box: BLBoxI(x0: 189, y0: 440, x1: 482, y1: 446), operation: .or)

I'm experiencing some incorrect results with this font-file "Quicksand_Light.otf" regarding how details are extracted from its NAME table. The weird thing about this font-file is that its "familyName" is different on Windows/Linux. On Windows its familyName is "Quicksand Light", On Linux its familyName is "Quicksand" (as reported by the basic font-installator utilities)

When inspected through Blend2d (BLFontFace ...), the resulting familyName is "Quicksand", independently of the running platform, and this is incoherent at least on Windows.

I've examined the logic used in "opentype/otname.cpp" for selecting the best record in the NAME table, and I noticed some special heuristic assumptions such as ".. Prefer TypographicFamilyName over FamilyName and WWSFamilyName..."

My question is:

• is this font-file wrong ? (end of the story). or
• are the heuristics used in "opentype/otname.cpp" flawed ?

Quicksand_Light.zip

Is there any way to disable edge anti-aliasing somehow? I'm trying to draw solids without a mask.

Even a hack way to do it is fine for the moment.

Use case: raterizing material IDs as colours, that can’t be antialiased or blended.

       BLGradient linear(BLLinearGradientValues(0, 0, 0, 360*5));
	linear.addStop(0.0, BLRgba32(0xFF0000FF));
	linear.addStop(0.2, BLRgba32(0xFFFFFFFF));
	ctx.setFillStyle(linear);
	ctx.fillRect(100.0, 100.0, 20, 360);

	BLGradient linear1(BLLinearGradientValues(0, 0, 0, 360));
	linear1.addStop(0.0, BLRgba32(0xFF0000FF));
	linear1.addStop(1.0, BLRgba32(0xFFFFFFFF));
	ctx.setFillStyle(linear1);
	ctx.fillRect(200.0, 100.0, 20, 360);

	std::vector<BLRgba32> vecColor = {
		BLRgba32(0xffff0000),
		BLRgba32(0xffffff00),
		BLRgba32(0xffffffff),
		BLRgba32(0xff0000ff),
		BLRgba32(0xffff00ff),
		BLRgba32(0xff00ffff),
		BLRgba32(0xff00ff00),
	};
		
	for (int i = 0; i < 6; i++)
	{
		ctx.setFillStyle(vecColor[i]);
		ctx.fillRect(230, 100 + i * 60, 20, 60);
	}

I would like to write a Rive renderer using Blend2D. It looks like BL supports all the required features, except I can't find reference to clipping paths (only clipRect) in the docs.

Are clip paths planned for the future?

This would be the only blocker to a Rive renderer at first glance.

Following the example of implementing blend2d with SDL2 in this sample , I came to a possible bug that can be produced through the example below.

#include <SDL2/SDL.h>
#include "blend2d.h"

int main(){
    SDL_Window * window;
    SDL_Renderer * renderer;
    
    if(SDL_Init(SDL_INIT_VIDEO) != 0){
        error("Unable to init sdl");
    }
    
    if(!(window = SDL_CreateWindow("win", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 600, 600, SDL_WINDOW_SHOWN | SDL_WINDOW_RESIZABLE))){
        error("Unable to create sdl window");
    }
    
    if(!(renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC))){
        error("Unable to create sdl renderer");
    }
    
    SDL_Event e;
    
    SDL_Texture * texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STREAMING, 500, 500);
    
    SDL_SetTextureBlendMode(texture, SDL_BLENDMODE_BLEND);

    BLImage img = BLImage(500, 500, BL_FORMAT_PRGB32);
    
    BLContext ctx = BLContext(img);
    
    ctx.setCompOp(BL_COMP_OP_CLEAR);
    ctx.fillAll();
    
    ctx.setCompOp(BL_COMP_OP_SRC_OVER);
    ctx.setFillStyle(BLRgba32(0xFFFEFEFE));
    ctx.fillRoundRect(50, 50, 400, 400, 50);
    
    ctx.end();
    
    img.writeToFile("img.png");
    
    BLImageData data;
    img.getData(&data);
    SDL_UpdateTexture(texture, NULL, data.pixelData, int(data.stride));
    
    SDL_Rect rect = {50,50,500,500};
    
    while (true) {
        while (SDL_PollEvent(&e) != 0) {
            if(e.type == SDL_QUIT)
                exit(0);
        }
        SDL_SetRenderDrawColor(renderer, 255, 255, 255, 255);
        SDL_RenderClear(renderer);
        SDL_RenderCopy(renderer, texture, nullptr, &rect);
        SDL_RenderPresent(renderer);
    }
}

Which results in:

The problem is that lines (that do not exist in the image generated by the context) appear in the curved regions of the Paths (in the SDL2 texture).

(Translated by Google)