I guess clipping works great in this case - it rejects fast everything outside of bounds
For circles, I switched to an instance thing. I pre-calculated my own spans, and then just blast spans, since the circles are all of the same size, no need to re-calculate spans every time. That sped up my thing tremendously, but I lose the beauty of the nice anti-aliasing that blend2d does.
@kobalicek: I do a few things to improve performance when zooming in. But yeah, it gets faster.
Right now I don't actually clip much--to be clear. I am brute-forcing things a bit. I have tree of items, and traverse them to render them
I tile my scene in order to speed up hit-testing and drawing items. So if you have 2M items like I had above, but your tile has 500, you are only paying for 500, of which you will draw only the ones whose bounding boxes intersect with the viewport.
I mainly pay for the traversal. If you have the same amount of items, but you have them in a single tile...your drawing will be slow always.
I really don't want to do a quad tree, since the idea is to work at the pixel scale--not at arbitrary scales.
An obvious way to get large performance improvements is to mipmap groups. That would make interacting with a huge group (100k/1M/etc) pretty fast
thanks!
I've a question related to strokes/lines of width 1.
My goal is to draw a stroke (line, or rect) of width 1. Here is my code:
#define BL_STATIC
#include <blend2d.h>
int main()
{
BLImage img(200, 5, BL_FORMAT_PRGB32);
BLContext ctx(img);
ctx.setCompOp(BL_COMP_OP_SRC_COPY);
ctx.fillAll();
ctx.setCompOp(BL_COMP_OP_SRC_OVER);
ctx.setStrokeStyle(BLRgba32(0xFFFFFFFF));
ctx.setStrokeWidth(1);
ctx.strokeLine(50, 3, 150, 3);
ctx.end();
BLImageCodec codec;
codec.findByName("PNG");
img.writeToFile("bl-getting-started-1.png", codec);
return 0;
}
And above is the output. The line is 2 pixels thick and it's not exactly white, but more grayish.
Can you tell what I am doing wrong? How can I get crisp lines with width 1 pixel? Thanks!
src_copy will still be blending alpha and strokeWidth of 1will straddle a pixel probably
if you want pixel aligned, try drawing thin rectangles
This fiddle should explain it:
// 'render()' is an entry-point, 'cci' would initialize the rendering context.
BLImage render(const BLContextCreateInfo& cci) {
// Create a destination image and rendering context.
BLImage img(220, 340, BL_FORMAT_PRGB32);
BLContext ctx(img, cci);
// The image data is not guaranteed to be empty, so clear it explicitly.
ctx.clearAll();
ctx.setStrokeStyle(BLRgba32(0xFFFFFFFF));
for (int i = 0; i < 32; i++) {
double y = double(i) * 10 + 10;
double f = double(i) / 32.0;
ctx.strokeLine(10 + f, y + f, 200 + f, y + f);
}
return img;
}
Thanks for the responses! @Wiladams I played with fill style but that didn't help much. @kobalicek This worked! for sharp, pixel aligned strokes I used floating point coordinates with 0.5 as fraction, and for sharp fills I used integer coordinates and it produced the result I was aiming. ^_^ Here is my abstraction:
void rect(int x, int y, int w, int h) {
if (processing::shouldFill) {
BLRectI rect{x, y, w, h};
processing::ctx.fillGeometry(BLGeometryType::BL_GEOMETRY_TYPE_RECTI, &rect);
}
if (processing::shouldStroke) {
BLRect rect{x + 0.5, y + 0.5, static_cast<double>(w), static_cast<double>(h)};
processing::ctx.strokeGeometry(BLGeometryType::BL_GEOMETRY_TYPE_RECTD, &rect);
}
}
First one is plotted via Processing (Java based creative coding library. It might be using Java2D, not sure), and second one with Blend2D. They very similar to me. Thanks for the help ^_^ Can continue working on my Processing clone in C++ now :-P
Just by ignoring the 3D-features of Processing, and the whole set of add-on libraries,
in my opinion these are the core features missing in Blend2d:
- Basic Image processing : blur, filter
- more on Bezier curves ( curvePoint(t) , curveTangent(t), ... )
- Curve (i.e. Catmull-Rom Splines)
- Color modes (RGBA, HSL , ...)
- Perlin noise and other random distributions
Except for Image Processing, all the missing features could be implemented as external libraries, but I think that filling these gaps within the Blend2d-core would provide a distinct advantage.
@Wiladams Sure! My goal is to learn more about C++ and graphics programming, and I used Processing a lot in the past and am familiar with it. Thought it can be a good exercise while I'm on parental leave. :-) Therefore not aiming for a complete port. Once I upload it to its own repo I'll share it here.
Right now only
Right now only
size, rect, fill, stroke, background functions are supported. :-) You create a file, say, sketch1.cpp, include processing.h and write setup and draw functions. After compiling, link it with Blend2D.lib MiniFB.lib, processing.cpp, and main.cpp. and the generated exe produces the image. ^_^
@abu-irrational found this library https://github.com/Auburn/FastNoiseLite for noise functionality. hoping to find an easy one for color theory stuff too. Didn't know Blend2d does not have image processing features. I guess because it's a vector graphics library.
This is the original Perlin noise in less than 50 lines of code:
// JAVA REFERENCE IMPLEMENTATION OF IMPROVED NOISE - COPYRIGHT 2002 KEN PERLIN.
https://mrl.cs.nyu.edu/~perlin/noise/
https://mrl.cs.nyu.edu/~perlin/noise/
I have the noise thing, and the bezier curvePoint, NOT curveTangent, but that's certainly possible. I did the color mode thing. That's a bit of work. I did the PImage vs just drawing to the canvas thing as well. Aside from the curve stuff, I don't really expect blend2d to do much more than it does. It's a vector graphics library, and should stay that way. All the pixel oriented stuff is fairly easily added as application layer stuff.
It would be nice for blend2d to supply super fast matrix calculations up to 4x4. That will make the image processing trivial to implement as well, and it needs it anyway.
The other thing I did in my implementation was try to eliminate creating objects as much as possible. So, passing references most everywhere. Just a very light touch on the C++, not going too crazy.
After doing such, translating from typical Processing code is fairly trivial.
This is my most favored mode of sample programming. Wrap up all the windowing and eventing stuff in boilerplate. Just implement setup(), and your event handlers, and you're good to go.
layers will be useful as well