vector-agg-general — Anti-Grain Geometry Project. General Issues.

Re: [AGG] Question about memory usage on small MCU

[Niki S. <nik...@gm...>]

On 5.07.23 г. 1:17 ч., Hugo Elias via Vector-agg-general wrote:
> I have just started trying to use AGG on a microcontroller with 264kB 
> memory. My image buffer is 240x240x3 = 172kB, and if I allow for memory 
> for other stuff, I reckon there's about 50kB of memory free for AGG to use.
> 
> However, when I try to run the simple star example, which draws a 
> 5-pointed star, I get an out-of-memory error. Adding some print 
> statements to the pod_allocator, I can see that a surprisingly large 
> amount of memory is being allocated for this simple task:
> 
> pod_allocator   512 bytes
> pod_allocator  1536 bytes
> pod_allocator   512 bytes
> pod_allocator  1024 bytes
> pod_allocator  2048 bytes
> pod_allocator 65536 bytes
> pod_allocator  3384 bytes
> pod_allocator   944 bytes
> pod_allocator  1664 bytes
> pod_allocator   104 bytes
> pod_allocator   512 bytes
> pod_allocator  1536 bytes
> pod_allocator   512 bytes
> pod_allocator  1024 bytes
> pod_allocator  9904 bytes
> 
> At one point it allocates 64kB! Just to draw a 5-pointed star. Is this 
> to be expected, or am I doing something wrong?  Is there some way to 
> make it use less memory?
> 
> double star[] = {50,  3, 20, 101, 95, 35, 5, 39, 80, 92, 50,  3};
> SimplePath path(star, sizeof(star) / sizeof(double));
> agg::conv_stroke<SimplePath> strokePath(path);
> double strokeWidth = 2.0;
> strokePath.width(strokeWidth);
> strokePath.line_cap(agg::square_cap);
> strokePath.line_join(agg::miter_join);
> strokePath.miter_limit(strokeWidth);
> ras.reset();
> ras.add_path(strokePath);
> agg::render_scanlines_aa_solid(ras, scanline, rBase, redColor);
> 

IIRC 512 is the default chink size. You can try to change it.

HTH
Niki

[AGG] Question about memory usage on small MCU

[Hugo E. <hu...@sh...>]

I have just started trying to use AGG on a microcontroller with 264kB
memory. My image buffer is 240x240x3 = 172kB, and if I allow for memory for
other stuff, I reckon there's about 50kB of memory free for AGG to use.

However, when I try to run the simple star example, which draws a 5-pointed
star, I get an out-of-memory error. Adding some print statements to the
pod_allocator, I can see that a surprisingly large amount of memory is
being allocated for this simple task:

pod_allocator   512 bytes
pod_allocator  1536 bytes
pod_allocator   512 bytes
pod_allocator  1024 bytes
pod_allocator  2048 bytes
pod_allocator 65536 bytes
pod_allocator  3384 bytes
pod_allocator   944 bytes
pod_allocator  1664 bytes
pod_allocator   104 bytes
pod_allocator   512 bytes
pod_allocator  1536 bytes
pod_allocator   512 bytes
pod_allocator  1024 bytes
pod_allocator  9904 bytes

At one point it allocates 64kB! Just to draw a 5-pointed star. Is this to
be expected, or am I doing something wrong?  Is there some way to make it
use less memory?

double star[] = {50,  3, 20, 101, 95, 35, 5, 39, 80, 92, 50,  3};
SimplePath path(star, sizeof(star) / sizeof(double));
agg::conv_stroke<SimplePath> strokePath(path);
double strokeWidth = 2.0;
strokePath.width(strokeWidth);
strokePath.line_cap(agg::square_cap);
strokePath.line_join(agg::miter_join);
strokePath.miter_limit(strokeWidth);
ras.reset();
ras.add_path(strokePath);
agg::render_scanlines_aa_solid(ras, scanline, rBase, redColor);

Many thanks
Hugo

-- 

Re: [AGG] [PATCH] Fix off-by-one error in mol_view example

[Jim B. <ji...@ch...>]

Hi John,

Thanks for doing this. It would be nice if we could regain control of
antigrain.com at some point!

- Jim

On Tue, 16 Feb 2021 at 07:06, John Horigan <jo...@gl...> wrote:

> Hi Jim,
>
> Sorry for the hasty commit. I'm not used to McSeem's C-style memory
> management.
>
> I was looking at the examples and I found that many of them don't build or
> run anymore. Some examples download additional files from antigrain.com,
> which is no more. The Makefiles literally have make rules like:
>
> 1.sdf:
>     @echo "Required file missing!!"
>     @echo "Please download http://www.antigrain.com/1.sdf to
> /examples/sdl/"
>     @echo "Attempting to retrieve file: (will fail if curl -O  is not
> installed)"
>     curl -O  http://www.antigrain.com/1.sdf
>
>
> All but three of the required files are already present in the
> examples/art directory. I'm preparing a commit that adds the remaining
> three files and changes the Makefiles and Windows readme files to use the
> new location.
>
> -- john
>

Re: [AGG] [PATCH] Fix off-by-one error in mol_view example

[John H. <jo...@gl...>]

Hi Jim,

Sorry for the hasty commit. I'm not used to McSeem's C-style memory
management.

I was looking at the examples and I found that many of them don't build or
run anymore. Some examples download additional files from antigrain.com,
which is no more. The Makefiles literally have make rules like:

1.sdf:
    @echo "Required file missing!!"
    @echo "Please download http://www.antigrain.com/1.sdf to /examples/sdl/"
    @echo "Attempting to retrieve file: (will fail if curl -O  is not
installed)"
    curl -O  http://www.antigrain.com/1.sdf


All but three of the required files are already present in the examples/art
directory. I'm preparing a commit that adds the remaining three files and
changes the Makefiles and Windows readme files to use the new location.

-- john

On Wed, Feb 10, 2021 at 6:57 AM Jim Barry via Vector-agg-general <
vec...@li...> wrote:

> I'm afraid this is incorrect, and is a good example of why the results of
> code analysis tools should be examined carefully.
>
> The function trim_cr_lf returns the length of the trimmed string, so
> "m_name[len] = 0" is the correct way to ensure that m_name is zero
> terminated.
>
> If changed to [len-1], the last character of the name is truncated. So
> with the "1.sdf" sample data file, the name is displayed as MFCD0013393
> when it should be MFCD00133935. Also, if "len" happened to be zero then
> "m_name[len-1]" is obviously out of bounds.
>
> However, there are a couple of other problems. The m_name buffer is 128
> characters in size, but space is not allowed for the terminating zero when
> enforcing the maximum string length, resulting in a buffer overflow.
>
> There is also a potential problem in trim_cr_lf, which is that strcpy has
> undefined behaviour if the source and destination strings overlap.
>
> I have undone the previous change, fixed the length check, and replaced
> the strcpy call with memmove, which does permit the buffers to overlap.
> (The trim_cr_lf function always zero-terminates the buffer so that is
> already taken care of.)
>
> - Jim
>
> On Fri, 5 Feb 2021 at 19:28, Alex Henrie <ale...@gm...> wrote:
>
>> This bug was identified by cppcheck.
>> ---
>>  agg-2.4/examples/mol_view.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/agg-2.4/examples/mol_view.cpp b/agg-2.4/examples/mol_view.cpp
>> index 7813dc3..adba034 100644
>> --- a/agg-2.4/examples/mol_view.cpp
>> +++ b/agg-2.4/examples/mol_view.cpp
>> @@ -205,7 +205,7 @@ bool molecule::read(FILE* fd)
>>      if(len > 128) len = 128;
>>
>>      if(len) memcpy(m_name, buf, len);
>> -    m_name[len] = 0;
>> +    m_name[len-1] = 0;
>>
>>      if(!fgets(buf, 510, fd)) return false;
>>      if(!fgets(buf, 510, fd)) return false;
>> --
>> 2.30.0
>>
> _______________________________________________
> Vector-agg-general mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

