Nabble - Anti-Grain Geometry

Re: aa_test is not antiliased (jagged), a bug?

2009-11-11T07:58:05Z

John Horigan wrote:
> Ah, I missed that one. I can't see any more that I've missed. Can you
give a look?

I haven't spotted any others yet, but I found another problem. The
bottom of the "ice lolly sticks" are not rendered correctly (see
attached image). It took me a little while to figure out the reason, but
in rgba8 we have:

AGG_INLINE self_type gradient(const self_type& c, double k) const
{
self_type ret;
calc_type ik = uround(k * base_scale);
ret.r = (value_type)int_lerp(r, c.r, ik);
ret.g = (value_type)int_lerp(g, c.g, ik);
ret.b = (value_type)int_lerp(b, c.b, ik);
ret.a = (value_type)int_lerp(a, c.a, ik);
return ret;
}

In 8-bit formats, you're lerping in the range 0-256 instead of 0-255.
You need to use "base_mask" instead of "base_scale". The same applies to
rgba16, of course.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

aa_test.png (29K) Download Attachment

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T12:30:57Z

Ah, I missed that one. I can't see any more that I've missed. Can you give a look?

I'll send out patch fixing this bug as soon as we get to the bottom of this aa_test failure. I can't even get it to build on my system (a mac).

-- john

On Nov 10, 2009, at 11:13 AM, Jim Barry wrote:

> John Horigan wrote:
>> In the blender class blend_pix() method you will find:
>> alpha = color_type::int_mult_cover(alpha, cover);
>>
>> This is part of the patch. The int_mult_cover(alpha, cover) has been moved from pixfmt_alpha_blender_* to the blender class blend_pix () method. This was done to improve efficiency and expose parallelism.
>
> OK, I see. So it's just that you forgot to add an int_mult_cover call to
> blender_rgb_gamma::blend_pix.
>
> Actually it did seem like a bit of an anomaly that the original version
> of pixfmt_alpha_blend_rgb[a] prelerped the alpha before calling
> blend_pix - other pixel formats don't do that.
>
> - Jim
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T11:13:07Z

John Horigan wrote:
> In the blender class blend_pix() method you will find:
> alpha = color_type::int_mult_cover(alpha, cover);
>
> This is part of the patch. The int_mult_cover(alpha, cover) has been moved from pixfmt_alpha_blender_* to the blender class blend_pix () method. This was done to improve efficiency and expose parallelism.

OK, I see. So it's just that you forgot to add an int_mult_cover call to
blender_rgb_gamma::blend_pix.

Actually it did seem like a bit of an anomaly that the original version
of pixfmt_alpha_blend_rgb[a] prelerped the alpha before calling
blend_pix - other pixel formats don't do that.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T08:22:06Z

In the blender class blend_pix() method you will find:
alpha = color_type::int_mult_cover(alpha, cover);

This is part of the patch. The int_mult_cover(alpha, cover) has been moved from pixfmt_alpha_blender_* to the blender class blend_pix () method. This was done to improve efficiency and expose parallelism.

My own code uses renderer_scanline_aa_solid<> and it produces anti-aliased output. I will pull the latest copy of agg from svn and see if it is different than what I am compiling my code against.

-- john

On Nov 10, 2009, at 3:33 AM, Jim Barry wrote:

> John Horigan wrote:
>> I believe that the patch is correct:
>
> Compiling and running aa_test proves otherwise ;-)
>
>> int_mult_cover(255, 254) == 254 (rgb8)
>> int_mult_cover(65534, 255) == 65534 && int_mult_cover(65535, 254) ==
>> 65278 (rgb16)
>>
>> int_mult_cover(c.a, cover) equals base_mask if and only if c.a equals
>> base_mask and cover equals cover_mask. So the two if statement
>> conditions are equivalent.
>
> Yes, but the problem is that you pass c.a to blend_pix instead of (c.a *
> cover / cover_full). So you *could* write:
>
> if (c.a)
> {
> if(c.a == base_mask && cover == cover_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> calc_type alpha = color_type::int_mult_cover(c.a, cover);
> m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
> }
> }
>
> Is this more or less efficient than the version I proposed before? I
> don't know. I suppose it depends how many of the source pixels are fully
> opaque.
>
> - Jim
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T03:33:49Z

John Horigan wrote:
> I believe that the patch is correct:

Compiling and running aa_test proves otherwise ;-)

> int_mult_cover(255, 254) == 254 (rgb8)
> int_mult_cover(65534, 255) == 65534 && int_mult_cover(65535, 254) ==
> 65278 (rgb16)
>
> int_mult_cover(c.a, cover) equals base_mask if and only if c.a equals
> base_mask and cover equals cover_mask. So the two if statement
> conditions are equivalent.

Yes, but the problem is that you pass c.a to blend_pix instead of (c.a *
cover / cover_full). So you *could* write:

if (c.a)
{
if(c.a == base_mask && cover == cover_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
calc_type alpha = color_type::int_mult_cover(c.a, cover);
m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
}
}

Is this more or less efficient than the version I proposed before? I
don't know. I suppose it depends how many of the source pixels are fully
opaque.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-09T22:38:35Z

I believe that the patch is correct:
int_mult_cover(255, 254) == 254 (rgb8)
int_mult_cover(65534, 255) == 65534 && int_mult_cover(65535, 254) ==
65278 (rgb16)

int_mult_cover(c.a, cover) equals base_mask if and only if c.a equals
base_mask and cover equals cover_mask. So the two if statement
conditions are equivalent.

-- john

On Nov 9, 2009, at 10:48 AM, Jim Barry wrote:

