In this case with triangulation you need to fold opacity to modified colors of new triangles - resulting to few blue triangles, few red triangles and few pink triangles. Of course some triangles will be small but proper antialiasing already requires support differentiation of small shapes (up to 16*16 grid inside pixel for 256 shades of color for common rgb encoding with 1-byte per color)
Well, I would definitely not spend my time on even trying this as I don't really see how this could be fast. There are trade-offs, and with Blend2D we do basically what others are doing, but we do optimize it better. So for example if your stack is AGG or Qt you would gain performance when switching to Blend2D without sacrificing the quality.
But if you need something like you have described - composition at a sub-pixel level then this is not something Blend2D can help with. You can still multisample and then downscale - I think this could be still faster than doing the triangulation and resolving intersections and overlapping of everything in the scene if it's complicated enough.
And resolving intersection important not only for right blending (and solving conflation problem) but for the efficient rasterization too. How blend2d optimizes overlapping? Does it suffers from overdrawing? When you have complex ui primitives which overlaps you can spend more time doing extra work (by blitting pixels of shapes which will be hidden by new opaque shapes later) than by resolving intersection between shapes geometrically and blit only visible pixels
BTW do you have a link to any project that does the approach you have described? I would take a look to see how viable it is
No, I'm just planning to write one by myself.
I think that fast raw scene rasterization is not the first goal of rasterizer engine. I would want to have right blending first, and only then do speed comparison of rasterizer libs. And when you have pixels caching and incremental propagation of data changes to pixels (resulting in smaller work like only rasterizing few new pixel lines when you scoll or rasterizing small frame of pixels when you zoom out) - then the raw rasterization speed doesn't matter as much
How blend2d optimizes overlapping? Does it suffers from overdrawing? When you have complex ui primitives which overlaps you can spend more time doing extra work (by blitting pixels of shapes which will be hidden by new opaque shapes later) then by resolving intersection between shapes geometrically and blit only visible pixels
It doesn't - it does composition, which means that if you render 100 rectangles on top of each other, it would render 100 rectangles (at the moment) - I plan to do tile-based optimizations of solid fills in the future, but it's not relevant now and maybe with a fast cache and banding it wouldn't be that beneficial as it may seem.
Basically Blend2D works this way, those two operations are identical:
Create rendering context:
fillRect(A);
fillRect(B);
Destroy rendering context.
vs
Create rendering context:
fillRect(A);
Destroy rendering context.
Create rendering context:
fillRect(B);
Destroy rendering context.The second will be slower, but that's it - the output will be identical, because it's two render commands done separately.
https://www.dropbox.com/s/wrcsky7u82rmmk6/Bildschirmaufnahme%202020-11-28%20um%2017.30.31.mov?dl=0
gAppSurface->setPpiUnits(systemPpi, 96); inline void setPpiUnits(double ppi, double units)
{
fDimensionScale = ppi / units;
fCtx.scale(fDimensionScale);
fCtx.userToMeta();
} auto dhdc = CreateDC(TEXT("DISPLAY"), NULL, NULL, NULL);
auto screenWidth = ::GetDeviceCaps(dhdc, HORZSIZE)/25.4;
auto screenHeight = ::GetDeviceCaps(dhdc, VERTSIZE)/25.4;
auto pixelWidth = ::GetDeviceCaps(dhdc, LOGPIXELSX);
auto pixelHeight = ::GetDeviceCaps(dhdc, LOGPIXELSY);
double screenHPpi = (double)dpidisplayWidth / screenWidth;
double screenVPpi = (double)dpidisplayHeight / screenHeight;
systemPpi = (unsigned int)screenVPpi; background(255, 255, 0);
stroke(0);
// print lines of different lengths
// increasing width as we go
for (size_t i = 1; i < 192; i++) {
auto w = map(i, 1, 192, 0.25, 2);
strokeWeight(w);
line(0, i*2, i, i*2);
}
Also, does blend2d support faux bold and faux italic text?