Re: [AGG] [PATCH] Fix off-by-one error in mol_view example

[Alex H. <ale...@gm...>]

On Wed, Feb 10, 2021 at 7:57 AM Jim Barry via Vector-agg-general
<vec...@li...> wrote:
>
> I'm afraid this is incorrect, and is a good example of why the results of code analysis tools should be examined carefully.
>
> The function trim_cr_lf returns the length of the trimmed string, so "m_name[len] = 0" is the correct way to ensure that m_name is zero terminated.
>
> If changed to [len-1], the last character of the name is truncated. So with the "1.sdf" sample data file, the name is displayed as MFCD0013393 when it should be MFCD00133935. Also, if "len" happened to be zero then "m_name[len-1]" is obviously out of bounds.
>
> However, there are a couple of other problems. The m_name buffer is 128 characters in size, but space is not allowed for the terminating zero when enforcing the maximum string length, resulting in a buffer overflow.

The buffer overflow is the problem that cppcheck identified and I was
trying to fix. I incorrectly assumed that len included the terminating
null character. I apologize for not looking at the code more closely.

> There is also a potential problem in trim_cr_lf, which is that strcpy has undefined behaviour if the source and destination strings overlap.
>
> I have undone the previous change, fixed the length check, and replaced the strcpy call with memmove, which does permit the buffers to overlap. (The trim_cr_lf function always zero-terminates the buffer so that is already taken care of.)

You really didn't have to commit and then revert the incorrect fix
that I originally suggested. But anyway, thank you for resolving the
buffer overflow, and for finding and fixing the bug with strcpy as
well.

-Alex

Re: [AGG] [PATCH] Fix off-by-one error in mol_view example

[Jim B. <ji...@ch...>]

I'm afraid this is incorrect, and is a good example of why the results of
code analysis tools should be examined carefully.

The function trim_cr_lf returns the length of the trimmed string, so
"m_name[len] = 0" is the correct way to ensure that m_name is zero
terminated.

If changed to [len-1], the last character of the name is truncated. So with
the "1.sdf" sample data file, the name is displayed as MFCD0013393 when it
should be MFCD00133935. Also, if "len" happened to be zero then
"m_name[len-1]" is obviously out of bounds.

However, there are a couple of other problems. The m_name buffer is 128
characters in size, but space is not allowed for the terminating zero when
enforcing the maximum string length, resulting in a buffer overflow.

There is also a potential problem in trim_cr_lf, which is that strcpy has
undefined behaviour if the source and destination strings overlap.

I have undone the previous change, fixed the length check, and replaced the
strcpy call with memmove, which does permit the buffers to overlap. (The
trim_cr_lf function always zero-terminates the buffer so that is already
taken care of.)

- Jim

On Fri, 5 Feb 2021 at 19:28, Alex Henrie <ale...@gm...> wrote:

> This bug was identified by cppcheck.
> ---
>  agg-2.4/examples/mol_view.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/agg-2.4/examples/mol_view.cpp b/agg-2.4/examples/mol_view.cpp
> index 7813dc3..adba034 100644
> --- a/agg-2.4/examples/mol_view.cpp
> +++ b/agg-2.4/examples/mol_view.cpp
> @@ -205,7 +205,7 @@ bool molecule::read(FILE* fd)
>      if(len > 128) len = 128;
>
>      if(len) memcpy(m_name, buf, len);
> -    m_name[len] = 0;
> +    m_name[len-1] = 0;
>
>      if(!fgets(buf, 510, fd)) return false;
>      if(!fgets(buf, 510, fd)) return false;
> --
> 2.30.0
>

[AGG] [PATCH] Fix off-by-one error in mol_view example

[Alex H. <ale...@gm...>]

This bug was identified by cppcheck.
---
 agg-2.4/examples/mol_view.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/agg-2.4/examples/mol_view.cpp b/agg-2.4/examples/mol_view.cpp
index 7813dc3..adba034 100644
--- a/agg-2.4/examples/mol_view.cpp
+++ b/agg-2.4/examples/mol_view.cpp
@@ -205,7 +205,7 @@ bool molecule::read(FILE* fd)
     if(len > 128) len = 128;
 
     if(len) memcpy(m_name, buf, len);
-    m_name[len] = 0;
+    m_name[len-1] = 0;
 
     if(!fgets(buf, 510, fd)) return false;
     if(!fgets(buf, 510, fd)) return false;
-- 
2.30.0

Re: [AGG] Trouble initializing buffer in constructor

[Stephan A. <sup...@gm...>]

Hi,

you are pointing member variables of the Plot class to a bunch of temporary variables (allocated on the stack). These go out of scope when the constructor is finished, and then the member variables point to invalid objects (they have been deallocated). You need to declare all the variables you need in the constructor as members of the Plot class. No objects of the „pipeline“ should be temporary.

Best regards,
Stephan 