> jay3d wrote:
>> The aa-test demo in the latest svn is not antialiased!
>>
>> is it a known bug?
>
> Seems to be a problem with the recent "accurate blending" patch.
>
> In pixfmt_alpha_blend_rgb::copy_or_blend_pix, we used to have:
>
> if (c.a)
> {
> calc_type alpha = (calc_type(c.a) * (cover + 1)) >> 8;
> if(alpha == base_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
> }
> }
>
> The patch changed this to:
>
> if (c.a)
> {
> if(c.a == base_mask && cover == cover_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> m_blender.blend_pix(p, c.r, c.g, c.b, c.a, cover);
> }
> }
>
> Which is not correct. I think it should be something like this:
>
> if (c.a)
> {
> calc_type alpha = color_type::int_mult_cover(c.a, cover);
> if(alpha == base_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
> }
> }
>
> The same applies to blend_hline, blend_vline, blend_solid_hspan, and
> blend_solid_vspan.
>
> - Jim
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-09T10:48:46Z

jay3d wrote:
> The aa-test demo in the latest svn is not antialiased!
>
> is it a known bug?

Seems to be a problem with the recent "accurate blending" patch.

In pixfmt_alpha_blend_rgb::copy_or_blend_pix, we used to have:

if (c.a)
{
calc_type alpha = (calc_type(c.a) * (cover + 1)) >> 8;
if(alpha == base_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
}
}

The patch changed this to:

if (c.a)
{
if(c.a == base_mask && cover == cover_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
m_blender.blend_pix(p, c.r, c.g, c.b, c.a, cover);
}
}

Which is not correct. I think it should be something like this:

if (c.a)
{
calc_type alpha = color_type::int_mult_cover(c.a, cover);
if(alpha == base_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
}
}

The same applies to blend_hline, blend_vline, blend_solid_hspan, and
blend_solid_vspan.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

aa_test is not antiliased (jagged), a bug?

2009-11-07T11:39:15Z

The aa-test demo in the latest svn is not antialiased!

is it a known bug?

using VS2008 SP1

Thanks!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: agg render buffer and opengl

2009-11-03T20:14:29Z

Possible. U can use the memory provided to agg::rendering_buffer. Make
pixel format for the render buffer and texture are same.

unsigned long *buffer = new unsigned long[width*height*4];
memset(buffer, 0, width * height* 4);

agg::rendering_buffer r_buf_(buffer, width, height, width * 4);

//Do ur rendreing

//Copy buffer to texture

Jim Crafton wrote:

> I'm contemplating making an image editor of sorts, something that's
> based on another library of mine that roughly duplicates Apple's
> CoreImage on Windows. It uses OpenGL to draw images and GLSL for
> filters that can added to an image for processing the pixels. What I'd
> like to do is also use AGG to draw on the opengl image, which is just
> a texture map. Any advice on how best to approach this? Is it just a
> matter of creating a texture and dumping the contents of AGG's
> render_buffer onto the texture bits?
>
> Thanks!
>
> Jim
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>

#define ENABLE_LTDL 0

2009-11-03T11:11:29Z

I am building a minimal dot build, which will take a dot file in and output
an SVG fil only (ultimately I will make it a single DLL, but for now several
DLLs is fine).

I have built the solution with ENABLE_LTDL = 0 (as well as all the PNG JPEG
etc = 0) and am able to run dot from the command line, but I get the
following error:
Unable to find even the default "-Tdot" renderer. Has the config
file been generated by running "dot -c" with installer's priviledges?

>From digging around look like I need to use some predefined structs for the
SVG "plugin", but am not sure where to declare (and how to declare) and how
to initialize, any help appreciated.

Gordon.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg render buffer and opengl

2009-11-03T10:16:25Z

I'm contemplating making an image editor of sorts, something that's
based on another library of mine that roughly duplicates Apple's
CoreImage on Windows. It uses OpenGL to draw images and GLSL for
filters that can added to an image for processing the pixels. What I'd
like to do is also use AGG to draw on the opengl image, which is just
a texture map. Any advice on how best to approach this? Is it just a
matter of creating a texture and dumping the contents of AGG's
render_buffer onto the texture bits?

Thanks!

Jim

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Feedback: Ray-Alvy-Smith patch, SVN

2009-10-19T12:19:37Z

Hi All,

We waited for more then enough.
Have not seen objection.
Will apply the patch tomorrow in say 24 hours.

Regards,

Klaas

John Horigan wrote:
>
> OK. I will incorporate that. New patch attached.
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: SVN (SourceForge ID)

2009-10-07T09:20:09Z

thevinn has been added to the project

editor rights has been added

--- On Wed, 9/16/09, Vinnie <thevinn@...> wrote:

> From: Vinnie <thevinn@...>
> Subject: Re: [AGG] SVN (SourceForge ID)
> To: vector-agg-general@...
> Date: Wednesday, September 16, 2009, 8:25 AM
> > Date: Wed, 26 Aug 2009 23:35:01
> +0200
> > From: "klaas.holwerda" <ngi@...>
> > Please post your Source Forge ID to grant you
> developer
> > access
> >
> > Is there a problem doing that?
>
> Apparently yes because it was over 3 weeks since I sent the
> message, and I have not received any Vector-agg digests. I
> just now read your reply. Sorry for the inconvenience!
>
> My SourceForge ID is thevinn
>
> Thank you for your consideration.
>
> Sincerely,
>
> Vinnie
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer
> Conference in SF, CA
> is the only developer event you need to attend this year.
> Jumpstart your
> developing skills, take BlackBerry mobile applications to
> market and stay
> ahead of the curve. Join us from November 9-12, 2009.
> Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Feedback: Ray-Alvy-Smith patch, SVN

2009-10-03T09:51:11Z

On Oct 3, 2009, at 5:10 AM, Vinnie wrote:

> - I was able to get the patch from the last post, I saw it both in
> my private message and also the message posted to the list. Thanks
>
> - Patch worked great!
>
> - When I looked at my customizations, there was really only one
> thing that i added, an enumeration value to each of the orders:
>
> struct order_rgb { enum rgb_e { R=0, G=1, B=2, rgb_tag,
> hasAlpha=false }; }; //----order_rgb
> struct order_bgr { enum bgr_e { B=0, G=1, R=2, rgb_tag,
> hasAlpha=false }; }; //----order_bgr
> struct order_rgba { enum rgba_e { R=0, G=1, B=2, A=3, rgba_tag,
> hasAlpha=true }; }; //----order_rgba
> struct order_argb { enum argb_e { A=0, R=1, G=2, B=3, rgba_tag,
> hasAlpha=true }; }; //----order_argb
> struct order_abgr { enum abgr_e { A=0, B=1, G=2, R=3, rgba_tag,
> hasAlpha=true }; }; //----order_abgr
> struct order_bgra { enum bgra_e { B=0, G=1, R=2, A=3, rgba_tag,
> hasAlpha=true }; }; //----order_bgra
>
> My change was to include 'hasAlpha'. This is useful for template
> metaprogramming.
>

OK. I will incorporate that. New patch attached.

> - I have a common header file at the beginning of every .cpp file in
> the agg project, #include "pch.h" for building a precompiled header
> under MSVC
>
>

Sounds great. You should create a patch for that. Wrap the #include in
something like #ifdef AGG_USE_MSVC_PCH so that other Windows users are
not compelled to use pre-compiled headers.