> Am 12.06.2019 um 21:43 schrieb KarthikRIyer <Kar...@ya...>:
> 
> Hi,
> 
> I want to initialize the buffer that I want to use inside a constructor. But
> doing that is giving me a segmentation fault as follows when run using gdb:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555588680 in agg::blender_rgb<agg::rgba8,
> agg::order_rgb>::blend_pix (p=0x264d4b42129b <error: Cannot access memory at
> address 0x264d4b42129b>, cr=0, cg=0, cb=0, alpha=34, cover=34)
>    at /home/karthik/swiftplot/framework/AGG/include/agg_pixfmt_rgb.h:91
> 91                p[Order::R] += (value_type)(((cr - p[Order::R]) * alpha) >>
> base_shift);
> 
> 
> But everything works fine when I initialize it in the class directly.
> 
> Here's the initializing part of the code:
> 
> class Plot{
> 
>  public:
>    agg::rasterizer_scanline_aa<> m_ras;
>    agg::scanline_p8              m_sl_p8;
>    agg::line_cap_e roundCap = agg::round_cap;
>    renderer_aa ren_aa;
>    int pngBufferSize = 0;
> 
>    unsigned char* buffer;
> 
> 
>    agg::int8u*           m_pattern;
>    agg::rendering_buffer m_pattern_rbuf;
>    renderer_base_pre rb_pre;
> 
>    Plot(float width, float height, float subW, float subH){
>      frame_width = width;
>      frame_height = height;
>      sub_width = subW;
>      sub_height = subH;
>      buffer = new unsigned char[frame_width*frame_height*3];
>      agg::rendering_buffer rbuf = agg::rendering_buffer(buffer,
> frame_width, frame_height, -frame_width*3);
>      pixfmt pixf = pixfmt(rbuf);
>      renderer_base rb = renderer_base(pixf);
>      ren_aa = renderer_aa(rb);
>      pixfmt_pre pixf_pre(rbuf);
>      rb_pre = renderer_base_pre(pixf_pre);
>    }
> 
> How can I solve this? I need to set the buffer size in the constructor so
> that the end user can choose he size of the image he/she wants.
> 
> Thanks,
> Karthik
> 
> 
> 
> 
> --
> Sent from: http://anti-grain-geometry.1086185.n5.nabble.com/
> 
> 
> _______________________________________________
> Vector-agg-general mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

[AGG] Trouble initializing buffer in constructor

[KarthikRIyer <Kar...@ya...>]

Hi,

I want to initialize the buffer that I want to use inside a constructor. But
doing that is giving me a segmentation fault as follows when run using gdb:

Program received signal SIGSEGV, Segmentation fault.
0x0000555555588680 in agg::blender_rgb<agg::rgba8,
agg::order_rgb>::blend_pix (p=0x264d4b42129b <error: Cannot access memory at
address 0x264d4b42129b>, cr=0, cg=0, cb=0, alpha=34, cover=34)
    at /home/karthik/swiftplot/framework/AGG/include/agg_pixfmt_rgb.h:91
91	            p[Order::R] += (value_type)(((cr - p[Order::R]) * alpha) >>
base_shift);


But everything works fine when I initialize it in the class directly.

Here's the initializing part of the code:

class Plot{

  public:
    agg::rasterizer_scanline_aa<> m_ras;
    agg::scanline_p8              m_sl_p8;
    agg::line_cap_e roundCap = agg::round_cap;
    renderer_aa ren_aa;
    int pngBufferSize = 0;

    unsigned char* buffer;


    agg::int8u*           m_pattern;
    agg::rendering_buffer m_pattern_rbuf;
    renderer_base_pre rb_pre;

    Plot(float width, float height, float subW, float subH){
      frame_width = width;
      frame_height = height;
      sub_width = subW;
      sub_height = subH;
      buffer = new unsigned char[frame_width*frame_height*3];
      agg::rendering_buffer rbuf = agg::rendering_buffer(buffer,
frame_width, frame_height, -frame_width*3);
      pixfmt pixf = pixfmt(rbuf);
      renderer_base rb = renderer_base(pixf);
      ren_aa = renderer_aa(rb);
      pixfmt_pre pixf_pre(rbuf);
      rb_pre = renderer_base_pre(pixf_pre);
    }

How can I solve this? I need to set the buffer size in the constructor so
that the end user can choose he size of the image he/she wants.

Thanks,
Karthik




--
Sent from: http://anti-grain-geometry.1086185.n5.nabble.com/

Re: [AGG] Trouble with filling pattern in a rectangle

[Karthik I. <kar...@ya...>]

<div>Thanks a lot Stephan. I changed <span style="background-color:#ffffff;color:#000000;float:none;font-family:'arial' , sans-serif;font-size:15px;font-style:normal;font-weight:400;text-decoration-style:initial;text-transform:none;white-space:pre-wrap;word-spacing:0px">agg::span_pattern_rgba to agg::span_pattern_rgb and it worked! </span></div><div><br /></div><div><br /></div><div>02.06.2019, 14:03, "Stephan Aßmus" &lt;sup...@gm...&gt;:</div><blockquote><p>Hi,<br /><br />just to give you a quick reply, the templates need to be declared in<br />such a way that they fit together. You are defining your "pixel format"<br />type to RGB24, which has no alpha channel, and then you are trying to<br />use that with classes that expect an alpha channel (typedef<br />agg::span_pattern_rgba). You need to make sure that everything matches.<br /><br />The "typedefs" at the beginning of your code make sure that they are<br />consistent, because they are based on each other. You can change<br />something in the beginning and the later declarations automatically<br />adjust. But then in your code, you have additional typedefs and template<br />declarations which are not based on the earlier typedefs and are<br />therefore not forced to match.<br /><br />Often, you also need to adjust the #includes, especially when switching<br />between classes with alpha and without alpha, since they are declared in<br />different .h files.<br /><br />Hope this helps,<br />-Stephan<br /><br />Am 02.06.2019 um 09:06 schrieb KarthikRIyer:<br /></p><blockquote class="b4fd5cf2ec92bc68cb898700bb81355fwmi-quote"> #define AGG_RGB24<br /> typedef agg::pixfmt_rgb24 pixfmt;<br /> typedef agg::renderer_base&lt;pixfmt&gt; renderer_base;<br /> typedef agg::renderer_base&lt;pixfmt_pre&gt; renderer_base_pre;<br /> typedef agg::renderer_scanline_aa_solid&lt;renderer_base&gt; renderer_aa;<br /> typedef agg::renderer_scanline_bin_solid&lt;renderer_base&gt; renderer_bin;<br /> typedef agg::rasterizer_scanline_aa&lt;&gt; rasterizer_scanline;<br /> typedef agg::scanline_p8 scanline;<br /> typedef agg::rgba Color;<br />      agg::rasterizer_scanline_aa&lt;&gt; m_ras;<br />      agg::scanline_p8              m_sl_p8;<br />      agg::line_cap_e roundCap = agg::round_cap;<br />      renderer_base rb;<br />      renderer_aa ren_aa;<br />      int pngBufferSize = 0;<br /><br />      agg::int8u*           m_pattern;<br />      agg::rendering_buffer m_pattern_rbuf;<br />      agg::path_storage m_ps;<br />      renderer_base_pre rb_pre;<br />      rb = renderer_base(pixf);<br />      ren_aa = renderer_aa(rb);<br />      rb_pre = renderer_base_pre(pixf_pre);<br /><br /><br /> void generate_pattern(){<!-- --><br />        m_ps.move_to(0,0);<br />        m_ps.line_to(10,10);<br />        int size = 10;<br />        agg::conv_stroke&lt;agg::path_storage&gt; stroke(m_ps);<br />        stroke.width(5);<br />        m_pattern = new agg::int8u[size * size * 3];<br />        m_pattern_rbuf.attach(m_pattern, size, size, size*3);<br />        pixfmt pixf1(m_pattern_rbuf);<br />        agg::renderer_base&lt;pixfmt&gt; rb1(pixf);<br />        agg::renderer_scanline_aa_solid&lt;agg::renderer_base&amp;lt;pixfmt&gt; &gt;<br /> rs1(rb1);<br />        rb.clear(agg::rgba_pre(1, 1, 1, 0));<br />        m_ras.add_path(stroke);<br />        rs1.color(agg::rgba8(0,0,0));<br />        agg::render_scanlines(m_ras, m_sl_p8, rs1);<br />      }<br /><br />      void draw_solid_rect_transformed(const float *x, const float *y, float<br /> r, float g, float b, float a){<!-- --><br />        generate_pattern();<br />        agg::path_storage rect_path;<br />        rect_path.move_to(*x, *y);<br />        for (int i = 1; i &lt; 4; i++) {<!-- --><br />          rect_path.line_to(*(x+i),*(y+i));<br />        }<br />        rect_path.close_polygon();<br />        agg::trans_affine matrix;<br />        matrix *= agg::trans_affine_translation(sub_width*0.1f,<br /> sub_height*0.1f);<br />        agg::conv_transform&lt;agg::path_storage, agg::trans_affine&gt;<br /> trans(rect_path, matrix);<br />        // m_ras.add_path(trans);<br />        // Color c(r, g, b, a);<br />        // ren_aa.color(c);<br />        // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);<br /><br />        typedef agg::wrap_mode_reflect_auto_pow2 wrap_x_type;<br />        typedef agg::wrap_mode_reflect_auto_pow2 wrap_y_type;<br />        typedef agg::image_accessor_wrap&lt;pixfmt,<br />                                         wrap_x_type,<br />                                         wrap_y_type&gt; img_source_type;<br />        typedef agg::span_pattern_rgba&lt;img_source_type&gt; span_gen_type;<br />        agg::span_allocator&lt;color_type&gt; sa;<br />        pixfmt          img_pixf(m_pattern_rbuf);<br />        img_source_type img_src(img_pixf);<br />        span_gen_type sg(img_src, 0,0);<br />        sg.alpha(span_gen_type::value_type(0.6 * 255.0));<br /><br />        m_ras.add_path(trans);<br />        Color c(r, g, b, a);<br />        // ren_aa.color(c);<br />        // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);<br />        agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);<br /><br />      }<br /><br /> I need to add some hatching to a rectangle am trying to follow the pattern<br /> fill example in the demo.<br /> Above is the code I'm trying out.<br /><br /> Can someone please explain how the pattern fill works?<br /><br /> I'm getting this error while compiling:<br /> //home/karthik/swiftplot/framework/AGG/include/agg_span_pattern_rgba.h:77:41:<br /> error: no member named 'A' in 'agg::order_rgb'<br />                  span-&gt;a = p[order_type::A];<br />                                          ^<br /> /home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:168:22:<br /> note<br /> : in instantiation of member function<br /> 'agg::span_pattern_rgba&lt;agg::image_accessor_wrap&amp;lt;agg::pixfmt_alpha_blend_rgb&amp;lt;agg::blender_rgb&amp;lt;agg::rgba8,<br /> agg::order_rgb&gt;, agg::row_accessor&lt;unsigned char&gt; &gt;,<br /> agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2&gt;<br /><blockquote class="b4fd5cf2ec92bc68cb898700bb81355fwmi-quote"> ::generate' requested here<br /></blockquote>              span_gen.generate(colors, x, y, len);<br />                       ^<br /><br /> /home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:189:17:<br /> note: in instantiation of function template specialization<br /> 'agg::render_scanline_aa&lt;agg::scanline_p8,<br /> agg::renderer_base&amp;lt;agg::pixfmt_alpha_blend_rgb&amp;lt;agg::blender_rgb_pre&amp;lt;agg::rgba8,<br /> agg::order_rgb&gt;, agg::row_accessor&lt;unsigned char&gt; &gt; &gt;,<br /> agg::span_allocator&lt;agg::rgba8&gt;,<br /> agg::span_pattern_rgba&lt;agg::image_accessor_wrap&amp;lt;agg::pixfmt_alpha_blend_rgb&amp;lt;agg::blender_rgb&amp;lt;agg::rgba8,<br /> agg::order_rgb&gt;, agg::row_accessor&lt;unsigned char&gt; &gt;,<br /> agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2&gt; &gt; &gt;'<br /> requested here<br /><br />                  render_scanline_aa(sl, ren, alloc, span_gen);<br />                  ^<br /> /home/karthik/swiftplot/framework/AGGRenderer/CPPAGGRenderer/CPPAGGRenderer.cpp:167:12:<br /> note: in instantiation of function template specialization<br /> 'agg::render_scanlines_aa&lt;agg::rasterizer_scanline_aa&amp;lt;agg::rasterizer_sl_clip&amp;lt;agg::ras_conv_int&gt;<br /><blockquote class="b4fd5cf2ec92bc68cb898700bb81355fwmi-quote"> , agg::scanline_p8,<br /></blockquote> agg::renderer_base&lt;agg::pixfmt_alpha_blend_rgb&amp;lt;agg::blender_rgb_pre&amp;lt;agg::rgba8,<br /> agg::order_rgb&gt;, agg::row_accessor&lt;unsigned char&gt; &gt; &gt;,<br /> agg::span_allocator&lt;agg::rgba8&gt;,<br /> agg::span_pattern_rgba&lt;agg::image_accessor_wrap&amp;lt;agg::pixfmt_alpha_blend_rgb&amp;lt;agg::blender_rgb&amp;lt;agg::rgba8,<br /> agg::order_rgb&gt;, agg::row_accessor&lt;unsigned char&gt; &gt;,<br /> agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2&gt; &gt; &gt;'<br /> requested here<br /><br />        agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);<br /> /<br /><br /><br /><br /><br /> --<br /> Sent from: <a href="http://anti-grain-geometry.1086185.n5.nabble.com/">http://anti-grain-geometry.1086185.n5.nabble.com/</a><br /><br /><br /> _______________________________________________<br /> Vector-agg-general mailing list<br /> <a href="mailto:Vec...@li...">Vec...@li...</a><br /> <a href="https://lists.sourceforge.net/lists/listinfo/vector-agg-general">https://lists.sourceforge.net/lists/listinfo/vector-agg-general</a><br /><br /></blockquote><p><br /><br /><br />_______________________________________________<br />Vector-agg-general mailing list<br /><a href="mailto:Vec...@li...">Vec...@li...</a><br /><a href="https://lists.sourceforge.net/lists/listinfo/vector-agg-general">https://lists.sourceforge.net/lists/listinfo/vector-agg-general</a><br /></p></blockquote><div><br /></div><div><br /></div><div>-- </div><div>Karthik</div><div><br /></div>

Re: [AGG] Trouble with filling pattern in a rectangle

[Stephan A. <sup...@gm...>]

Hi,

just to give you a quick reply, the templates need to be declared in
such a way that they fit together. You are defining your "pixel format"
type to RGB24, which has no alpha channel, and then you are trying to
use that with classes that expect an alpha channel (typedef
agg::span_pattern_rgba). You need to make sure that everything matches.

The "typedefs" at the beginning of your code make sure that they are
consistent, because they are based on each other. You can change
something in the beginning and the later declarations automatically
adjust. But then in your code, you have additional typedefs and template
declarations which are not based on the earlier typedefs and are
therefore not forced to match.

Often, you also need to adjust the #includes, especially when switching
between classes with alpha and without alpha, since they are declared in
different .h files.

Hope this helps,
-Stephan

Am 02.06.2019 um 09:06 schrieb KarthikRIyer:
> #define AGG_RGB24
> typedef agg::pixfmt_rgb24 pixfmt;
> typedef agg::renderer_base<pixfmt> renderer_base;
> typedef agg::renderer_base<pixfmt_pre> renderer_base_pre;
> typedef agg::renderer_scanline_aa_solid<renderer_base> renderer_aa;
> typedef agg::renderer_scanline_bin_solid<renderer_base> renderer_bin;
> typedef agg::rasterizer_scanline_aa<> rasterizer_scanline;
> typedef agg::scanline_p8 scanline;
> typedef agg::rgba Color;
>      agg::rasterizer_scanline_aa<> m_ras;
>      agg::scanline_p8              m_sl_p8;
>      agg::line_cap_e roundCap = agg::round_cap;
>      renderer_base rb;
>      renderer_aa ren_aa;
>      int pngBufferSize = 0;
>
>      agg::int8u*           m_pattern;
>      agg::rendering_buffer m_pattern_rbuf;
>      agg::path_storage m_ps;
>      renderer_base_pre rb_pre;
>      rb = renderer_base(pixf);
>      ren_aa = renderer_aa(rb);
>      rb_pre = renderer_base_pre(pixf_pre);
>
>
> void generate_pattern(){
>        m_ps.move_to(0,0);
>        m_ps.line_to(10,10);
>        int size = 10;
>        agg::conv_stroke<agg::path_storage> stroke(m_ps);
>        stroke.width(5);
>        m_pattern = new agg::int8u[size * size * 3];
>        m_pattern_rbuf.attach(m_pattern, size, size, size*3);
>        pixfmt pixf1(m_pattern_rbuf);
>        agg::renderer_base<pixfmt> rb1(pixf);
>        agg::renderer_scanline_aa_solid<agg::renderer_base&lt;pixfmt> >
> rs1(rb1);
>        rb.clear(agg::rgba_pre(1, 1, 1, 0));
>        m_ras.add_path(stroke);
>        rs1.color(agg::rgba8(0,0,0));
>        agg::render_scanlines(m_ras, m_sl_p8, rs1);
>      }
>
>      void draw_solid_rect_transformed(const float *x, const float *y, float
> r, float g, float b, float a){
>        generate_pattern();
>        agg::path_storage rect_path;
>        rect_path.move_to(*x, *y);
>        for (int i = 1; i < 4; i++) {
>          rect_path.line_to(*(x+i),*(y+i));
>        }
>        rect_path.close_polygon();
>        agg::trans_affine matrix;
>        matrix *= agg::trans_affine_translation(sub_width*0.1f,
> sub_height*0.1f);
>        agg::conv_transform<agg::path_storage, agg::trans_affine>
> trans(rect_path, matrix);
>        // m_ras.add_path(trans);
>        // Color c(r, g, b, a);
>        // ren_aa.color(c);
>        // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);
>
>        typedef agg::wrap_mode_reflect_auto_pow2 wrap_x_type;
>        typedef agg::wrap_mode_reflect_auto_pow2 wrap_y_type;
>        typedef agg::image_accessor_wrap<pixfmt,
>                                         wrap_x_type,
>                                         wrap_y_type> img_source_type;
>        typedef agg::span_pattern_rgba<img_source_type> span_gen_type;
>        agg::span_allocator<color_type> sa;
>        pixfmt          img_pixf(m_pattern_rbuf);
>        img_source_type img_src(img_pixf);
>        span_gen_type sg(img_src, 0,0);
>        sg.alpha(span_gen_type::value_type(0.6 * 255.0));
>
>        m_ras.add_path(trans);
>        Color c(r, g, b, a);
>        // ren_aa.color(c);
>        // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);
>        agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);
>
>      }
>
> I need to add some hatching to a rectangle am trying to follow the pattern
> fill example in the demo.
> Above is the code I'm trying out.
>
> Can someone please explain how the pattern fill works?
>
> I'm getting this error while compiling:
> //home/karthik/swiftplot/framework/AGG/include/agg_span_pattern_rgba.h:77:41:
> error: no member named 'A' in 'agg::order_rgb'
>                  span->a = p[order_type::A];
>                                          ^
> /home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:168:22:
> note
> : in instantiation of member function
> 'agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
> agg::order_rgb>, agg::row_accessor<unsigned char> >,
> agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2>
>> ::generate' requested here
>              span_gen.generate(colors, x, y, len);
>                       ^
>
> /home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:189:17:
> note: in instantiation of function template specialization
> 'agg::render_scanline_aa<agg::scanline_p8,
> agg::renderer_base&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb_pre&lt;agg::rgba8,
> agg::order_rgb>, agg::row_accessor<unsigned char> > >,
> agg::span_allocator<agg::rgba8>,
> agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
> agg::order_rgb>, agg::row_accessor<unsigned char> >,
> agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2> > >'
> requested here
>
>                  render_scanline_aa(sl, ren, alloc, span_gen);
>                  ^
> /home/karthik/swiftplot/framework/AGGRenderer/CPPAGGRenderer/CPPAGGRenderer.cpp:167:12:
> note: in instantiation of function template specialization
> 'agg::render_scanlines_aa<agg::rasterizer_scanline_aa&lt;agg::rasterizer_sl_clip&lt;agg::ras_conv_int>
>> , agg::scanline_p8,
> agg::renderer_base<agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb_pre&lt;agg::rgba8,
> agg::order_rgb>, agg::row_accessor<unsigned char> > >,
> agg::span_allocator<agg::rgba8>,
> agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
> agg::order_rgb>, agg::row_accessor<unsigned char> >,
> agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2> > >'
> requested here
>
>        agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);
> /
>
>
>
>
> --
> Sent from: http://anti-grain-geometry.1086185.n5.nabble.com/
>
>
> _______________________________________________
> Vector-agg-general mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

[AGG] Trouble with filling pattern in a rectangle

[KarthikRIyer <Kar...@ya...>]

#define AGG_RGB24
typedef agg::pixfmt_rgb24 pixfmt;
typedef agg::renderer_base<pixfmt> renderer_base;
typedef agg::renderer_base<pixfmt_pre> renderer_base_pre;
typedef agg::renderer_scanline_aa_solid<renderer_base> renderer_aa;
typedef agg::renderer_scanline_bin_solid<renderer_base> renderer_bin;
typedef agg::rasterizer_scanline_aa<> rasterizer_scanline;
typedef agg::scanline_p8 scanline;
typedef agg::rgba Color;
    agg::rasterizer_scanline_aa<> m_ras;
    agg::scanline_p8              m_sl_p8;
    agg::line_cap_e roundCap = agg::round_cap;
    renderer_base rb;
    renderer_aa ren_aa;
    int pngBufferSize = 0;

    agg::int8u*           m_pattern;
    agg::rendering_buffer m_pattern_rbuf;
    agg::path_storage m_ps;
    renderer_base_pre rb_pre;
    rb = renderer_base(pixf);
    ren_aa = renderer_aa(rb);
    rb_pre = renderer_base_pre(pixf_pre);


void generate_pattern(){
      m_ps.move_to(0,0);
      m_ps.line_to(10,10);
      int size = 10;
      agg::conv_stroke<agg::path_storage> stroke(m_ps);
      stroke.width(5);
      m_pattern = new agg::int8u[size * size * 3];
      m_pattern_rbuf.attach(m_pattern, size, size, size*3);
      pixfmt pixf1(m_pattern_rbuf);
      agg::renderer_base<pixfmt> rb1(pixf);
      agg::renderer_scanline_aa_solid<agg::renderer_base&lt;pixfmt> >
rs1(rb1);
      rb.clear(agg::rgba_pre(1, 1, 1, 0));
      m_ras.add_path(stroke);
      rs1.color(agg::rgba8(0,0,0));
      agg::render_scanlines(m_ras, m_sl_p8, rs1);
    }

    void draw_solid_rect_transformed(const float *x, const float *y, float
r, float g, float b, float a){
      generate_pattern();
      agg::path_storage rect_path;
      rect_path.move_to(*x, *y);
      for (int i = 1; i < 4; i++) {
        rect_path.line_to(*(x+i),*(y+i));
      }
      rect_path.close_polygon();
      agg::trans_affine matrix;
      matrix *= agg::trans_affine_translation(sub_width*0.1f,
sub_height*0.1f);
      agg::conv_transform<agg::path_storage, agg::trans_affine>
trans(rect_path, matrix);
      // m_ras.add_path(trans);
      // Color c(r, g, b, a);
      // ren_aa.color(c);
      // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);

      typedef agg::wrap_mode_reflect_auto_pow2 wrap_x_type;
      typedef agg::wrap_mode_reflect_auto_pow2 wrap_y_type;
      typedef agg::image_accessor_wrap<pixfmt,
                                       wrap_x_type,
                                       wrap_y_type> img_source_type;
      typedef agg::span_pattern_rgba<img_source_type> span_gen_type;
      agg::span_allocator<color_type> sa;
      pixfmt          img_pixf(m_pattern_rbuf);
      img_source_type img_src(img_pixf);
      span_gen_type sg(img_src, 0,0);
      sg.alpha(span_gen_type::value_type(0.6 * 255.0));

      m_ras.add_path(trans);
      Color c(r, g, b, a);
      // ren_aa.color(c);
      // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);
      agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);

    }