> Also:
>
> - The directory structure of the project could be improved. The
> extra 'agg-2.4' is pretty annoying, as is the lack of a single
> include directory. It was one of the first things I changed in my
> private copy and I had to revert it back in order to apply the
> patch. I was thinking:
>
> {agg dir}include/agg/*
> {agg dir}include/agg/ctrl/*
> {agg dir}include/agg/platform/*
> ...
> {agg dir}include/agg/freetype/{freetype includes}
> {agg dir}include/agg/win_truetype/{win truetype includes}
> {agg dir}src/*
> ...
>
> This way a build environment can use -I{agg dir}include, with client
> code having lines like:
> #include <agg/agg_arrowhead.h>
> or (more work)
> #include <agg/arrowhead.h>
> for example.
>
> Of course this is a non trivial change that might require client
> code changes (mostly search and replace) but I wanted to mention it.
>

This is a great idea. We could do this trivially use symbolic links
but SVN doesn't even try to support symbolic links under Windows.
Maybe you could create your preferred include tree using symlinks (if
you are running Vista or Win7).

We should have a list of major improvements to AGG. Then at some date
we could have a hacking sprint and produce AGG3. Reorganizing the
header files should be on the list.

> - Still no SVN access unless I am doing something wrong (?)
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg24_alvyraysmithOct0309.patch.gz (7K) Download Attachment

Feedback: Ray-Alvy-Smith patch, SVN

2009-10-03T05:10:11Z

- I was able to get the patch from the last post, I saw it both in my private message and also the message posted to the list. Thanks

- Patch worked great!

- When I looked at my customizations, there was really only one thing that i added, an enumeration value to each of the orders:

struct order_rgb { enum rgb_e { R=0, G=1, B=2, rgb_tag, hasAlpha=false }; }; //----order_rgb
struct order_bgr { enum bgr_e { B=0, G=1, R=2, rgb_tag, hasAlpha=false }; }; //----order_bgr
struct order_rgba { enum rgba_e { R=0, G=1, B=2, A=3, rgba_tag, hasAlpha=true }; }; //----order_rgba
struct order_argb { enum argb_e { A=0, R=1, G=2, B=3, rgba_tag, hasAlpha=true }; }; //----order_argb
struct order_abgr { enum abgr_e { A=0, B=1, G=2, R=3, rgba_tag, hasAlpha=true }; }; //----order_abgr
struct order_bgra { enum bgra_e { B=0, G=1, R=2, A=3, rgba_tag, hasAlpha=true }; }; //----order_bgra

My change was to include 'hasAlpha'. This is useful for template metaprogramming.

- I have a common header file at the beginning of every .cpp file in the agg project, #include "pch.h" for building a precompiled header under MSVC

Also:

- The directory structure of the project could be improved. The extra 'agg-2.4' is pretty annoying, as is the lack of a single include directory. It was one of the first things I changed in my private copy and I had to revert it back in order to apply the patch. I was thinking:

{agg dir}include/agg/*
{agg dir}include/agg/ctrl/*
{agg dir}include/agg/platform/*
...
{agg dir}include/agg/freetype/{freetype includes}
{agg dir}include/agg/win_truetype/{win truetype includes}
{agg dir}src/*
...

This way a build environment can use -I{agg dir}include, with client code having lines like:
#include <agg/agg_arrowhead.h>
or (more work)
#include <agg/arrowhead.h>
for example.

Of course this is a non trivial change that might require client code changes (mostly search and replace) but I wanted to mention it.

- Still no SVN access unless I am doing something wrong (?)

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T23:19:39Z

A gzipped patch file is attached. If you don't see an attachment then
contact me and I will arrange some other method of getting the patch
to you.

Updated patch for accurate blenders:
1) Old blenders are completely removed
2) both gray16(const rgba16&) constructors are fixed

-- john

On Oct 2, 2009, at 3:19 PM, John Horigan wrote:

> Yes, that is a bug in my new gray16() constructor. I will send out a
> new patch with that fixed and the old code removed.
>
> -- john
>
> On Oct 2, 2009, at 10:13 AM, klaas.holwerda wrote:
>
>> Stephan Assmus wrote:
>>> Hi John,
>>>
>>> On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...>
>>> wrote:
>>>
>>>> Sorry for the delay in this patch. I thought that the new blenders
>>>> were
>>>> failing in the rgba16 formats. But it turned out that the error
>>>> was in my
>>>> test framework.
>>>>
>>>
>>> I've read through the patch and it looks very good! Thanks a lot
>>> for this
>>> work. Only one place I am not sure about:
>>>
>>> +
>>> //--------------------------------------------------------------------
>>> + gray16(const rgba16& c, unsigned a_) :
>>> + v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
>>> + a((value_type)a_) {}
>>>
>>> I think the shift is wrong, since 77 + 150 + 29 = 256.
>>>
>>> Has anybody else here already commited this patch?
>> I think not, can you do it?
>> Although i thinks legacy and incorrect blending code in AGG should be
>> removed. I agree with John on that and/or the husband.
>> It is bad to keep all old code around.
>> What do you think?
>>> I do not follow the AGG
>>> commits, is there a commit notification list I can sign up to?
>>>
>> Not yet, and only the admin can do it.
>> I suggest our admin gives other devlopers admin rights too.
>> Or at least make things happen more quickly. e.g. Vinnie is not on
>> the
>> members list jet.
>> And this commit list should be in place.
>>
>> Leonardo were are you??
>>
>> regards,
>>
>> Klaas
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF,
>> CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Vector-agg-general mailing list
>> Vector-agg-general@...
>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg24_alvyraysmithOct0209.patch.gz (7K) Download Attachment

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T15:27:27Z

The patch does not fix the 15/16 bit formats. The patch is based on
the theory in Alvy Ray Smith's paper:
http://www.ozonehouse.com/john/4_Comp.pdf

It shouldn't be too hard to adapt this work to 5 or 6-bit color
components.

-- john

On Oct 2, 2009, at 4:21 AM, Udo Giacomozzi wrote:

> Hi John,
>
> does your patch also improve blending accuracy when using 15 or 16 bit
> ("hicolor") formats? We experience noticeable artifacts in those modes
> in Gnash...
>
> Udo
>
>
> Monday, August 17, 2009, 8:36:17 AM, you wrote:
>
>
> For my digital art program, Context Free, I have been using a
> modified form of the RGBA, RGB, and gray pixel formats. I do this
> because stock AGG is slightly inaccurate in computing and blending
> colors. My changes to AGG are based on Alvy Ray Smith's paper on
> fast, accurate color blending (ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf
> ).
>
> The changes that I have made are:
> * Utility methods have been added to classes rgb8, rgb16, gray8, and
> gray16 for doing fast, accurate fixed point multiplies and linear
> interpolations.
> * The add, gradient, and premultiply methods of classes rgb8, rgb16,
> gray8, and gray16 use the new utility methods.
> * multiplier_rgba<>::premultiply() method in agg_pixfmt_rgba.h uses
> the new utility methods.
> * All of the blender classes in agg_pixfmt_gray/rbg/rgba.h use the
> new utility methods.
> * The interface between these blender classes and the pixfmt classes
> has been changed slightly. Currently the pixfmt class multiplies the
> color alpha with pixel coverage factor before calling the blender
> (even though both alpha and cover are passed to the blender). With
> this patch, this calculation is moved to the blender class blend_pix
> () methods.
> * I added a utility method to class rect_base in agg_basics.h:
> overlaps()
>
> I have been using most of these changes for over a year in Context
> Free and I am confident in their correctness. I don't use the non-
> premultiplied color blenders but I was able to tweak Context Free to
> use them and they appeared to function correctly.
>
> The composition operation classes comp_op_rgba_x in
> agg_pixfmt_rgba.h and the pixfmt_custom_blend_rgba class that uses
> them have not been updated to use the new utility methods. The
> composition operators could stand to be implemented more accurately,
> but I don't have any test bench for validating changes.
>
> The patch can be found at http://www.ozonehouse.com/john/agg24_alvyraysmith.patch
>
> -- john
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T15:19:26Z

Yes, that is a bug in my new gray16() constructor. I will send out a
new patch with that fixed and the old code removed.

-- john

On Oct 2, 2009, at 10:13 AM, klaas.holwerda wrote:

> Stephan Assmus wrote:
>> Hi John,
>>
>> On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...>
>> wrote:
>>
>>> Sorry for the delay in this patch. I thought that the new blenders
>>> were
>>> failing in the rgba16 formats. But it turned out that the error
>>> was in my
>>> test framework.
>>>
>>
>> I've read through the patch and it looks very good! Thanks a lot
>> for this
>> work. Only one place I am not sure about:
>>
>> +
>> //--------------------------------------------------------------------
>> + gray16(const rgba16& c, unsigned a_) :
>> + v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
>> + a((value_type)a_) {}
>>
>> I think the shift is wrong, since 77 + 150 + 29 = 256.
>>
>> Has anybody else here already commited this patch?
> I think not, can you do it?
> Although i thinks legacy and incorrect blending code in AGG should be
> removed. I agree with John on that and/or the husband.
> It is bad to keep all old code around.
> What do you think?
>> I do not follow the AGG
>> commits, is there a commit notification list I can sign up to?
>>
> Not yet, and only the admin can do it.
> I suggest our admin gives other devlopers admin rights too.
> Or at least make things happen more quickly. e.g. Vinnie is not on the
> members list jet.
> And this commit list should be in place.
>
> Leonardo were are you??
>
> regards,
>
> Klaas
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T10:13:00Z

Stephan Assmus wrote:

> Hi John,
>
> On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...> wrote:
>
>> Sorry for the delay in this patch. I thought that the new blenders were
>> failing in the rgba16 formats. But it turned out that the error was in my
>> test framework.
>>
>
> I've read through the patch and it looks very good! Thanks a lot for this
> work. Only one place I am not sure about:
>
> +
> //--------------------------------------------------------------------
> + gray16(const rgba16& c, unsigned a_) :
> + v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
> + a((value_type)a_) {}
>
> I think the shift is wrong, since 77 + 150 + 29 = 256.
>
> Has anybody else here already commited this patch?

I think not, can you do it?
Although i thinks legacy and incorrect blending code in AGG should be
removed. I agree with John on that and/or the husband.
It is bad to keep all old code around.
What do you think?
> I do not follow the AGG
> commits, is there a commit notification list I can sign up to?
>
Not yet, and only the admin can do it.
I suggest our admin gives other devlopers admin rights too.
Or at least make things happen more quickly. e.g. Vinnie is not on the
members list jet.
And this commit list should be in place.

Leonardo were are you??

regards,

Klaas

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray

2009-10-02T10:12:09Z

Vinnie wrote:
> http://agg.svn.sourceforge.net/ shows the last change at 6 weeks ago and there are no attachments on any items in the mailing list.
>
> Where is this patch?
>
It was attached. So somehow it is removed in your case. Ask John to sent
it to you private i think.

Klaas

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray

2009-10-02T04:22:51Z

> From: John Horigan <john@...>

These changes sound very exciting and I would love to try them and provide feedback; However, I am not sure precisely how to obtain the patch. http://agg.svn.sourceforge.net/ shows the last change at 6 weeks ago and there are no attachments on any items in the mailing list.

Where is this patch?

Thanks!

Vinnie

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T04:21:30Z

Hi John,

does your patch also improve blending accuracy when using 15 or 16 bit
("hicolor") formats? We experience noticeable artifacts in those modes
in Gnash...

Udo

Monday, August 17, 2009, 8:36:17 AM, you wrote:

For my digital art program, Context Free, I have been using a modified form of the RGBA, RGB, and gray pixel formats. I do this because stock AGG is slightly inaccurate in computing and blending colors. My changes to AGG are based on Alvy Ray Smith's paper on fast, accurate color blending (ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf).

The changes that I have made are:
* Utility methods have been added to classes rgb8, rgb16, gray8, and gray16 for doing fast, accurate fixed point multiplies and linear interpolations.
* The add, gradient, and premultiply methods of classes rgb8, rgb16, gray8, and gray16 use the new utility methods.
* multiplier_rgba<>::premultiply() method in agg_pixfmt_rgba.h uses the new utility methods.
* All of the blender classes in agg_pixfmt_gray/rbg/rgba.h use the new utility methods.
* The interface between these blender classes and the pixfmt classes has been changed slightly. Currently the pixfmt class multiplies the color alpha with pixel coverage factor before calling the blender (even though both alpha and cover are passed to the blender). With this patch, this calculation is moved to the blender class blend_pix() methods.
* I added a utility method to class rect_base in agg_basics.h: overlaps()

I have been using most of these changes for over a year in Context Free and I am confident in their correctness. I don't use the non-premultiplied color blenders but I was able to tweak Context Free to use them and they appeared to function correctly.

The composition operation classes comp_op_rgba_x in agg_pixfmt_rgba.h and the pixfmt_custom_blend_rgba class that uses them have not been updated to use the new utility methods. The composition operators could stand to be implemented more accurately, but I don't have any test bench for validating changes.

The patch can be found at http://www.ozonehouse.com/john/agg24_alvyraysmith.patch

-- john

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T03:26:16Z

Hi John,

On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...> wrote:
> Sorry for the delay in this patch. I thought that the new blenders were
> failing in the rgba16 formats. But it turned out that the error was in my
> test framework.

I've read through the patch and it looks very good! Thanks a lot for this
work. Only one place I am not sure about:

+
//--------------------------------------------------------------------
+ gray16(const rgba16& c, unsigned a_) :
+ v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
+ a((value_type)a_) {}

I think the shift is wrong, since 77 + 150 + 29 = 256.

Has anybody else here already commited this patch? I do not follow the AGG
commits, is there a commit notification list I can sign up to?

Best regards,
-Stephan

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-09-27T20:34:44Z

My husband is (a software architect) is critical of these parts to my patch. He says that it is a mistake to leave the incorrect blending code in AGG and that the old blenders and the legacy typedefs should be removed. Or if they are to remain that they should be renamed to make it clear that they are deprecated.

Vinnie, you are the advocate for keeping the old blender code. Can you describe the changes that you have made to the blenders in your private copy of AGG.

-- john

On Sep 27, 2009, at 3:12 PM, John Horigan wrote:

* New blender classes have been added to agg_pixfmt_gray/rbg/rgba.h using the new utility methods. They have the same names as the old blenders with '_ars' (for Alvy Ray Smith) appended. It just occurred to me that this naming convention may cause British AGG users to giggle. I am open to changes in the naming convention.

* All of the pixel format typedefs in agg_pixfmt_gray/rbg/rgba.h use the new '_ars' blenders. Typedefs using the old blenders remain, but have '_legacy' appended to them.

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-09-27T15:12:42Z

Sorry for the delay in this patch. I thought that the new blenders were failing in the rgba16 formats. But it turned out that the error was in my test framework.

The changes that I have made are:
* Utility methods have been added to classes rgb8, rgb16, gray8, and gray16 for doing fast, accurate fixed point multiplies and linear interpolations.

* The add, gradient, and premultiply methods of classes rgb8, rgb16, gray8, and gray16 use the new utility methods.

* A few new constructors have been added to agg_color_gray.h/agg_color_rgba.h: rgba8(const gray8& c), rgba16(const gray16& c), gray16(const rgba16& c), gray16(const rgba16& c, unsigned a_)

* A new file: agg_color_rgba.cpp was added to store the new rgba8/16 constructors. This was necessary to avoid a dependency loop. I used the same style of header comments that I found in other .cpp files.

* multiplier_rgba<>::premultiply() method in agg_pixfmt_rgba.h uses the new utility methods.

* New blender classes have been added to agg_pixfmt_gray/rbg/rgba.h using the new utility methods. They have the same names as the old blenders with '_ars' (for Alvy Ray Smith) appended. It just occurred to me that this naming convention may cause British AGG users to giggle. I am open to changes in the naming convention.

* All of the pixel format typedefs in agg_pixfmt_gray/rbg/rgba.h use the new '_ars' blenders. Typedefs using the old blenders remain, but have '_legacy' appended to them.

* The interface between the blender classes and the pixfmt classes has been changed slightly. Currently the pixfmt class multiplies the color alpha with pixel coverage factor before calling the blender (even though both alpha and cover are passed to the blender). With this patch, this calculation is moved to the blender class blend_pix() methods.

* I added a utility method to class rect_base in agg_basics.h: overlaps()

-- john horigan

agg24_alvyraysmithSept2709.patch.gz (9K) Download Attachment

Re: Bug in conv_stroke with line cap

2009-09-25T10:11:36Z

Mathieu Monney wrote:
> I'm facing a very strange problem with the conv_stroke converter while
> setting the line cap to round_cap.
>
> Here is the situation:
[...]

I don't think you gave enough information to reproduce the problem. If
you post the exact steps required then somebody may be able to help.

- Jim

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Bug in conv_stroke with line cap

2009-09-23T04:32:30Z

Hi all,

I'm facing a very strange problem with the conv_stroke converter while setting the line cap to round_cap.

Here is the situation:

I'm trying to draw a polyline of a certain width which is completly offscreen so when the clipping occures, nothin must be drawn because the polyline is entirely located off the screen.

The polyline is defined as follow:

ps.move_to(-530,-1212);

ps.line_to(-526,-1217);

ps.line_to(-519, -1224);

ps.line_to(-510, -1230);

ps.line_to(-500, -1234);

ps.line_to(-353, -1292);

Then the following pipepline is used to render this polyline:

agg::conv_stroke<agg::path_storage> pg(ps);

agg::conv_transform<agg::conv_stroke<agg::path_storage>, agg::trans_perspective> trans(pg,matrix);

pg.width(5.0);

pg.line_cap(agg::round_cap);

Then the overall is rasterized using renderer_scanline_aa_solid. The perspective matrix has a translation and rotation on the x and z axis but I don't think it is the problem.

I attached the image I get with the above command. The white strip is the line which is drawn and the black color is the background. In theory everything should be black but because of some problem it's not.

Then if I remove the pg.line_cap() line (so there is no rounded cap anymore), then everything works fine (i.e. nothing is displayed).

Does anybody know why or have some pointers about that?

Thanks a lot!

Best regards,

Mathieu Monney

Re: AGG with Java

2009-09-20T13:19:35Z

Yes, its no problem using JNI.

You can directly access java-arrays using JNI, and therefor if you've
allocated a java byte[], you can directly access it like some
malloc'ed memory.

I would however recommend using Java2D on top of BufferedImages, which
covers quite a lot of what agg does do, without the need to fight with
native code (which can cause massive deployment headacke).

- Clemens

2009/8/10 Juan Pedro Pérez Alcántara <jp.alcantara@...>:

> Hello everybody,
>
> I'm new to the list and my first question is (I hope) quiet simple: does
> anybody has any experience working with AGG and Java? Moreover, it is
> even possible to use AGG with this language? Obviously I prefer C, but
> due to project constraints imposed by the costumer, Java is going to be
> used.
>
> Thanks in advance and keep the good job,
>
> Juan Pedro Pérez
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

[Patch] Patch to add 3D rotation to perspective matrix

2009-09-18T10:13:23Z

Hi all,

So after helping trying to find out what the perspective matrix terms
are, here is, as gift, a patch to add 3D rotation capabilities to the
trans_perspective class of the AGG 2.5 release. In order to make a
rotation of x radian along either the x,y or z axis you can now call
the .rotate(x,trans_perspective::xaxis) to apply the transformation to
the matrix. The matrix itself is returned and returned as reference as
other modifier functions.

I hope that will help some people.

Thanks again for your active help on this mailing list. It becomes
rarer to find such support on mailing list. Thanks guys!

Best,

Mathieu Monney

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

rotation_perspective_agg.patch (1K) Download Attachment

Re: Perspective projected stroked path with variable width

2009-09-17T07:44:38Z

Mathieu Monney schrieb:

> Hi Petr,
>
> Thanks for your complete response. It really helps.
>
> However I still have two questions:
>
> - What do you mean by converting curves to lines ? In the input I have
> already points defining the segments of my lines. So it is already ok,
> isn't it ?
> - Is there any performance speed up which can be made in order to draw
> the same lines under a different perspective. I mean I want to draw my
> lines using one perspective matrix and then later draw the same lines
> again with another perspective matrix. What kind of things should I be
> aware of in order AGG not to recompute all the vectors data again?

The stroker works on the fly. It does not cache the computed coordinates
if I am not mistaken. If you needed to use a curve converter (doesn't
seem to be the case), it would also generate points on the fly. So you
cannot do anything, except record the output in another
agg::path_storage and use that as a cache. But once you use more
sophisticated fills, you will quickly notice that the vector
calculations are not usually any performance problem. That is my own
experience, though, it depends on the complexity of your vector data.

Best regards,
-Stephan

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Perspective projected stroked path with variable width

2009-09-17T05:17:41Z

Hi Petr,

Thanks for your complete response. It really helps.

However I still have two questions:

- What do you mean by converting curves to lines ? In the input I have
already points defining the segments of my lines. So it is already ok,
isn't it ?
- Is there any performance speed up which can be made in order to draw
the same lines under a different perspective. I mean I want to draw my
lines using one perspective matrix and then later draw the same lines
again with another perspective matrix. What kind of things should I be
aware of in order AGG not to recompute all the vectors data again?

Thanks a lot.

Best,

Mathieu

Le 17 sept. 2009 à 06:36, Petr Kobalíček a écrit :

> Hi Mathieu,
>
> I think that you must first understand how rasterization in antigrain
> works. The pipeline in antigrain is something like middleware between
> your final image and your vector data. Antigrain rasterizer can only
> rasterize polygons, so here the pipeline is to create set (or one) of
> closed polygons from your vector data.
>
> For example, you have some vector data:
> 1. you need to convert curves to lines (curve pipeline)
> 2. you need to stroke (stroke pipeline)
> 3. you need to apply transform (here your perspective matrix is used -
> transform pipeline)
> 4. you are ready to rasterize
>
> if you swap step 2 and 3 it's logical that stroke width will be
> constant in are places. Antigrain gives you ability to swap various
> steps in the pipeline.
>
> About perspective matrix:
> - it's like affine matrix but contains another fields. It's sometimes
> called as transform matrix. For detailed description look at
> QTransform class in qt: http://doc.trolltech.com/4.5/qtransform.html .
>
> Regards
> - Petr
>
> 2009/9/16 Mathieu Monney <mathieu.monney@...>:
>> Hi,
>>
>> Thanks for your answer.
>>
>> Actually I didn't really how to set the perspective transformation.
>> What does the matrix terms mean? In order to set up my perspective
>> matrix to test, I used the image_perspective demo and set up the quad
>> of the image in order to have the perspective I want. Then I used the
>> produced matrix to put it in my program. Dirty but I thought it
>> should
>> work :-).
>>
>> So can you explain a little more what the perspective matrix means? I
>> should have the sufficient knowledge to understand the affine matrix
>> but this perspective matrix sounds awkward for me. Is there any
>> documentation somewhere about that?
>>
>> Actually I just found out that I mixed up my pipeline and I applied
>> the perspective transformation directly to the path and then stroke
>> it. So I reverse that and now it works :-). However I still don't
>> know
>> how to set up this perspective matrix :-).
>> So I have the following pipeline: transform < stroke< stroke<path>
>> > ,
>> perspective >. Is that optimal or is there any more optimal way to
>> convert the thick lines to polygons?
>>
>> Thanks a lot.
>>
>> Best regards,
>>
>> Mathieu
>>
>>
>>
>> Le 16 sept. 2009 à 17:05, Stephan Aßmus a écrit :
>>
>>> Hi,
>>>
>>> Mathieu Monney schrieb:
>>>> I'm pretty new to AGG and I'm trying to use to render lines with
>>>> variable width in order to produce a "perspective effect" where the
>>>> line width gets lower as it goes far away. What I have in the input
>>>> is
>>>> only vertices defining the line. So my goal would be to transform
>>>> these vertices into a polygon representing the contour of the
>>>> stroked
>>>> line with a variable width. I tried to use a pipeline like path ->
>>>> conv_stroke -> conv_stroke (in order to get the border of stroke)
>>>> However it doesn't give me a polygon on the output so applying a
>>>> perspective transform to it will not change the stroke width
>>>> accordingly. What solution could I use?
>>>
>>> Hm, but when you apply a perspective transform to the last step of
>>> your
>>> pipeline, your entire shape should be transformed. I don't know what
>>> you
>>> mean by "it doesn't give me a polygon". The stroke output is also a
>>> polygon in the sense of AGG, but the perspective transformation does
>>> not
>>> care about that. It simply transforms any coordinates. How do you
>>> configure the perspective transformation? In any case, I can confirm
>>> you
>>> this is possible with AGG, we just need to figure out where you are
>>> doing something wrong or where you have a misunderstanding. :-)
>>>
>>> Best regards,
>>> -Stephan
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry® Developer Conference in
>>> SF, CA
>>> is the only developer event you need to attend this year. Jumpstart
>>> your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay
>>> ahead of the curve. Join us from November 9-12, 2009. Register
>>> now!
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Vector-agg-general mailing list
>>> Vector-agg-general@...
>>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF,
>> CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market
>> and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Vector-agg-general mailing list
>> Vector-agg-general@...
>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Perspective projected stroked path with variable width

2009-09-17T04:38:26Z

Hi,

Mathieu Monney schrieb:
> Actually I just found out that I mixed up my pipeline and I applied
> the perspective transformation directly to the path and then stroke
> it. So I reverse that and now it works :-). However I still don't know
> how to set up this perspective matrix :-).
> So I have the following pipeline: transform < stroke< stroke<path> > ,
> perspective >. Is that optimal or is there any more optimal way to
> convert the thick lines to polygons?

Good to know you figured it out. Sorry, but I cannot help explain the
perspective matrix, but this is probably a subject that you can google.
When I used the persepective transformation, I've always used the quad
to quad utility methods to produce the matrix I wanted.

Best regards,
-Stephan

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Perspective projected stroked path with variable width

2009-09-16T21:36:19Z

Hi Mathieu,

I think that you must first understand how rasterization in antigrain
works. The pipeline in antigrain is something like middleware between
your final image and your vector data. Antigrain rasterizer can only
rasterize polygons, so here the pipeline is to create set (or one) of
closed polygons from your vector data.

For example, you have some vector data:
1. you need to convert curves to lines (curve pipeline)
2. you need to stroke (stroke pipeline)
3. you need to apply transform (here your perspective matrix is used -
transform pipeline)
4. you are ready to rasterize

if you swap step 2 and 3 it's logical that stroke width will be
constant in are places. Antigrain gives you ability to swap various
steps in the pipeline.

About perspective matrix:
- it's like affine matrix but contains another fields. It's sometimes
called as transform matrix. For detailed description look at
QTransform class in qt: http://doc.trolltech.com/4.5/qtransform.html .

Regards
- Petr

2009/9/16 Mathieu Monney <mathieu.monney@...>:

> Hi,
>
> Thanks for your answer.
>
> Actually I didn't really how to set the perspective transformation.
> What does the matrix terms mean? In order to set up my perspective
> matrix to test, I used the image_perspective demo and set up the quad
> of the image in order to have the perspective I want. Then I used the
> produced matrix to put it in my program. Dirty but I thought it should
> work :-).
>
> So can you explain a little more what the perspective matrix means? I
> should have the sufficient knowledge to understand the affine matrix
> but this perspective matrix sounds awkward for me. Is there any
> documentation somewhere about that?
>
> Actually I just found out that I mixed up my pipeline and I applied
> the perspective transformation directly to the path and then stroke
> it. So I reverse that and now it works :-). However I still don't know
> how to set up this perspective matrix :-).
> So I have the following pipeline: transform < stroke< stroke<path> > ,
> perspective >. Is that optimal or is there any more optimal way to
> convert the thick lines to polygons?
>
> Thanks a lot.
>
> Best regards,
>
> Mathieu
>
>
>
> Le 16 sept. 2009 à 17:05, Stephan Aßmus a écrit :
>
>> Hi,
>>
>> Mathieu Monney schrieb:
>>> I'm pretty new to AGG and I'm trying to use to render lines with
>>> variable width in order to produce a "perspective effect" where the
>>> line width gets lower as it goes far away. What I have in the input
>>> is
>>> only vertices defining the line. So my goal would be to transform
>>> these vertices into a polygon representing the contour of the stroked
>>> line with a variable width. I tried to use a pipeline like path ->
>>> conv_stroke -> conv_stroke (in order to get the border of stroke)
>>> However it doesn't give me a polygon on the output so applying a
>>> perspective transform to it will not change the stroke width
>>> accordingly. What solution could I use?
>>
>> Hm, but when you apply a perspective transform to the last step of
>> your
>> pipeline, your entire shape should be transformed. I don't know what
>> you
>> mean by "it doesn't give me a polygon". The stroke output is also a
>> polygon in the sense of AGG, but the perspective transformation does
>> not
>> care about that. It simply transforms any coordinates. How do you
>> configure the perspective transformation? In any case, I can confirm
>> you
>> this is possible with AGG, we just need to figure out where you are
>> doing something wrong or where you have a misunderstanding. :-)
>>
>> Best regards,
>> -Stephan
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Vector-agg-general mailing list
>> Vector-agg-general@...
>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

Re: Perspective projected stroked path with variable width

2009-09-16T13:11:33Z

Hi,

Thanks for your answer.

Actually I didn't really how to set the perspective transformation.
What does the matrix terms mean? In order to set up my perspective
matrix to test, I used the image_perspective demo and set up the quad
of the image in order to have the perspective I want. Then I used the
produced matrix to put it in my program. Dirty but I thought it should
work :-).

So can you explain a little more what the perspective matrix means? I
should have the sufficient knowledge to understand the affine matrix
but this perspective matrix sounds awkward for me. Is there any
documentation somewhere about that?

Actually I just found out that I mixed up my pipeline and I applied
the perspective transformation directly to the path and then stroke
it. So I reverse that and now it works :-). However I still don't know
how to set up this perspective matrix :-).
So I have the following pipeline: transform < stroke< stroke<path> > ,
perspective >. Is that optimal or is there any more optimal way to
convert the thick lines to polygons?

Thanks a lot.

Best regards,

Mathieu

Le 16 sept. 2009 à 17:05, Stephan Aßmus a écrit :

> Hi,
>
> Mathieu Monney schrieb:
>> I'm pretty new to AGG and I'm trying to use to render lines with
>> variable width in order to produce a "perspective effect" where the
>> line width gets lower as it goes far away. What I have in the input
>> is
>> only vertices defining the line. So my goal would be to transform
>> these vertices into a polygon representing the contour of the stroked
>> line with a variable width. I tried to use a pipeline like path ->
>> conv_stroke -> conv_stroke (in order to get the border of stroke)
>> However it doesn't give me a polygon on the output so applying a
>> perspective transform to it will not change the stroke width
>> accordingly. What solution could I use?
>
> Hm, but when you apply a perspective transform to the last step of
> your
> pipeline, your entire shape should be transformed. I don't know what
> you
> mean by "it doesn't give me a polygon". The stroke output is also a
> polygon in the sense of AGG, but the perspective transformation does
> not
> care about that. It simply transforms any coordinates. How do you
> configure the perspective transformation? In any case, I can confirm
> you
> this is possible with AGG, we just need to figure out where you are
> doing something wrong or where you have a misunderstanding. :-)
>
> Best regards,
> -Stephan
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: SVN (SourceForge ID)

2009-09-16T08:25:08Z

> Date: Wed, 26 Aug 2009 23:35:01 +0200
> From: "klaas.holwerda" <ngi@...>
> Please post your Source Forge ID to grant you developer
> access
>
> Is there a problem doing that?

Apparently yes because it was over 3 weeks since I sent the message, and I have not received any Vector-agg digests. I just now read your reply. Sorry for the inconvenience!

My SourceForge ID is thevinn

Thank you for your consideration.

Sincerely,

Vinnie

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general