I need to add some hatching to a rectangle am trying to follow the pattern
fill example in the demo.
Above is the code I'm trying out.

Can someone please explain how the pattern fill works?

I'm getting this error while compiling:
//home/karthik/swiftplot/framework/AGG/include/agg_span_pattern_rgba.h:77:41:
error: no member named 'A' in 'agg::order_rgb'
                span->a = p[order_type::A];
                                        ^
/home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:168:22:
note
: in instantiation of member function
'agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> >,
agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2>
>::generate' requested here
            span_gen.generate(colors, x, y, len);
                     ^

/home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:189:17:
note: in instantiation of function template specialization
'agg::render_scanline_aa<agg::scanline_p8,
agg::renderer_base&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb_pre&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> > >,
agg::span_allocator<agg::rgba8>,
agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> >,
agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2> > >'
requested here

                render_scanline_aa(sl, ren, alloc, span_gen);
                ^
/home/karthik/swiftplot/framework/AGGRenderer/CPPAGGRenderer/CPPAGGRenderer.cpp:167:12:
note: in instantiation of function template specialization
'agg::render_scanlines_aa<agg::rasterizer_scanline_aa&lt;agg::rasterizer_sl_clip&lt;agg::ras_conv_int>
>, agg::scanline_p8,
agg::renderer_base<agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb_pre&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> > >,
agg::span_allocator<agg::rgba8>,
agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> >,
agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2> > >'
requested here

      agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);
/




--
Sent from: http://anti-grain-geometry.1086185.n5.nabble.com/

[AGG] Trouble with filling pattern in a rectangle

[KarthikRIyer <Kar...@ya...>]

#define AGG_RGB24
typedef agg::pixfmt_rgb24 pixfmt;
typedef agg::renderer_base<pixfmt> renderer_base;
typedef agg::renderer_base<pixfmt_pre> renderer_base_pre;
typedef agg::renderer_scanline_aa_solid<renderer_base> renderer_aa;
typedef agg::renderer_scanline_bin_solid<renderer_base> renderer_bin;
typedef agg::rasterizer_scanline_aa<> rasterizer_scanline;
typedef agg::scanline_p8 scanline;
typedef agg::rgba Color;
    agg::rasterizer_scanline_aa<> m_ras;
    agg::scanline_p8              m_sl_p8;
    agg::line_cap_e roundCap = agg::round_cap;
    renderer_base rb;
    renderer_aa ren_aa;
    int pngBufferSize = 0;

    agg::int8u*           m_pattern;
    agg::rendering_buffer m_pattern_rbuf;
    agg::path_storage m_ps;
    renderer_base_pre rb_pre;
    rb = renderer_base(pixf);
    ren_aa = renderer_aa(rb);
    rb_pre = renderer_base_pre(pixf_pre);


void generate_pattern(){
      m_ps.move_to(0,0);
      m_ps.line_to(10,10);
      int size = 10;
      agg::conv_stroke<agg::path_storage> stroke(m_ps);
      stroke.width(5);
      m_pattern = new agg::int8u[size * size * 3];
      m_pattern_rbuf.attach(m_pattern, size, size, size*3);
      pixfmt pixf1(m_pattern_rbuf);
      agg::renderer_base<pixfmt> rb1(pixf);
      agg::renderer_scanline_aa_solid<agg::renderer_base&lt;pixfmt> >
rs1(rb1);
      rb.clear(agg::rgba_pre(1, 1, 1, 0));
      m_ras.add_path(stroke);
      rs1.color(agg::rgba8(0,0,0));
      agg::render_scanlines(m_ras, m_sl_p8, rs1);
    }

    void draw_solid_rect_transformed(const float *x, const float *y, float
r, float g, float b, float a){
      generate_pattern();
      agg::path_storage rect_path;
      rect_path.move_to(*x, *y);
      for (int i = 1; i < 4; i++) {
        rect_path.line_to(*(x+i),*(y+i));
      }
      rect_path.close_polygon();
      agg::trans_affine matrix;
      matrix *= agg::trans_affine_translation(sub_width*0.1f,
sub_height*0.1f);
      agg::conv_transform<agg::path_storage, agg::trans_affine>
trans(rect_path, matrix);
      // m_ras.add_path(trans);
      // Color c(r, g, b, a);
      // ren_aa.color(c);
      // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);

      typedef agg::wrap_mode_reflect_auto_pow2 wrap_x_type;
      typedef agg::wrap_mode_reflect_auto_pow2 wrap_y_type;
      typedef agg::image_accessor_wrap<pixfmt,
                                       wrap_x_type,
                                       wrap_y_type> img_source_type;
      typedef agg::span_pattern_rgba<img_source_type> span_gen_type;
      agg::span_allocator<color_type> sa;
      pixfmt          img_pixf(m_pattern_rbuf);
      img_source_type img_src(img_pixf);
      span_gen_type sg(img_src, 0,0);
      sg.alpha(span_gen_type::value_type(0.6 * 255.0));

      m_ras.add_path(trans);
      Color c(r, g, b, a);
      // ren_aa.color(c);
      // agg::render_scanlines(m_ras, m_sl_p8, ren_aa);
      agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);

    }

I need to add some hatching to a rectangle am trying to follow the pattern
fill example in the demo.
Above is the code I'm trying out.

Can someone please explain how the pattern fill works?

I'm getting this error while compiling:
//home/karthik/swiftplot/framework/AGG/include/agg_span_pattern_rgba.h:77:41:
error: no member named 'A' in 'agg::order_rgb'
                span->a = p[order_type::A];
                                        ^
/home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:168:22:
note
: in instantiation of member function
'agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> >,
agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2>
>::generate' requested here
            span_gen.generate(colors, x, y, len);
                     ^

/home/karthik/swiftplot/framework/AGG/include/agg_renderer_scanline.h:189:17:
note: in instantiation of function template specialization
'agg::render_scanline_aa<agg::scanline_p8,
agg::renderer_base&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb_pre&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> > >,
agg::span_allocator<agg::rgba8>,
agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> >,
agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2> > >'
requested here

                render_scanline_aa(sl, ren, alloc, span_gen);
                ^
/home/karthik/swiftplot/framework/AGGRenderer/CPPAGGRenderer/CPPAGGRenderer.cpp:167:12:
note: in instantiation of function template specialization
'agg::render_scanlines_aa<agg::rasterizer_scanline_aa&lt;agg::rasterizer_sl_clip&lt;agg::ras_conv_int>
>, agg::scanline_p8,
agg::renderer_base<agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb_pre&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> > >,
agg::span_allocator<agg::rgba8>,
agg::span_pattern_rgba<agg::image_accessor_wrap&lt;agg::pixfmt_alpha_blend_rgb&lt;agg::blender_rgb&lt;agg::rgba8,
agg::order_rgb>, agg::row_accessor<unsigned char> >,
agg::wrap_mode_reflect_auto_pow2, agg::wrap_mode_reflect_auto_pow2> > >'
requested here

      agg::render_scanlines_aa(m_ras, m_sl_p8, rb_pre, sa, sg);
/




--
Sent from: http://anti-grain-geometry.1086185.n5.nabble.com/

[AGG] Blend2D Beta Released

[Petr K. <kob...@gm...>]

Hi list,

I would like to announce the first beta release of the Blend2D library.
It's a cross-platform and high performance 2D vector graphics engine
written in C++ that implements many original ideas. At the moment Blend2D
focuses on software-based 2D rendering and tries to make it faster while
maintaining the same output quality as other 2D renderers [including AGG].
The thing that makes Blend2D unique is the JIT pipeline generator which is
able to merge several rendering steps into a single pipeline. Combining the
JIT pipelines with an improved analytic rasterizer and new stroking engine
results in Blend2D being very competitive in terms of performance.

What may be interesting to AGG users:

1. Blend2D rasterizer uses the same technique as AGG to calculate AA
coverages (cells), but it uses a dense-cell buffer combined with a shadow
bit-buffer to manage cells, which improves performance drastically for
complicated inputs. In addition, the rasterizer has no cell limit (as cells
are dense) so the only limit is the memory required to store edges (yes the
rasterizer uses edge table).

2. Blend2D uses a stroking engine that doesn't flatten inputs to line
segments. Of course curve offsets are also approximations, but they are
much more precise than line segments, which makes it possible to
post-transform stroked output without having to worry about
approximation_scale.

3. Blend2D uses JIT compiler to generate pipelines at runtime. The
generated pipelines consume rasterizer cells directly so there are no
scanline containers used by the engine. In fact the composition happens in
bands (several scanlines together) so a single pipeline can do a lot of
batched work, which improves fill rate.

Additionally, Blend2D comes with a benchmarking tool (bl_bench) and sample
packages. The benchmarking tool has also AGG backend so it can be used to
compare the performance of Blend2D and AGG. Our own results are shared on
Blend2D home page under Performance section (links below).

Let me know if you have any questions, thank you!

Links:
  https://blend2d.com - Blend2D home page
  https://blend2d.com/performance.html - Performance comparison with others
including AGG

Best,
- Petr

[AGG] Filling rasterizer instead of rendering

[Stephan A. <sup...@gm...>]

Hi guys,

it's been a while that I worked with AGG code, and I feel a bit rusty. I 
want to change some code that renders cached glyph bitmaps one by one 
using agg::render_scanlines() to transfer the bitmap contents instead to 
the rasterizer cells, and then agg::render_scanlines() the complete 
string in just one call.

Perhaps some background: The text rendering code I have here uses 
different code-paths for when the glyphs are cached bitmaps (originating 
from FreeType), or when they are vector paths. In case of bitmaps, each 
glyph is rendered by itself, in case of vector paths, each glyph is 
rasterized into the same rasterizer, and then after processing the last 
glyph, there is a final render pass. I need to make it so the processing 
is the same for the bitmap path as it is for the vector path. The reason 
being that there is a difference in output when a glyph touches the same 
pixels as the previous glyph (overlap). That's due to some strange way 
in which some drawing modes render the glyphs. It would not matter if it 
were normal alpha blending the foreground color with the existing 
background, but that's not always the case.

So is there an easy way to do something equivalent to 
rasterizer.add_path() with the glyph bitmap that's already rasterized, 
to have it end up as the rasterizer contents? Basically, I need to copy 
it into the rasterizer cells at the correct location.

Thanks a lot & best regards,
-Stephan

[AGG] New version of AGG coming to Debian/Ubuntu

[John H. <jo...@gl...>]

I am updating the libagg-dev Debian package to fix a packaging issue w.r.t
cross compilation. While I am at it I want to pick up some other changes:

1) Deliver a shared library version. There will also be a package libagg
that is just the runtime shared library support.
2) Pick up the patch request from matplotlib so that they can just depend
on libagg instead of embedding a version of agg with their additions and
bug fixes. I'm being selective about applying the matplotlib patch because
most of it seems to just be reverting our bug fixes and additons that
happened after their fork.
3) Bump the version to 2.6.0 because of the several compatible API
additions since AGG 2.4 started, skipping version 2.5. AGG 2.4 should
really have been AGG 3.0 because of the incompatibility with AGG 2.3.
4) Go all-in on the C++ standard library because it's 2018. All instances
of <math.h>, <stdlib.h>, <string.h>, etc are replaced with <cmath>,
<cstdlib>, <cstring>. All standard library functions are prefixed with
std:: Using the old C headers pollutes the global namespace with functions
and macros. With the C++ headers the functions typically are still at
global level, but the macros should not be.

-- john

[AGG] svg_viewer strangeness

[John H. <jo...@gl...>]

I'm tracking down a bug that was filed against the AGG svg_viewer example.
The svg_viewer parses SVG path elements in agg::path_storage objects. But
before it renders the path_storage it calls a method that examines every
subpath in path_storage and if it finds a subpath with clock-wise
orientation it reverses the order of the vertices in the subpath to make it
counter-clock-wise. Then it sets a flag in the subpath to indicate that
this inversion has occurred. This totally breaks non-zero filling rule if
you have a closed path with a hole inside it.

My question is why does this code even exist? Did an earlier version of AGG
implement non-zero filling using flags instead of directly calculating the
subpath orientation? I'm hesitating to check this one-line fix in until I
understand why Maxim went to considerable trouble to reorient subpaths.

-- john

Re: [AGG] AGG on Debian and Ubuntu

[John H. <jo...@gl...>]

I propose to simply replace the GPL'd AGG 2.5 on Debian with AGG 2.4,
including its liberal license. Giving it a Debian-specific version of 2.5.4
is just to get the Debian tools to accept that this is an upgrade to AGG
2.5. There will be no changes to the AGG 2.4 license. Downstream users of
libagg should have no issue with the license becoming more relaxed.

Libagg on Debian already has a patch that uses std::numeric_limits<>, so I
am not adding anything new. I should have realized that before.

-- john

On Sun, Jun 11, 2017 at 11:00 AM Jim Barry via Vector-agg-general <
vec...@li...> wrote:

> Hi John,
>
> AGG historically avoided using the C++ standard library, though there is
> no real reason why that should continue.
>
> Don't forget that AGG 2.4 has a permissive licence, incompatible with the
> GPL. I find such licensing issues quite hard to comprehend, but I suppose
> this means that significant contributors to AGG 2.4 must consent to their
> code being included in the GPL'd AGG 2.5? I certainly have no objection to
> that.
>
> Cheers,
>
> - Jim
>
>
> On 11 June 2017 at 17:39, John Horigan <jo...@gl...> wrote:
>
>> Hi Jerry. I avoided std::numeric_limits<> because I thought that it was a
>> C++11 feature. But I checked and it isn't. I will create new patches
>> replacing the macros with std:: namespace constants.
>>
>> -- john
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Vector-agg-general mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

Re: [AGG] AGG on Debian and Ubuntu

[Jim B. <ji...@ch...>]

Hi John,

AGG historically avoided using the C++ standard library, though there is no
real reason why that should continue.

Don't forget that AGG 2.4 has a permissive licence, incompatible with the
GPL. I find such licensing issues quite hard to comprehend, but I suppose
this means that significant contributors to AGG 2.4 must consent to their
code being included in the GPL'd AGG 2.5? I certainly have no objection to
that.

Cheers,

- Jim

On 11 June 2017 at 17:39, John Horigan <jo...@gl...> wrote:

> Hi Jerry. I avoided std::numeric_limits<> because I thought that it was a
> C++11 feature. But I checked and it isn't. I will create new patches
> replacing the macros with std:: namespace constants.
>
> -- john
>

Re: [AGG] AGG on Debian and Ubuntu

[John H. <jo...@gl...>]

Here is the Debian crash fix patch without any 0x7FFFFFFF changes and an
new No32bit patch that uses std::numeric_limits<int>::max()/min().

-- john


On Sun, Jun 11, 2017 at 9:39 AM John Horigan <jo...@gl...> wrote:

> Hi Jerry. I avoided std::numeric_limits<> because I thought that it was a
> C++11 feature. But I checked and it isn't. I will create new patches
> replacing the macros with std:: namespace constants.
>
> -- john
>
> On Sun, Jun 11, 2017 at 6:23 AM Jerry Evans <je...@no...> wrote:
>
>> Hello John
>>
>> Good to see someone grabbing the horse. Thank you.
>>
>> >> -- agg24No32bitIntAssumption.diff I noticed that AGG is littered with
>> the constant 0x7FFFFFFF, INT_MAX for 32-bit integers. This patch replaces
>> all of them with the INT_MAX/INT_MIN macros.
>>
>> Suggest these might be better replaced with the C++ standards in <limits>
>> ?
>>
>> BR.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Vector-agg-general mailing list
>> Vec...@li...
>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>>
>

Re: [AGG] AGG on Debian and Ubuntu

[John H. <jo...@gl...>]

Hi Jerry. I avoided std::numeric_limits<> because I thought that it was a
C++11 feature. But I checked and it isn't. I will create new patches
replacing the macros with std:: namespace constants.

-- john

On Sun, Jun 11, 2017 at 6:23 AM Jerry Evans <je...@no...> wrote:

> Hello John
>
> Good to see someone grabbing the horse. Thank you.
>
> >> -- agg24No32bitIntAssumption.diff I noticed that AGG is littered with
> the constant 0x7FFFFFFF, INT_MAX for 32-bit integers. This patch replaces
> all of them with the INT_MAX/INT_MIN macros.
>
> Suggest these might be better replaced with the C++ standards in <limits> ?
>
> BR.
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Vector-agg-general mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

Re: [AGG] AGG on Debian and Ubuntu

[Jerry E. <je...@no...>]

Hello John

Good to see someone grabbing the horse. Thank you.

>> -- agg24No32bitIntAssumption.diff I noticed that AGG is littered with the constant 0x7FFFFFFF, INT_MAX for 32-bit integers. This patch replaces all of them with the INT_MAX/INT_MIN macros.

Suggest these might be better replaced with the C++ standards in <limits> ?

BR.

[AGG] AGG on Debian and Ubuntu

[John H. <jo...@gl...>]

Debian has a package called libagg-dev that installs libagg.a and all of
the headers for AGG 2.5. This package is orphaned and I am thinking of
taking it over and updating it to AGG 2.4 from SourceForge. Unless we
update AGG 2.4 to 2.6 I will have to create a fictitious Debian version
like 2.5.4.117 to represent AGG 2.4-r117.

I am attaching some patches to AGG 2.4 that come from Debian and Ubuntu:

-- agg24debiancrashfix.diff fixes a crash that happens when drawing really
long lines triggers signed integer overflow in agg_rasterizer_cells_aa.
Debian uses a patch that detects if overflow is likely and doesn't draw the
line. I have replaced it with a patch that uses 64-bit math in a few places
where 32-bit integer math isn't correct.

-- agg24debianfailtobuildfix.diff fixes a build failure on some systems
using clang

-- agg24noUB.diff eliminates another place where signed overflow could
result in undefined behavior. The patch shouldn't effect code generation
but it may inhibit unsafe compiler optimizations.

-- agg24No32bitIntAssumption.diff I noticed that AGG is littered with the
constant 0x7FFFFFFF, INT_MAX for 32-bit integers. This patch replaces all
of them with the INT_MAX/INT_MIN macros.

-- agg24unusedparams.diff This is a patch from my personal copy of AGG. It
just silences some unused parameter warnings.

I have applied all of these patches and then built and run all of the
examples. Everything seemed to be OK.

-- john

Re: [AGG] B2dPipe - 2D Pipeline Compiler

[Ben H. <be...@im...>]

Awesome - I’ve used AGG for years (as well as AsmJit), and followed the news on your projects here. Very excited to see what you’ve achieved here. I’m primarily interested in using this from C++ code.

Ben

From: Petr Kobalíček [mailto:kob...@gm...]
Sent: Friday, February 17, 2017 5:12 PM
To: Anti-Grain Geometry <vec...@li...>
Subject: Re: [AGG] B2dPipe - 2D Pipeline Compiler

Hi Ben,

All images on https://blend2d.com site were rendered by Blend2D through B2dPipe. I have many demos, some use C++ and some node.js (through JS bindings of Blend2D). However, demos and benchmarks will be published after I release the main product - Blend2D. B2dPipe was released as a separate project to allow others to also benefit from JIT, and I posted it here because I also use analytic rasterizer similar to AGG.

I'm really looking forward to publish all the benchmarks I have as the results are really impressive, but it will have to wait a bit until Blend2D alpha is released. I compare with Cairo and Qt, and if I publish my results now there would be no way to verify the numbers are accurate.

I plan to release Blend2D at the end of February / start of March, so let's see if I can make it on schedule :)

Best,
Petr


On Fri, Feb 17, 2017 at 9:18 AM, Ben Harper <be...@im...<mailto:be...@im...>> wrote:
Sounds awesome. Do you have a demo using b2dpipe to produce actual pixels, and do you have performance numbers?

From: Petr Kobalíček [mailto:kob...@gm...<mailto:kob...@gm...>]
Sent: Friday, January 27, 2017 3:13 PM
To: Anti-Grain Geometry <vec...@li...<mailto:vec...@li...>>
Subject: [AGG] B2dPipe - 2D Pipeline Compiler

Hi list,

I would like to announce a first release of b2dpipe library. It's a 2D pipeline compiler written in C++ that I developed as a part of Blend2D project. It currently implements only 32-bit pixel formats and there are some missing features that should be finished before general use, but I think it's in a good shape for experimenting and contributing.

It's not a 2D engine and the library doesn't provide any 2D drawing context. It's a low-level library allowing you to define a 2D pipeline and to compile it at runtime by using a JIT compiler. This means that the library can be used in any rendering engine as a software-based rendering backend.

What b2dpipe offers at the moment:

  * ARGB32 (premultiplied) and XRGB32 pixel formats
  * Acceleration of various compositing and blending operators
  * Acceleration of rendering gradiends and textures
  * Acceleration of semi-transparent blits
  * 3 fill types (2 rectangle fills and one analytic)

The library doesn't provide its own rasterizer, and I don't know if it should be part of it (I guess I will put it in a separate project instead), but it has an implementation of calculating alpha coverage based on the same analytic method as used by FreeType and AGG. Base structures are defined in b2dpipe::FillData::Analytic, most importantly Analytic::Cell and Analytic::Span, which are analogous to antigrain cell and array of cells. I would provide more details to anyone who is interested about this.

Blend2D project:

  https://blend2d.com

B2dPipe repository:

  https://github.com/blend2d/b2dpipe

Thanks for your attention, and hopes for your contribution!

Best,
Petr
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. Please notify the sender by replying to this message and then delete it from your system. Please report email abuse / misuse to IMQS Software<http://www.imqs.co.za>.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Vector-agg-general mailing list
Vec...@li...<mailto:Vec...@li...>
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. Please notify the sender by replying to this message and then delete it from your system. Please report email abuse / misuse to IMQS Software<www.imqs.co.za>.

Re: [AGG] B2dPipe - 2D Pipeline Compiler

[Petr K. <kob...@gm...>]

Hi Ben,

All images on https://blend2d.com site were rendered by Blend2D through
B2dPipe. I have many demos, some use C++ and some node.js (through JS
bindings of Blend2D). However, demos and benchmarks will be published after
I release the main product - Blend2D. B2dPipe was released as a separate
project to allow others to also benefit from JIT, and I posted it here
because I also use analytic rasterizer similar to AGG.

I'm really looking forward to publish all the benchmarks I have as the
results are really impressive, but it will have to wait a bit until Blend2D
alpha is released. I compare with Cairo and Qt, and if I publish my results
now there would be no way to verify the numbers are accurate.

I plan to release Blend2D at the end of February / start of March, so let's
see if I can make it on schedule :)

Best,
Petr


On Fri, Feb 17, 2017 at 9:18 AM, Ben Harper <be...@im...> wrote:

> Sounds awesome. Do you have a demo using b2dpipe to produce actual pixels,
> and do you have performance numbers?
>
>
>
> *From:* Petr Kobalíček [mailto:kob...@gm...]
> *Sent:* Friday, January 27, 2017 3:13 PM
> *To:* Anti-Grain Geometry <vec...@li...>
> *Subject:* [AGG] B2dPipe - 2D Pipeline Compiler
>
>
>
> Hi list,
>
>
>
> I would like to announce a first release of b2dpipe library. It's a 2D
> pipeline compiler written in C++ that I developed as a part of Blend2D
> project. It currently implements only 32-bit pixel formats and there are
> some missing features that should be finished before general use, but I
> think it's in a good shape for experimenting and contributing.
>
>
>
> It's not a 2D engine and the library doesn't provide any 2D drawing
> context. It's a low-level library allowing you to define a 2D pipeline and
> to compile it at runtime by using a JIT compiler. This means that the
> library can be used in any rendering engine as a software-based rendering
> backend.
>
>
>
> What b2dpipe offers at the moment:
>
>
>
>   * ARGB32 (premultiplied) and XRGB32 pixel formats
>
>   * Acceleration of various compositing and blending operators
>
>   * Acceleration of rendering gradiends and textures
>
>   * Acceleration of semi-transparent blits
>
>   * 3 fill types (2 rectangle fills and one analytic)
>
>
>
> The library doesn't provide its own rasterizer, and I don't know if it
> should be part of it (I guess I will put it in a separate project instead),
> but it has an implementation of calculating alpha coverage based on the
> same analytic method as used by FreeType and AGG. Base structures are
> defined in b2dpipe::FillData::Analytic, most importantly Analytic::Cell and
> Analytic::Span, which are analogous to antigrain cell and array of cells. I
> would provide more details to anyone who is interested about this.
>
>
>
> Blend2D project:
>
>
>
>   https://blend2d.com
>
>
>
> B2dPipe repository:
>
>
>
>   https://github.com/blend2d/b2dpipe
>
>
>
> Thanks for your attention, and hopes for your contribution!
>
>
>
> Best,
>
> Petr
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful. Please notify the sender by replying to this message and then
> delete it from your system. Please report email abuse / misuse to IMQS
> Software <http://www.imqs.co.za>.
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Vector-agg-general mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>