From ml3p at onghu.com  Thu Oct  1 08:41:27 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Thu, 01 Oct 2009 23:41:27 +0800
Subject: [cairo] Building pixman for Windows CE
Message-ID: <4AC4CDA7.7070909@onghu.com>

I'm just starting to build Pixman 0.16.2 for Windows CE.  Just a bit 
confused when starting out... do I build it directly with Cairo, or do I 
create it as a separate library first and then compile the static 
library with the Cairo build?

I ask because my build (using VS2005) is failing for now.  It seems to 
be looking for "config.h" which doesn't exist and I'm unable to find any 
conclusive documentation on this.

I'm sorry if this is a bit trivial, but I've always used cairo on 
Windows and never needed to build it from source (till now!).

Thanks,
Mohit.


From gerdusvanzyl at gmail.com  Thu Oct  1 09:07:44 2009
From: gerdusvanzyl at gmail.com (Gerdus van Zyl)
Date: Thu, 1 Oct 2009 18:07:44 +0200
Subject: [cairo] Building pixman for Windows CE
In-Reply-To: <4AC4CDA7.7070909@onghu.com>
References: <4AC4CDA7.7070909@onghu.com>
Message-ID: <91882ea90910010907q3eae5474p21b4e148af3053e4@mail.gmail.com>

First build pixman seperately. config.h is a file made by the
./configure command and is just a bunch of c defines. The build files
will also use a perl script to create pixman-combine32/64 so you might
be missing those as well. I would recommend installing msys/mingw
(might take a little work) and running the default build scripts, then
you can just copy the generated files and reverse engineer the build
process a little better.

~Gerdus

On Thu, Oct 1, 2009 at 5:41 PM, Mohit Sindhwani <ml3p at onghu.com> wrote:
> I'm just starting to build Pixman 0.16.2 for Windows CE. ?Just a bit
> confused when starting out... do I build it directly with Cairo, or do I
> create it as a separate library first and then compile the static
> library with the Cairo build?
>
> I ask because my build (using VS2005) is failing for now. ?It seems to
> be looking for "config.h" which doesn't exist and I'm unable to find any
> conclusive documentation on this.
>
> I'm sorry if this is a bit trivial, but I've always used cairo on
> Windows and never needed to build it from source (till now!).
>
> Thanks,
> Mohit.
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>

From ml3p at onghu.com  Thu Oct  1 09:13:26 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Fri, 02 Oct 2009 00:13:26 +0800
Subject: [cairo] Building pixman for Windows CE
In-Reply-To: <91882ea90910010907q3eae5474p21b4e148af3053e4@mail.gmail.com>
References: <4AC4CDA7.7070909@onghu.com>
	<91882ea90910010907q3eae5474p21b4e148af3053e4@mail.gmail.com>
Message-ID: <4AC4D526.8030907@onghu.com>

Gerdus van Zyl wrote:
> First build pixman seperately. config.h is a file made by the
> ./configure command and is just a bunch of c defines. The build files
> will also use a perl script to create pixman-combine32/64 so you might
> be missing those as well. I would recommend installing msys/mingw
> (might take a little work) and running the default build scripts, then
> you can just copy the generated files and reverse engineer the build
> process a little better.
>   
Hi Gerdus

Thanks!  I guess I'll need to do that...

Cheers,
Mohit.
10/2/2009 | 12:13 AM.


From britten at caris.com  Thu Oct  1 09:32:32 2009
From: britten at caris.com (Ian Britten)
Date: Thu, 01 Oct 2009 13:32:32 -0300
Subject: [cairo] Underlining text, etc?
Message-ID: <4AC4D9A0.5050301@caris.com>

Hi all,
Can someone confirm that Cairo has no support for extra font
markups (Such as underline, strike-through, etc), that there is
no plan to add support, and thus it's stuff I'll have to handle
in my rendering code?

Assuming I have to do it myself, does anyone have any experience,
suggestions, or pitfalls?  I can imagine numerous upcoming
questions about this, regarding path/stroke handling, alphas,
vector output considerations (PDF, SVG, etc), and figured I
might as well try to save myself from some problems, if there's
a preferred technique to doing this.

Although I can probably kludge some drawing instructions
together, I'd like to do things 'right' (If there is such a thing)

Many thanks for any info!
Ian

From flying.toaster at voila.fr  Thu Oct  1 09:24:59 2009
From: flying.toaster at voila.fr (flying.toaster)
Date: Thu,  1 Oct 2009 18:24:59 +0200 (CEST)
Subject: [cairo] Librsvg + cairo animation flicker
Message-ID: <24812956.11175001254414299451.JavaMail.www@wwinf4601>

Hi all 

 I am trying to put up an application animating SVG objects (as sprites) with Librsvg and cairo on top of SDL on a Win32 rig (yeah, that IS weird). 
I am using a SDL timer to update periodically the image.
I have tried all sorts of backbuffering (cairo surfaces, SDL surfaces) but I still get a terrible flicker on the parts that are drawn through a call to rsvg_handle_render_cairo. Parts drawn through direct calls to cairo do not exhibit this flicker.
Wondering if this function is thread unsafe or something... Has anybody a clue on this kind of issue ?

Thanks in advance

Enrique

____________________________________________________

Retour sur un week-end charg? en exploits?sur http://sports.voila.fr/ 




From domlachowicz at gmail.com  Thu Oct  1 09:58:42 2009
From: domlachowicz at gmail.com (Dominic Lachowicz)
Date: Thu, 1 Oct 2009 12:58:42 -0400
Subject: [cairo] Underlining text, etc?
In-Reply-To: <4AC4D9A0.5050301@caris.com>
References: <4AC4D9A0.5050301@caris.com>
Message-ID: <2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>

Hi Ian,

Cairo doesn't support font markup. Pango does support the few features
you mentioned, though.

http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html

Cheers,
Dom

On Thu, Oct 1, 2009 at 12:32 PM, Ian Britten <britten at caris.com> wrote:
> Hi all,
> Can someone confirm that Cairo has no support for extra font
> markups (Such as underline, strike-through, etc), that there is
> no plan to add support, and thus it's stuff I'll have to handle
> in my rendering code?
>
> Assuming I have to do it myself, does anyone have any experience,
> suggestions, or pitfalls? ?I can imagine numerous upcoming
> questions about this, regarding path/stroke handling, alphas,
> vector output considerations (PDF, SVG, etc), and figured I
> might as well try to save myself from some problems, if there's
> a preferred technique to doing this.
>
> Although I can probably kludge some drawing instructions
> together, I'd like to do things 'right' (If there is such a thing)
>
> Many thanks for any info!
> Ian
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>



-- 
"I like to pay taxes. With them, I buy civilization." --  Oliver Wendell Holmes

From britten at caris.com  Thu Oct  1 10:05:55 2009
From: britten at caris.com (Ian Britten)
Date: Thu, 01 Oct 2009 14:05:55 -0300
Subject: [cairo] Underlining text, etc?
In-Reply-To: <2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>
References: <4AC4D9A0.5050301@caris.com>
	<2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>
Message-ID: <4AC4E173.8060604@caris.com>

Dominic Lachowicz wrote:

> Cairo doesn't support font markup. Pango does support the few features
> you mentioned, though.
> 
> http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html

Thanks for the info!

I'm not sure if you were suggesting I use Pango - Unfortunately, that's
not possible.  (I'm in code that is roughly equivalent to Pango though,
layout out text, rendering it, etc).

However, I may try to grep around in the Pango code to see if I can
figure out how they're supporting their features. (Not always fun...)

Thanks,
Ian


From domlachowicz at gmail.com  Thu Oct  1 10:10:38 2009
From: domlachowicz at gmail.com (Dominic Lachowicz)
Date: Thu, 1 Oct 2009 13:10:38 -0400
Subject: [cairo] Librsvg + cairo animation flicker
In-Reply-To: <24812956.11175001254414299451.JavaMail.www@wwinf4601>
References: <24812956.11175001254414299451.JavaMail.www@wwinf4601>
Message-ID: <2672cf4d0910011010o58a22bbdq2547deb6eebd7d1f@mail.gmail.com>

Hi Enrique,

RE: thread safety, you shouldn't call rsvg_handle_render_cairo() on
the same handle and cairo surface concurrently from multiple threads.

librsvg draws directly to the cairo surface, so from the limited
information you provided, I can't imagine why it would behave
differently than your direct calls to cairo.

Is your flicker due to how long it takes to render the SVG? If that's
the case, you might want to cache your SVG sprites as image surfaces,
and then blit them onto your SDL surface.

Best,
Dom

On Thu, Oct 1, 2009 at 12:24 PM, flying.toaster <flying.toaster at voila.fr> wrote:
> Hi all
>
> ?I am trying to put up an application animating SVG objects (as sprites) with Librsvg and cairo on top of SDL on a Win32 rig (yeah, that IS weird).
> I am using a SDL timer to update periodically the image.
> I have tried all sorts of backbuffering (cairo surfaces, SDL surfaces) but I still get a terrible flicker on the parts that are drawn through a call to rsvg_handle_render_cairo. Parts drawn through direct calls to cairo do not exhibit this flicker.
> Wondering if this function is thread unsafe or something... Has anybody a clue on this kind of issue ?
>
> Thanks in advance
>
> Enrique
>
> ____________________________________________________
>
> Retour sur un week-end charg? en exploits?sur http://sports.voila.fr/
>
>
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo



-- 
"I like to pay taxes. With them, I buy civilization." --  Oliver Wendell Holmes

From fejj at novell.com  Thu Oct  1 10:43:42 2009
From: fejj at novell.com (Jeffrey Stedfast)
Date: Thu, 01 Oct 2009 13:43:42 -0400
Subject: [cairo] Underlining text, etc?
In-Reply-To: <4AC4E173.8060604@caris.com>
References: <4AC4D9A0.5050301@caris.com>	<2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>
	<4AC4E173.8060604@caris.com>
Message-ID: <4AC4EA4E.4010602@novell.com>

Ian Britten wrote:
> Dominic Lachowicz wrote:
>
>   
>> Cairo doesn't support font markup. Pango does support the few features
>> you mentioned, though.
>>
>> http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html
>>     
>
> Thanks for the info!
>
> I'm not sure if you were suggesting I use Pango - Unfortunately, that's
> not possible.  (I'm in code that is roughly equivalent to Pango though,
> layout out text, rendering it, etc).
>
> However, I may try to grep around in the Pango code to see if I can
> figure out how they're supporting their features. (Not always fun...)
>   

Take a look at FreeType2's underline_position and underline_thickness
attributes on the FT_Face you're using to render the glyphs. Once you
know those values, it's pretty trivial to render underlines.

(I assume you are using FreeType2)

Jeff


From britten at caris.com  Fri Oct  2 12:21:21 2009
From: britten at caris.com (Ian Britten)
Date: Fri, 02 Oct 2009 16:21:21 -0300
Subject: [cairo] Underlining text, etc?
In-Reply-To: <4AC4EA4E.4010602@novell.com>
References: <4AC4D9A0.5050301@caris.com>	<2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>
	<4AC4E173.8060604@caris.com> <4AC4EA4E.4010602@novell.com>
Message-ID: <4AC652B1.4050301@caris.com>

Jeffrey Stedfast wrote:

> Take a look at FreeType2's underline_position and underline_thickness
> attributes on the FT_Face you're using to render the glyphs. Once you
> know those values, it's pretty trivial to render underlines.

Thanks.  We already use this in our main (non-Cairo) rendering path.

However, I now see that where I'm trying to patch Cairo in, I may not
have the info I need (Critically, the next/previous character).  I'm
in a "draw this single character at this position" hook, so I'm not
sure how I'll figure out how to make the points for the line, etc... :(
[ Which is kindof why I was hoping Cairo automagically handled it! :) ]

Irregardless, I'm still open to any suggestions about how to how to
best use Cairo to do this.  For example, should I draw each underline
stroke after each character, or should I draw all the underlines
separately after the characters?  What if the text and strikeout are
partially transparent - Shouldn't the result have one homogeneous
alpha?  Is this somewhere I should maybe make use of a Cairo 'group'?
I haven't used them anywhere yet ...

Anyways, thanks for the feedback, and for any suggestions!
Ian


From fejj at novell.com  Fri Oct  2 14:05:26 2009
From: fejj at novell.com (Jeffrey Stedfast)
Date: Fri, 02 Oct 2009 17:05:26 -0400
Subject: [cairo] Underlining text, etc?
In-Reply-To: <4AC652B1.4050301@caris.com>
References: <4AC4D9A0.5050301@caris.com>	<2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>	<4AC4E173.8060604@caris.com>
	<4AC4EA4E.4010602@novell.com> <4AC652B1.4050301@caris.com>
Message-ID: <4AC66B16.20303@novell.com>

Ian Britten wrote:
[snip]
>
> Irregardless, I'm still open to any suggestions about how to how to
> best use Cairo to do this.  For example, should I draw each underline
> stroke after each character, or should I draw all the underlines
> separately after the characters?  What if the text and strikeout are
> partially transparent - Shouldn't the result have one homogeneous
> alpha?  Is this somewhere I should maybe make use of a Cairo 'group'?
> I haven't used them anywhere yet ...
>   

What I do is render a string of glyphs that all share the same font and
then go back and draw/fill the underline separately (having kept track
of the 'advance' width of the full run of glyphs).

Jeff


From ajohnson at redneon.com  Sun Oct  4 18:30:15 2009
From: ajohnson at redneon.com (Adrian Johnson)
Date: Mon, 05 Oct 2009 12:00:15 +1030
Subject: [cairo] fallback resolution bug?
In-Reply-To: <3c78ff030909291609n78f61fc7u2018a47b3630446a@mail.gmail.com>
References: <3c78ff030909291609n78f61fc7u2018a47b3630446a@mail.gmail.com>
Message-ID: <4AC94C27.4050600@redneon.com>

bulia byak wrote:
> Hi Carl,
> 
> I'm addressing you personally because I saw your blog post about a
> similar, or maybe even the same, bug. I attach a simple SVG which was
> exported by Inkscape to EPS, using cairo operations as we now do.
> There are two bugs:
> 
> - where the transparent image overlaps the text, it is obvious that it
> is rasterized at a very small resolution, perhaps 72 dpi, not the
> default 300. Inkscape never sets this so it should be 300. The image
> itself it rendered at 300 dpi, but the other objects touched by it are
> not.
> 
> - in fact, in the rasterized bitmap there must be no text at all -
> because text is higher in z-order and thus is not affected by the
> image with alpha anyway. Fallback rasterization should render only the
> transparent object and whatever is BELOW it, not above.

There are many optimizations that could be done to improve output in 
cases such as the above. But they also add a lot more complexity to the 
fallback code for limited gain.

I am not planning on doing any further optimizing of the finer grained 
fallbacks code. However patches are welcome.

Note also that in PDF surface fallback images can only be painted last 
due to need to use a knockout group to paint the fallback image on top.

> 
> This is with cairo 1.8.8. Can you tell me if there exists a version
> that fixes at least the first of these bugs? If not what can I do to
> help you or someone in the know to fix it?

I have a branch that contains a fix for Carl's patch for this bug. It 
works for me.

http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=acquire_source_image_transformed

> 
> Thanks!
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From buliabyak at gmail.com  Sun Oct  4 19:39:42 2009
From: buliabyak at gmail.com (bulia byak)
Date: Sun, 4 Oct 2009 23:39:42 -0300
Subject: [cairo] fallback resolution bug?
In-Reply-To: <4AC94C27.4050600@redneon.com>
References: <3c78ff030909291609n78f61fc7u2018a47b3630446a@mail.gmail.com>
	<4AC94C27.4050600@redneon.com>
Message-ID: <3c78ff030910041939o7c7dbd5di4a9d5e6512265109@mail.gmail.com>

On Sun, Oct 4, 2009 at 10:30 PM, Adrian Johnson <ajohnson at redneon.com> wrote:
> I have a branch that contains a fix for Carl's patch for this bug. It works
> for me.
>
> http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=acquire_source_image_transformed

1. Do you have, by chance, a Windows build of this branch?

2. Do you have an idea what official cairo version will have this fix?

Thanks!

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

From britten at caris.com  Mon Oct  5 05:55:47 2009
From: britten at caris.com (Ian Britten)
Date: Mon, 05 Oct 2009 09:55:47 -0300
Subject: [cairo] Underlining text, etc?
In-Reply-To: <4AC66B16.20303@novell.com>
References: <4AC4D9A0.5050301@caris.com>	<2672cf4d0910010958x38083768se74a113b55dec99c@mail.gmail.com>	<4AC4E173.8060604@caris.com>
	<4AC4EA4E.4010602@novell.com> <4AC652B1.4050301@caris.com>
	<4AC66B16.20303@novell.com>
Message-ID: <4AC9ECD3.4000208@caris.com>

Jeffrey Stedfast wrote:

>> Irregardless, I'm still open to any suggestions about how to how to
>> best use Cairo to do this.  For example, should I draw each underline
>> stroke after each character, or should I draw all the underlines
>> separately after the characters?  
[ snip ]
> What I do is render a string of glyphs that all share the same font and
> then go back and draw/fill the underline separately (having kept track
> of the 'advance' width of the full run of glyphs).

Ya, I'm starting to see that I'm going to have to rip apart our
non-Cairo rendering engine that I'm trying to patch into, and rework
how it performs underlining (Something I was hoping to avoid...).

Additional complexities that I have to deal with is exotic/advanced
text cases, such as curved text, text with track-kerning ("Expanded"),
multi-line text, in addition to the multiple-font RTF/HTML-like text
that you mentioned.
This could get ugly... :(

Many thanks for the feedback - I suspect this won't be my last post
about this stuff ... :P
Ian


From wpmami at gmail.com  Mon Oct  5 06:26:13 2009
From: wpmami at gmail.com (Mami)
Date: Mon, 5 Oct 2009 15:26:13 +0200
Subject: [cairo] drawing tons of circles
Message-ID: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>

hi all,

I'm new to cairo and have a performance question.
I need to draw tons of filled circles (thousand, actually) and I found that
using cairo_arc is not the way to go; it lacks the performance I need.

Can you recommend a method for drawing such a lot of objects in an
acceptable timeframe?

thanks,
/mami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091005/37c9e840/attachment.html 

From ntd at entidi.it  Mon Oct  5 07:44:17 2009
From: ntd at entidi.it (Nicola Fontana)
Date: Mon, 5 Oct 2009 16:44:17 +0200
Subject: [cairo] drawing tons of circles
In-Reply-To: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
References: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
Message-ID: <20091005164417.2b96825e@entidi.it>

Il giorno Mon, 5 Oct 2009 15:26:13 +0200
Mami <wpmami at gmail.com> ha scritto:

> I need to draw tons of filled circles (thousand, actually) and I
> found that using cairo_arc is not the way to go; it lacks the
> performance I need.
> 
> Can you recommend a method for drawing such a lot of objects in an
> acceptable timeframe?

If the bottleneck is not in the backend I'd compute only once the circle
path, rendering it multiple times with different matrices. Something
like this (not tested):

cairo_arc(cr, 0, 0, 1, 0, M_PI*2);
path = cairo_copy_path(cr);

cairo_matrix_init(&matrix, radius1, 0, 0, radius1, x1, y1);
cairo_set_matrix(cr, &matrix);
cairo_fill(cr);

cairo_matrix_init(&matrix, radius2, 0, 0, radius2, x2, y2);
cairo_set_matrix(cr, &matrix);
cairo_append_path(cr, path);
cairo_fill(cr);

...

cairo_path_destroy(path);

-- 
Nicola

From chris at chris-wilson.co.uk  Mon Oct  5 08:15:08 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Mon, 05 Oct 2009 16:15:08 +0100
Subject: [cairo] drawing tons of circles
In-Reply-To: <20091005164417.2b96825e@entidi.it>
References: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
	<20091005164417.2b96825e@entidi.it>
Message-ID: <1254755275-sup-9090@broadwater.alporthouse.com>

Excerpts from Nicola Fontana's message of Mon Oct 05 15:44:17 +0100 2009:
> Il giorno Mon, 5 Oct 2009 15:26:13 +0200
> Mami <wpmami at gmail.com> ha scritto:
> 
> > I need to draw tons of filled circles (thousand, actually) and I
> > found that using cairo_arc is not the way to go; it lacks the
> > performance I need.
> > 
> > Can you recommend a method for drawing such a lot of objects in an
> > acceptable timeframe?
> 
> If the bottleneck is not in the backend I'd compute only once the circle
> path, rendering it multiple times with different matrices. Something
> like this (not tested):

That still converts the path to a mask multiple times. The trick, if you
are willing to sacrifice sub-pixel accuracy (and there are times when
that is desired or mitigated by other means) is to render the circle to
a 'large' alpha-only similar surface:

mask_surface
    = cairo_surface_create_similar (cairo_get_target (cr),
                                    CAIRO_CONTENT_ALPHA,
				    128, 128);
cr_mask = cairo_create (mask_surface);
cairo_surface_destroy (mask_surface);

cairo_arc (cr_mask, 64, 64, 64, 0, 2 * M_PI);
cairo_fill (cr_mask);
mask = cairo_pattern_create_for_surface (cairo_get_target (cr_mask));
cairo_destroy (cr_mask);

Then to use, something like:
cairo_matrix_init_scale (&m, r/128., r/128.);
cairo_matrix_translate (&m, -x, -y);
cairo_pattern_set_matrix (mask, &m);
cairo_set_source (cr, source);
cairo_mask (cr, mask);

It is tempting to create first class paths to do the same, but that is
not trivial and so the complexity and trade-offs are pushed to the
higher layers.

Hope this helps (and the rushed transformations are correct!).
Have fun with cairo!
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From wpmami at gmail.com  Mon Oct  5 11:22:06 2009
From: wpmami at gmail.com (Mami)
Date: Mon, 5 Oct 2009 20:22:06 +0200
Subject: [cairo] drawing tons of circles
In-Reply-To: <1254755275-sup-9090@broadwater.alporthouse.com>
References: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
	<20091005164417.2b96825e@entidi.it>
	<1254755275-sup-9090@broadwater.alporthouse.com>
Message-ID: <c788573a0910051122i3d6f1402wf1cd8b6bcfb14e48@mail.gmail.com>

> That still converts the path to a mask multiple times. The trick, if you
> are willing to sacrifice sub-pixel accuracy (and there are times when
> that is desired or mitigated by other means) is to render the circle to
> a 'large' alpha-only similar surface:
>

thanks a lot,

that is definately faster. I need to play a bit to correctly position the
circles but I seem to be on track.

br,
/mami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091005/bd8aeea5/attachment.htm 

From chris at chris-wilson.co.uk  Mon Oct  5 11:27:18 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Mon, 05 Oct 2009 19:27:18 +0100
Subject: [cairo] drawing tons of circles
In-Reply-To: <c788573a0910051122i3d6f1402wf1cd8b6bcfb14e48@mail.gmail.com>
References: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
	<20091005164417.2b96825e@entidi.it>
	<1254755275-sup-9090@broadwater.alporthouse.com>
	<c788573a0910051122i3d6f1402wf1cd8b6bcfb14e48@mail.gmail.com>
Message-ID: <1254767094-sup-733@broadwater.alporthouse.com>

Excerpts from Mami's message of Mon Oct 05 19:22:06 +0100 2009:
> that is definately faster. I need to play a bit to correctly position the
> circles but I seem to be on track.

I should also mention that scaling artefacts may cause uglies if the
mask is more than 2x the size of the resultant circle. Just a word of
warning.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From wpmami at gmail.com  Mon Oct  5 12:04:53 2009
From: wpmami at gmail.com (Mami)
Date: Mon, 5 Oct 2009 21:04:53 +0200
Subject: [cairo] drawing tons of circles
In-Reply-To: <1254767094-sup-733@broadwater.alporthouse.com>
References: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
	<20091005164417.2b96825e@entidi.it>
	<1254755275-sup-9090@broadwater.alporthouse.com>
	<c788573a0910051122i3d6f1402wf1cd8b6bcfb14e48@mail.gmail.com>
	<1254767094-sup-733@broadwater.alporthouse.com>
Message-ID: <c788573a0910051204p39a246e3y581e2373f2146658@mail.gmail.com>

On Mon, Oct 5, 2009 at 8:27 PM, Chris Wilson <chris at chris-wilson.co.uk>wrote:

> Excerpts from Mami's message of Mon Oct 05 19:22:06 +0100 2009:
> > that is definately faster. I need to play a bit to correctly position the
> > circles but I seem to be on track.
>
> I should also mention that scaling artefacts may cause uglies if the
> mask is more than 2x the size of the resultant circle. Just a word of
> warning.
> -ickle
>

yep, that is another issue.
I need small circles so I have tried to create a small original arc and use
no scaling matrix, but that is a big performance hit.

br,
-mami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091005/bc32bcbc/attachment.htm 

From andrew4main at googlemail.com  Mon Oct  5 12:58:22 2009
From: andrew4main at googlemail.com (Andrew Main)
Date: Mon, 5 Oct 2009 20:58:22 +0100
Subject: [cairo] Cairo & Pango
Message-ID: <0E1EE757B1F7481E938201DD67E4D396@STUDY>

The documentation on Cairo & Pango that I have found is ultra-brief and
seems to assume that I know lots about font data structures.  I need to
break in to it, to go beyond the "toy text".  Is there a comprehensive
document to use?
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091005/66783eec/attachment.htm 

From domlachowicz at gmail.com  Mon Oct  5 13:22:08 2009
From: domlachowicz at gmail.com (Dominic Lachowicz)
Date: Mon, 5 Oct 2009 16:22:08 -0400
Subject: [cairo] Cairo & Pango
In-Reply-To: <0E1EE757B1F7481E938201DD67E4D396@STUDY>
References: <0E1EE757B1F7481E938201DD67E4D396@STUDY>
Message-ID: <2672cf4d0910051322o3aa6a9e9t7b1a686112265bbb@mail.gmail.com>

Have you looked at
http://library.gnome.org/devel/pango/stable/pango-Cairo-Rendering.html?
It has decent documentat ion and a C example. You don't need to know
too much about font data structures. Mostly, you just have to use the
pango_cairo font map, use Pango as you otherwise would, and then use
pango_cairo_show_layout() when you want to draw.

Best,
Dom

On Mon, Oct 5, 2009 at 3:58 PM, Andrew Main <andrew4main at googlemail.com> wrote:
> The documentation on Cairo & Pango that I have found is ultra-brief and
> seems to assume that I know lots about font data structures.? I need to
> break in to it, to go beyond the "toy text".? Is there a comprehensive
> document to use?
> Andrew
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>



-- 
"I like to pay taxes. With them, I buy civilization." --  Oliver Wendell Holmes

From xinanchen888 at yahoo.com  Mon Oct  5 18:37:08 2009
From: xinanchen888 at yahoo.com (xin an chen)
Date: Mon, 5 Oct 2009 18:37:08 -0700 (PDT)
Subject: [cairo] Initial invocation of cairo_text_extents is extremely slow
Message-ID: <314925.27987.qm@web57607.mail.re1.yahoo.com>

Hi, All,
     I have one situation as follows:

(1)	In my program, the initial invocation of cairo function:

                         cairo_text_extents

              is extremely slow, sometimes it takes about 60 seconds for this function to return;

(2)	After the initial invocation of cairo_text_extents, any subsequent invocation of this
method becomes very fast, it returns in less than 1 second.

     Why cairo_text_extents behaviors like this? Is there any way to solve this problem?


Thanks very much,

Regards,

Sam



      

From ml3p at onghu.com  Tue Oct  6 09:23:05 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Wed, 07 Oct 2009 00:23:05 +0800
Subject: [cairo] Building pixman for Windows CE
In-Reply-To: <91882ea90910010907q3eae5474p21b4e148af3053e4@mail.gmail.com>
References: <4AC4CDA7.7070909@onghu.com>
	<91882ea90910010907q3eae5474p21b4e148af3053e4@mail.gmail.com>
Message-ID: <4ACB6EE9.1090004@onghu.com>

Gerdus van Zyl wrote:
> First build pixman seperately. config.h is a file made by the
> ./configure command and is just a bunch of c defines. The build files
> will also use a perl script to create pixman-combine32/64 so you might
> be missing those as well. I would recommend installing msys/mingw
> (might take a little work) and running the default build scripts, then
> you can just copy the generated files and reverse engineer the build
> process a little better.
>   

Hi!  I tried to go down this path... and did a configure under MSYS to 
produce the files... and adjusted the files slightly.
Now, when I try to compile pixman with Visual Studio 2005, I get this 
error (a large number) in pixman-region.c

1>..\..\..\pixman\pixman\pixman-region.c(109) : error C2061: syntax 
error : identifier 'PREFIX'
1>..\..\..\pixman\pixman\pixman-region.c(109) : error C2059: syntax 
error : ';'
1>..\..\..\pixman\pixman\pixman-region.c(109) : error C2078: too many 
initializers

The first of these lines is:
static const box_type_t PREFIX (_empty_box_) = { 0, 0, 0, 0 };

Any idea what I can try?

Cheers,
Mohit.
10/7/2009 | 12:23 AM.


From ml3p at onghu.com  Tue Oct  6 09:56:04 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Wed, 07 Oct 2009 00:56:04 +0800
Subject: [cairo] Building pixman for Windows CE
In-Reply-To: <4ACB6EE9.1090004@onghu.com>
References: <4AC4CDA7.7070909@onghu.com>	<91882ea90910010907q3eae5474p21b4e148af3053e4@mail.gmail.com>
	<4ACB6EE9.1090004@onghu.com>
Message-ID: <4ACB76A4.7040208@onghu.com>

Mohit Sindhwani wrote:
> Gerdus van Zyl wrote:
>   
>> First build pixman seperately. config.h is a file made by the
>> ./configure command and is just a bunch of c defines. The build files
>> will also use a perl script to create pixman-combine32/64 so you might
>> be missing those as well. I would recommend installing msys/mingw
>> (might take a little work) and running the default build scripts, then
>> you can just copy the generated files and reverse engineer the build
>> process a little better.
>>   
>>     
>
> Hi!  I tried to go down this path... and did a configure under MSYS to 
> produce the files... and adjusted the files slightly.
> Now, when I try to compile pixman with Visual Studio 2005, I get this 
> error (a large number) in pixman-region.c
>
> 1>..\..\..\pixman\pixman\pixman-region.c(109) : error C2061: syntax 
> error : identifier 'PREFIX'
> 1>..\..\..\pixman\pixman\pixman-region.c(109) : error C2059: syntax 
> error : ';'
> 1>..\..\..\pixman\pixman\pixman-region.c(109) : error C2078: too many 
> initializers
>
> The first of these lines is:
> static const box_type_t PREFIX (_empty_box_) = { 0, 0, 0, 0 };
>   
OK, answering my own question so no one else needs to...
I accidentally included both pixman-region.c and also pixman-region16.c 
and pixman-region32.c

As it turns out, pixman-region.c is included into the others, so there 
is no need to include it in the build files.

OK - now on to trying to build Cairo for Windows CE!

Cheers,
Mohit.
10/7/2009 | 12:56 AM.


From sandmann at daimi.au.dk  Tue Oct  6 13:06:34 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 06 Oct 2009 22:06:34 +0200
Subject: [cairo] Faster bilinear scaling
Message-ID: <ye8ljjoz3qt.fsf@camel24.daimi.au.dk>

Hi,

This branch:

        http://cgit.freedesktop.org/~sandmann/pixman/log/?h=bilinear

contains a fast path for fetching of bilinearly filtered, scaled
images. It is basically Andre's work, described here:

        http://lists.cairographics.org/archives/cairo/2008-December/016170.html

What I did was

        - Update scaling-test to also test bilinear scaling

        - Remove bilinear_interpolation_left/right() functions in
          favor of just calling bilinear_interpolation().

        - Fix coding style.

The performance improvement for the swfdec-youtube benchmark on a
3.8GHz P4 is around 17%:

Before:

[ # ]  backend                         test   min(s) median(s)  stddev. count
[  0]    image               swfdec-youtube    8.375    8.431   0.44%   6/6

After:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image               swfdec-youtube    6.942    7.019   0.61%  6/6

Much of the profile of this benchmark is in radial gradients, so other
users of bilinear scaling may see more improvement.

Also, if anyone is interested in adding support for SIMD acceeleration
of fetchers, the the bilinear_interpolation() function is begging to
be written with SSE2 or NEON.

Comments welcome.


Thanks,
Soren

From freddie at witherden.org  Tue Oct  6 12:58:32 2009
From: freddie at witherden.org (Freddie Witherden)
Date: Tue, 6 Oct 2009 20:58:32 +0100
Subject: [cairo] Subpixel Positioning w/FreeType
Message-ID: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>

Hi all,

I am wondering about any current or future proposals for supporting  
subpixel positioning with FreeType. Subpixel positioning -- not to be  
confused with subpixel rendering/anti-aliasing -- allows for more  
accurate glyph positioning.

Much like subpixel rendering, subpixel positioning takes advantage of  
the fact that LCD screens are made up of three subpixels in a specific  
order. This order is usually RGB. The predictable subpixel order  
allows for three times the horizontal resolution. The same technique  
can be applied to glyph positions. Instead of having to start on a  
pixel boundary glyphs are instead able to start on a subpixel  
boundary. This allows for spacing accurate to 1/3 of a pixel in most  
cases.

It is my understanding (from looking over the source) that Cairo does  
not currently support subpixel positing under FreeType. Further, I  
also understand that the FreeType code has been recently re-written  
(there was a note on the 1.10 roadmap) to take advantage of the  
subpixel filtering API exported by FreeType.

I believe that basic, 1/3 of a pixel, subpixel positing could be  
implemented in Cairo without a huge amount of work. It would of course  
only be applicable when subpixel rendering is enabled. Since Cairo and  
Pango both already use fractional co-ordinates this should not break  
backwards compatibility.

Both Quartz (OS X) and ClearType (Windows) support this already.

Polemically yours, Freddie.

From robert at ocallahan.org  Tue Oct  6 16:33:20 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 7 Oct 2009 12:33:20 +1300
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
Message-ID: <11e306600910061633l3b7d528dga09aaa21c466cc2@mail.gmail.com>

On Wed, Oct 7, 2009 at 8:58 AM, Freddie Witherden <freddie at witherden.org>wrote:

> I believe that basic, 1/3 of a pixel, subpixel positing could be
> implemented in Cairo without a huge amount of work. It would of course
> only be applicable when subpixel rendering is enabled. Since Cairo and
> Pango both already use fractional co-ordinates this should not break
> backwards compatibility.
>
> Both Quartz (OS X) and ClearType (Windows) support this already.
>

You mean the Windows WPF ClearType rasterizer? AFAIK GDI Cleartype does not
support this.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091007/28abab7b/attachment.html 

From tellrob at gmail.com  Tue Oct  6 17:03:15 2009
From: tellrob at gmail.com (Rob Arnold)
Date: Tue, 6 Oct 2009 20:03:15 -0400
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <11e306600910061633l3b7d528dga09aaa21c466cc2@mail.gmail.com>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
	<11e306600910061633l3b7d528dga09aaa21c466cc2@mail.gmail.com>
Message-ID: <2c9b9650910061703j5781f7deif29254734db4a50@mail.gmail.com>

On Tue, Oct 6, 2009 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Oct 7, 2009 at 8:58 AM, Freddie Witherden <freddie at witherden.org>wrote:
>
>> I believe that basic, 1/3 of a pixel, subpixel positing could be
>> implemented in Cairo without a huge amount of work. It would of course
>> only be applicable when subpixel rendering is enabled. Since Cairo and
>> Pango both already use fractional co-ordinates this should not break
>> backwards compatibility.
>>
>> Both Quartz (OS X) and ClearType (Windows) support this already.
>>
>
> You mean the Windows WPF ClearType rasterizer? AFAIK GDI Cleartype does not
> support this.
>

I'm pretty sure it's new in WPF/DirectWrite. But I'm not sure it uses 1/3
for sub pixel positioning. Before picking a fraction, it would be good to
find out what the other rasterizers have chosen for their pixel subdivision.

-Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091006/2cbba560/attachment.htm 

From mikhailkozhevnikov at yandex.ru  Wed Oct  7 11:03:00 2009
From: mikhailkozhevnikov at yandex.ru (Kozhevnikov Mikhail)
Date: Wed, 07 Oct 2009 22:03:00 +0400
Subject: [cairo] building pixman 0.16.2 with MinGW
Message-ID: <119991254938580@webmail25.yandex.ru>

Hello,

I'm trying to build pixman with MinGW/MSYS on Windows XP. The 'configure' script works fine, but 'make' fails after a while. The log is attached.

Any ideas?

Thanks in advance, 
Mikhail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pixman-make.log
Type: application/octet-stream
Size: 37818 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091007/632836c2/attachment-0001.obj 

From cloos at jhcloos.com  Wed Oct  7 11:34:49 2009
From: cloos at jhcloos.com (James Cloos)
Date: Wed, 07 Oct 2009 14:34:49 -0400
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <2c9b9650910061703j5781f7deif29254734db4a50@mail.gmail.com> (Rob
	Arnold's message of "Tue, 6 Oct 2009 20:03:15 -0400")
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
	<11e306600910061633l3b7d528dga09aaa21c466cc2@mail.gmail.com>
	<2c9b9650910061703j5781f7deif29254734db4a50@mail.gmail.com>
Message-ID: <m33a5v8332.fsf@lugabout.jhcloos.org>

>>>>> "Rob" == Rob Arnold <tellrob at gmail.com> writes:

Rob> I'm pretty sure it's new in WPF/DirectWrite. But I'm not sure it
Rob> uses 1/3 for sub pixel positioning. Before picking a fraction, it
Rob> would be good to find out what the other rasterizers have chosen
Rob> for their pixel subdivision.

The note about Cleartype recently posted, IIRC, to the opentype list
says that it uses 4 bits of fraction.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From cworth at cworth.org  Wed Oct  7 15:46:36 2009
From: cworth at cworth.org (Carl Worth)
Date: Wed, 07 Oct 2009 15:46:36 -0700
Subject: [cairo] Getting serious about making a cairo 1.10 release
Message-ID: <1254955092-sup-6757@yoom.home.cworth.org>

We've let far too much time go by without a new major release of
cairo. Much of that's my fault, and I apologize for that.

In the meantime, there are just a huge pile of interesting features
sitting on cairo master that we really want to get out to people.

So I'm placing my release-manager hat on firmly, and proposing the
following plan for getting the release done.

I just created a new tracker bug for cairo 1.10 here:

    https://bugs.freedesktop.org/show_bug.cgi?id=cairo-1.10

(It's got an alias of "cairo-1.10" so you don't need to remember any
magic bug number for it.)

My plan is to release cairo 1.10 when the above bug report does not
depend on any unfixed bugs.

This means we all need to work together to do the following:

    * Test cairo master or the latest cairo 1.9.x snapshot

    * Report bugs at bugs.freedesktop.org when you find them

    * Edit the "depends on" list in the cairo-1.10 bug to add any
      bugs that should block the release.

    * Help fix bugs in the cairo-1.10 "depends on" list.

I've started the list with a bug demonstrating an infinite loop in
cairo triggered by a particular PDF document. I'd also like to depend
on a bug describing the firefox crash issue. (Chris is quite certain
this is a bug in firefox, but even then, I'd like to see *that* fixed
before we release cairo 1.10).

What other bugs are in cairo that need to be fixed before 1.10? Some
issues with PDF snapshot support? Some additional review of some of
the new 1.10 API?

Let's get things listed so we don't forget anything important.

Thanks everybody, and let's all have fun making cairo better!

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091007/cb9cef4e/attachment.pgp 

From spitzak at gmail.com  Wed Oct  7 17:13:28 2009
From: spitzak at gmail.com (Bill Spitzak)
Date: Wed, 07 Oct 2009 17:13:28 -0700
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <m33a5v8332.fsf@lugabout.jhcloos.org>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>	<11e306600910061633l3b7d528dga09aaa21c466cc2@mail.gmail.com>	<2c9b9650910061703j5781f7deif29254734db4a50@mail.gmail.com>
	<m33a5v8332.fsf@lugabout.jhcloos.org>
Message-ID: <4ACD2EA8.5020506@gmail.com>

May want to investigate how many subpixel positions are needed so that a 
diagonal line of text looks straight. I think this may have stronger 
requirements than a horizontal line of text. Try using Cairo to draw 
small tilted anti-aliased rectangles and see what rounding factor for 
the position you can get away with before a row of them does not look 
straight.

Also the number of positions needed probably goes down as the font size 
gets bigger.

The 4 bits may only be some internal data storage and ClearType may be 
using fewer images, ie some of the 16 possible sub-positions map to the 
same glyph. 4 is the smallest power of 2 that will give 3 positions 
anything close to equal weight and may explain why it was chosen.

James Cloos wrote:
>>>>>> "Rob" == Rob Arnold <tellrob at gmail.com> writes:
> 
> Rob> I'm pretty sure it's new in WPF/DirectWrite. But I'm not sure it
> Rob> uses 1/3 for sub pixel positioning. Before picking a fraction, it
> Rob> would be good to find out what the other rasterizers have chosen
> Rob> for their pixel subdivision.
> 
> The note about Cleartype recently posted, IIRC, to the opentype list
> says that it uses 4 bits of fraction.
> 
> -JimC

From andrew at operationaldynamics.com  Wed Oct  7 16:33:18 2009
From: andrew at operationaldynamics.com (Andrew Cowie)
Date: Thu, 08 Oct 2009 10:33:18 +1100
Subject: [cairo] Getting serious about making a cairo 1.10 release
In-Reply-To: <1254955092-sup-6757@yoom.home.cworth.org>
References: <1254955092-sup-6757@yoom.home.cworth.org>
Message-ID: <1254958398.16995.12.camel@moonglow>

On Wed, 2009-10-07 at 15:46 -0700, Carl Worth wrote:
>     * Test cairo master or the latest cairo 1.9.x snapshot

Does anyone know off-hand of a reliable Ubuntu .deb or Fedora .rpm of
the Cairo 1.9.x snapshots?

AfC
Sydney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20091008/05f6a9c2/attachment.pgp 

From freddie at witherden.org  Thu Oct  8 01:24:48 2009
From: freddie at witherden.org (Freddie Witherden)
Date: Thu, 8 Oct 2009 09:24:48 +0100
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <4ACD2EA8.5020506@gmail.com>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
	<m33a5v8332.fsf@lugabout.jhcloos.org> <4ACD2EA8.5020506@gmail.com>
Message-ID: <200910080924.48151.freddie@witherden.org>

On Thursday 08 October 2009 01:13:28 Bill Spitzak wrote:
> The 4 bits may only be some internal data storage and ClearType may be
> using fewer images, ie some of the 16 possible sub-positions map to the
> same glyph. 4 is the smallest power of 2 that will give 3 positions
> anything close to equal weight and may explain why it was chosen.

It is my understanding that three positions of subpixel precision were chosen 
as most LCD screens are made up of three vertical subpixels. While it does 
seem theoretically possible to have more than that by adjusting the intensity 
of the pixels this is likely to cause blur glyphs further.

Regards, Freddie.

From ml3p at onghu.com  Thu Oct  8 05:21:50 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Thu, 08 Oct 2009 20:21:50 +0800
Subject: [cairo] Problems with building Cairo for Windows CE
Message-ID: <4ACDD95E.4050006@onghu.com>

Hello!  So, I managed to get the latest pixman to build and I have 
binaries for zlibce and libpngce.
I tried to follow the instructions at: 
http://vividos.wordpress.com/2008/01/23/how-to-compile-cairo-for-pocketpc/ 
but I'm using Cairo 1.8.8

But, I do run into a few problems.  The main issues were with io.h, 
errno.h and so on.  I stole seemingly relevant files from 
https://ella.pragmaticomm.com/symbian-ruby/browser/trunk/wince which has 
compatible files.

Next on, I'm stuck at an error in building win32-surface.c - there seem 
to be some errors related to the function:
* _cairo_win32_save_initial_clip -> called from 
_cairo_win32_surface_finish, _cairo_win32_surface_set_clip_region

Compilation errors/ warnings include:
1>..\..\..\cairo\src\cairo-win32-surface.c(1543) : warning C4013: 
'ExtSelectClipRgn' undefined; assuming extern returning int
1>..\..\..\cairo\src\cairo-win32-surface.c(2050) : warning C4013: 
'GetGraphicsMode' undefined; assuming extern returning int
1>..\..\..\cairo\src\cairo-win32-surface.c(2051) : error C2065: 
'GM_ADVANCED' : undeclared identifier
1>..\..\..\cairo\src\cairo-win32-surface.c(2052) : warning C4013: 
'GetWorldTransform' undefined; assuming extern returning int
1>..\..\..\cairo\src\cairo-win32-surface.c(2053) : warning C4013: 
'ModifyWorldTransform' undefined; assuming extern returning int
1>..\..\..\cairo\src\cairo-win32-surface.c(2053) : error C2065: 
'MWT_IDENTITY' : undeclared identifier
1>..\..\..\cairo\src\cairo-win32-surface.c(2059) : warning C4013: 
'SetGraphicsMode' undefined; assuming extern returning int
1>..\..\..\cairo\src\cairo-win32-surface.c(2083) : warning C4013: 
'SetWorldTransform' undefined; assuming extern returning int

These are new compared to 1.4.4 (the earlier build I had done), so I'm 
wondering what to do.

There are other errors, but these I have no idea what to do with (yet).

Thanks,
Mohit.


From jonathan.morton at movial.com  Thu Oct  8 07:14:48 2009
From: jonathan.morton at movial.com (Jonathan Morton)
Date: Thu, 08 Oct 2009 17:14:48 +0300
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <200910080924.48151.freddie@witherden.org>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
	<m33a5v8332.fsf@lugabout.jhcloos.org> <4ACD2EA8.5020506@gmail.com>
	<200910080924.48151.freddie@witherden.org>
Message-ID: <1255011288.6830.292.camel@sd070.hel.movial.fi>

On Thu, 2009-10-08 at 09:24 +0100, Freddie Witherden wrote:
> On Thursday 08 October 2009 01:13:28 Bill Spitzak wrote:
> > The 4 bits may only be some internal data storage and ClearType may be
> > using fewer images, ie some of the 16 possible sub-positions map to the
> > same glyph. 4 is the smallest power of 2 that will give 3 positions
> > anything close to equal weight and may explain why it was chosen.
> 
> It is my understanding that three positions of subpixel precision were chosen 
> as most LCD screens are made up of three vertical subpixels. While it does 
> seem theoretically possible to have more than that by adjusting the intensity 
> of the pixels this is likely to cause blur glyphs further.

As long ago as 1994, Acorn's RiscOS supported subpixel positioning of
antialiased text.  This was in the absence of any LCD-specific reasons
for doing so, as ClearType had not yet been invented.  I believe it only
supported half-pixels, or maybe quarter-pixels on each axis, but that
was more due to memory constraints than anything else.

It *did* improve the appearance of text, whenever the layout was not
explicitly bound to the screen physics - and this was on a mid-1990s 15"
CRT, on a machine rarely seen outside the UK.  The colour palettes were
heavily weighted towards grey-levels to support it.

With a 30MHz ARM CPU, it obviously had to pre-render and cache the
glyphs to get interactive performance.  It would have been unthinkable
on a similar 486 - at the time, an ARM was considered very fast.

By 1995, Apple also supported subpixel positioning of non-antialiased
text.  There was a preference option for it in ClarisWorks 3.  I always
turned it on and saw the difference.  I don't know how many bits were
involved, but I don't remember it causing any performance trouble on a
68K-based PowerBook.

ISTR seeing an article on ClearType which demonstrated that more than
even 4 bits of subpixel positioning could be visible even on horizontal
text.  The demonstration involved sub-point increments in font size.

The "blurry" argument is fallacious.  Windows users are just too used to
aggressive hinting, which distorts the glyph shapes in the name of
optical sharpness.  RiscOS didn't use hinting, and it looked wonderful
even at very small sizes.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com



From britten at caris.com  Thu Oct  8 07:49:45 2009
From: britten at caris.com (Ian Britten)
Date: Thu, 08 Oct 2009 11:49:45 -0300
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
Message-ID: <4ACDFC09.9030401@caris.com>

Freddie Witherden wrote:

> I am wondering about any current or future proposals for supporting  
> subpixel positioning with FreeType. Subpixel positioning -- not to be  
> confused with subpixel rendering/anti-aliasing -- allows for more  
> accurate glyph positioning.

FYI - Dunno if you've seen this before, but here is an (older)
post from FT, which I think is covering some of this (And more).
It also has some nice screenshot examples.
    http://lists.gnu.org/archive/html/freetype/2007-07/msg00007.html

Hope it helps!  (Apologies if it's not relevant)
Ian


From britten at caris.com  Thu Oct  8 09:35:46 2009
From: britten at caris.com (Ian Britten)
Date: Thu, 08 Oct 2009 13:35:46 -0300
Subject: [cairo] Missing consts?  [cairomm]
Message-ID: <4ACE14E2.9040907@caris.com>

Hi all,
    [ cairomm, v1.8.0 ]
It seems that
     Context::device_to_user();
     Context::device_to_user_distance();
     Context::user_to_device();
     Context::user_to_device_distance();
don't have const qualifiers.

Assuming they're appropriate, if they could be added someday, it'd
be appreciated!
Ian


From tgriggs at cincom.com  Thu Oct  8 10:58:32 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Thu, 8 Oct 2009 10:58:32 -0700
Subject: [cairo] Compiling on old Linuxes
Message-ID: <7CFF99A6-FCF2-4065-90F9-DA765550B68D@cincom.com>

Much thanks to those that have helped me get relocatable/distributable  
builds for both Windows and OSX, here or on the IRC channel.

I'm now trying to get a build or Linux. I'm using the 1.9.2 snapshot.  
I had to comment out the check in configure about requiring a native  
font backend.

I'm now getting this set of errors:

cairo-xlib-display.c: In function  
`_cairo_xlib_display_get_xrender_format':
cairo-xlib-display.c:518: `PictStandardA1' undeclared (first use in  
this function)
cairo-xlib-display.c:518: (Each undeclared identifier is reported only  
once
cairo-xlib-display.c:518: for each function it appears in.)
cairo-xlib-display.c:520: `PictStandardA8' undeclared (first use in  
this function)
cairo-xlib-display.c:522: `PictStandardRGB24' undeclared (first use in  
this function)
cairo-xlib-display.c:526: `PictStandardARGB32' undeclared (first use  
in this function)
cairo-xlib-display.c:528: implicit declaration of function  
`XRenderFindStandardFormat'
cairo-xlib-display.c:529: warning: assignment makes pointer from  
integer without a cast
cairo-xlib-display.c:514: warning: `pict_format' might be used  
uninitialized in this function
make[3]: *** [cairo-xlib-display.lo] Error 1
make[2]: *** [all] Error 2

I'm guessing that while it found XRender support when running  
configure, the XRender support here is too old? Or maybe something  
else? Anyone give any hints on what to hunt down?

This is a Red Hat 7.2 box, which I know is old, but is what some of  
our customers actually run on.

Thanks!

--
Travis Griggs
Objologist
"There are a thousand hacking at the branches of evil to one who is  
striking at the root" - Henry David Thoreau



From cworth at cworth.org  Thu Oct  8 11:43:39 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 08 Oct 2009 11:43:39 -0700
Subject: [cairo] drawing tons of circles
In-Reply-To: <c788573a0910051204p39a246e3y581e2373f2146658@mail.gmail.com>
References: <c788573a0910050626i7565a598v9f3df4e13f5ae387@mail.gmail.com>
	<20091005164417.2b96825e@entidi.it>
	<1254755275-sup-9090@broadwater.alporthouse.com>
	<c788573a0910051122i3d6f1402wf1cd8b6bcfb14e48@mail.gmail.com>
	<1254767094-sup-733@broadwater.alporthouse.com>
	<c788573a0910051204p39a246e3y581e2373f2146658@mail.gmail.com>
Message-ID: <1255027300-sup-7712@yoom.home.cworth.org>

Excerpts from Mami's message of Mon Oct 05 12:04:53 -0700 2009:
> On Mon, Oct 5, 2009 at 8:27 PM, Chris Wilson <chris at chris-wilson.co.uk>wrote:
> > I should also mention that scaling artefacts may cause uglies if the
> > mask is more than 2x the size of the resultant circle. Just a word of
> > warning.
> 
> yep, that is another issue.
> I need small circles so I have tried to create a small original arc and use
> no scaling matrix, but that is a big performance hit.

So with our current, ugly scaling, you could support a wide range of
circle sizes by creating several different circle masks in advance,
each twice as large as the previous, to cover the range of sizes.

Of course, better would be to have good scaling so you could just
render one large mask. That improved scaling should appear in a future
release.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091008/fda20e54/attachment-0001.pgp 

From cworth at cworth.org  Thu Oct  8 11:48:12 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 08 Oct 2009 11:48:12 -0700
Subject: [cairo] Getting serious about making a cairo 1.10 release
In-Reply-To: <1254958398.16995.12.camel@moonglow>
References: <1254955092-sup-6757@yoom.home.cworth.org>
	<1254958398.16995.12.camel@moonglow>
Message-ID: <1255027543-sup-5255@yoom.home.cworth.org>

Excerpts from Andrew Cowie's message of Wed Oct 07 16:33:18 -0700 2009:
> On Wed, 2009-10-07 at 15:46 -0700, Carl Worth wrote:
> >     * Test cairo master or the latest cairo 1.9.x snapshot
> 
> Does anyone know off-hand of a reliable Ubuntu .deb or Fedora .rpm of
> the Cairo 1.9.x snapshots?

We should be pushing these into Debian experimental, I think.

I was recently granted Debian Developer status, so it's even
technically possible for me to do this myself. I'll go talk, (starting
with this mail) to the current maintainer of the Debian packages of
cairo and see what he thinks. Dave?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091008/fbe23e0b/attachment.pgp 

From mike.shaver at gmail.com  Thu Oct  8 11:56:22 2009
From: mike.shaver at gmail.com (Mike Shaver)
Date: Thu, 8 Oct 2009 11:56:22 -0700
Subject: [cairo] Getting serious about making a cairo 1.10 release
In-Reply-To: <1254955092-sup-6757@yoom.home.cworth.org>
References: <1254955092-sup-6757@yoom.home.cworth.org>
Message-ID: <cc092ba00910081156q4e87618fl6a62295a1b0b509@mail.gmail.com>

On Wed, Oct 7, 2009 at 3:46 PM, Carl Worth <cworth at cworth.org> wrote:
> I'd also like to depend
> on a bug describing the firefox crash issue. (Chris is quite certain
> this is a bug in firefox, but even then, I'd like to see *that* fixed
> before we release cairo 1.10).

Do you know the bugzilla.mozilla.org bug number for this issue?  I'd
also like to see it fixed promptly.

Mike

From mikhailkozhevnikov at yandex.ru  Thu Oct  8 23:28:20 2009
From: mikhailkozhevnikov at yandex.ru (Kozhevnikov Mikhail)
Date: Fri, 09 Oct 2009 10:28:20 +0400
Subject: [cairo] cross-compiling on Linux for Windows
Message-ID: <57791255069700@webmail101.yandex.ru>

Hi All,

If anybody tried cross-compiling cairo Windows binaries on Linux?

Thanks,
Mikhail.

From mikhailkozhevnikov at yandex.ru  Thu Oct  8 23:24:40 2009
From: mikhailkozhevnikov at yandex.ru (Kozhevnikov Mikhail)
Date: Fri, 09 Oct 2009 10:24:40 +0400
Subject: [cairo] building pixman 0.16.2 with MinGW
In-Reply-To: <Pine.OSF.4.61.0910082146270.63144@sirppi.helsinki.fi>
References: <119991254938580@webmail25.yandex.ru>
	<Pine.OSF.4.61.0910072207110.373417@sirppi.helsinki.fi>
	<40261255027048@webmail107.yandex.ru>
	<Pine.OSF.4.61.0910082146270.63144@sirppi.helsinki.fi>
Message-ID: <53581255069480@webmail101.yandex.ru>

Hi Joonas,

Performance is not critical in my case. And I do hope it will be fixed at some point.

-- Mikhail 

08.10.09, 22:47, "M Joonas Pihlaja" <jpihlaja at cc.helsinki.fi>:

> On Thu, 8 Oct 2009, Kozhevnikov Mikhail wrote:
> > I succeeded by disabling both sse2 and mmx. There's some naming 
> > conflict in the linker with the latter one. Thanks for suggestion!
> Eeek..  Please don't judge cairo's rendering speed based on a crippled 
> pixman!  :-O
> Joonas


From mpsuzuki at hiroshima-u.ac.jp  Thu Oct  8 23:42:40 2009
From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya)
Date: Fri, 09 Oct 2009 15:42:40 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <57791255069700@webmail101.yandex.ru>
References: <57791255069700@webmail101.yandex.ru>
Message-ID: <4ACEDB60.10004@hiroshima-u.ac.jp>

Hi,

Yet I've not tried to rebuild it, Fedora Core has
mingw32-cairo package. According to its source rpm,
the package is configured and built on GNU/Linux.

http://rpmfind.net//linux/RPM/fedora/devel/src/mingw32-cairo-1.8.8-1.fc12.src.html

Have you experience any troubles?

Kozhevnikov Mikhail wrote (2009/10/09 15:28):
> Hi All,
> 
> If anybody tried cross-compiling cairo Windows binaries on Linux?
> 
> Thanks,
> Mikhail.
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From tml at iki.fi  Fri Oct  9 01:54:37 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Fri, 9 Oct 2009 11:54:37 +0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <4ACEDB60.10004@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
Message-ID: <c9b6d9a50910090154j38d5ff00sba7473e4dc91f2f5@mail.gmail.com>

> Yet I've not tried to rebuild it, Fedora Core has mingw32-cairo package.

As has the openSUSE build service,
http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_10.3/noarch/mingw32-cairo-1.8.8-2.2.noarch.rpm
, sources, spec file, and patches (if any) in
http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_10.3/src/mingw32-cairo-1.8.8-2.2.src.rpm

--tml

From mikhailkozhevnikov at yandex.ru  Fri Oct  9 08:03:00 2009
From: mikhailkozhevnikov at yandex.ru (Kozhevnikov Mikhail)
Date: Fri, 09 Oct 2009 19:03:00 +0400
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <4ACEDB60.10004@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
Message-ID: <26751255100580@webmail106.yandex.ru>

Hi suzuki,

I've just tried cross-compiling windows binaries on Ubuntu with the script attached. It has built something, but libtool has given me some warnings:

*** Warning: This system can not link to static lib archive /home/qnan/Desktop/test/out/libpng/lib/libpng12.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: rm -fr .libs/libcairo.a .libs/libcairo.la .libs/libcairo.lai

*** Warning: linker path does not have real file for library -lgdi32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgdi32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib//libgdi32.a

*** Warning: linker path does not have real file for library -lmsimg32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmsimg32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib//libmsimg32.a

*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/qnan/Desktop/test/out/zlib/lib/libz.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

I have no idea why could libtool not accept these libraries. It's clear that it does check the files built, though. I'll try further.

There's also a trouble with pkg-config finding some libraries for which I only have Linux binaries installed. That is why all these --enable-xxx=no options in cairo configure.

Best regards,
Mikhail. 

09.10.09, 10:42, "suzuki toshiya" <mpsuzuki at hiroshima-u.ac.jp>:

> Hi,
> Yet I've not tried to rebuild it, Fedora Core has
> mingw32-cairo package. According to its source rpm,
> the package is configured and built on GNU/Linux.
> http://rpmfind.net//linux/RPM/fedora/devel/src/mingw32-cairo-1.8.8-1.fc12.src.html
> Have you experience any troubles?
> Kozhevnikov Mikhail wrote (2009/10/09 15:28):
> > Hi All,
> > 
> > If anybody tried cross-compiling cairo Windows binaries on Linux?
> > 
> > Thanks,
> > Mikhail.
> > _______________________________________________
> > cairo mailing list
> > cairo at cairographics.org
> > http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_mingw32.sh
Type: application/x-sh
Size: 1285 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091009/f991802a/attachment.sh 

From ml3p at onghu.com  Fri Oct  9 08:54:55 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Fri, 09 Oct 2009 23:54:55 +0800
Subject: [cairo] Problems with building Cairo for Windows CE
In-Reply-To: <4ACDD95E.4050006@onghu.com>
References: <4ACDD95E.4050006@onghu.com>
Message-ID: <4ACF5CCF.6070104@onghu.com>

Mohit Sindhwani wrote:
> Hello!  So, I managed to get the latest pixman to build and I have 
> binaries for zlibce and libpngce.
> I tried to follow the instructions at: 
> http://vividos.wordpress.com/2008/01/23/how-to-compile-cairo-for-pocketpc/ 
> but I'm using Cairo 1.8.8
>
> But, I do run into a few problems.  The main issues were with io.h, 
> errno.h and so on.  I stole seemingly relevant files from 
> https://ella.pragmaticomm.com/symbian-ruby/browser/trunk/wince which has 
> compatible files.
>
> Next on, I'm stuck at an error in building win32-surface.c - there seem 
> to be some errors related to the function:
> * _cairo_win32_save_initial_clip -> called from 
> _cairo_win32_surface_finish, _cairo_win32_surface_set_clip_region
>
> Compilation errors/ warnings include:
> 1>..\..\..\cairo\src\cairo-win32-surface.c(1543) : warning C4013: 
> 'ExtSelectClipRgn' undefined; assuming extern returning int
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2050) : warning C4013: 
> 'GetGraphicsMode' undefined; assuming extern returning int
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2051) : error C2065: 
> 'GM_ADVANCED' : undeclared identifier
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2052) : warning C4013: 
> 'GetWorldTransform' undefined; assuming extern returning int
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2053) : warning C4013: 
> 'ModifyWorldTransform' undefined; assuming extern returning int
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2053) : error C2065: 
> 'MWT_IDENTITY' : undeclared identifier
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2059) : warning C4013: 
> 'SetGraphicsMode' undefined; assuming extern returning int
> 1>..\..\..\cairo\src\cairo-win32-surface.c(2083) : warning C4013: 
> 'SetWorldTransform' undefined; assuming extern returning int
>
> These are new compared to 1.4.4 (the earlier build I had done), so I'm 
> wondering what to do.
>
> There are other errors, but these I have no idea what to do with (yet).
>   

Sorry guys to be a bit pushy, but any advice for me?

Thanks,
Mohit.


From tgriggs at cincom.com  Fri Oct  9 15:45:21 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Fri, 9 Oct 2009 15:45:21 -0700
Subject: [cairo] Compiling on old Linuxes
In-Reply-To: <7CFF99A6-FCF2-4065-90F9-DA765550B68D@cincom.com>
References: <7CFF99A6-FCF2-4065-90F9-DA765550B68D@cincom.com>
Message-ID: <D69F114A-01CA-410C-AAA2-61FD4201DFA8@cincom.com>

On Oct 8, 2009, at 10:58 AM, Travis Griggs wrote:

> Much thanks to those that have helped me get relocatable/distributable
> builds for both Windows and OSX, here or on the IRC channel.
>
> I'm now trying to get a build or Linux. I'm using the 1.9.2 snapshot.
> I had to comment out the check in configure about requiring a native
> font backend.


I did get some help with my last set of errors on irc. In particular,  
Carl said "But all you need here is headers from a library new enough  
to allow cairo to compile."

Which then leads me to ask will it run on that machine though? or is  
it that Cairo is smart enough to dynamically figure out how much of  
it's linked xrender support it can use?

Anyway, for now, I just decided to disable it. So I'm using

./configure --prefix=/pps/tgriggs/BuildCairo/ --disable-ft --disable- 
fc --disable-xlib-xrender

I have to modify cairo-xlib-screen to not include <FontConfig/ 
FontConfig.h>. And it appears to compile everything in cairo proper.  
But when it gets down into util/cairo-trace, it has issues. I've  
copied the error's below the sig. Is there anyway to easily avoid it  
even compiling the util stuff? I looked in ./configure --help, but  
don't see a --disable-util ability. I don't think I necessarily NEED  
the utils. Or perhaps there's a more refined make target I can use to  
just compile the library?

This is all on the 1.9.2 snapshot.

--
Travis Griggs
Objologist
"The project was so plagued by politics and ego that when the  
engineers requested technical oversight, our manager hired a  
psychologist instead." -- Ron Avitzur

   CC    trace.o
trace.c: In function `_type_release_token':
trace.c:193: `CHAR_BIT' undeclared (first use in this function)
trace.c:193: (Each undeclared identifier is reported only once
trace.c:193: for each function it appears in.)
trace.c:202: implicit declaration of function `free'
trace.c:194: warning: `bit' might be used uninitialized in this function
trace.c:194: warning: `elem' might be used uninitialized in this  
function
trace.c: In function `_type_next_token':
trace.c:222: `CHAR_BIT' undeclared (first use in this function)
trace.c: In function `_trace_vprintf':
trace.c:590: implicit declaration of function `va_arg'
trace.c:590: parse error before `int'
trace.c:592: parse error before `int'
trace.c:594: parse error before `int'
trace.c:603: parse error before `int'
trace.c:605: parse error before `long'
trace.c:608: parse error before `long'
trace.c:613: parse error before `const'
trace.c:617: parse error before `double'
trace.c:620: parse error before `int'
trace.c: In function `_trace_printf':
trace.c:638: implicit declaration of function `va_start'
trace.c:640: implicit declaration of function `va_end'
trace.c:636: warning: `ap' might be used uninitialized in this function
trace.c: In function `_init_logfile':
trace.c:687: implicit declaration of function `getenv'
trace.c:687: warning: assignment makes pointer from integer without a  
cast
trace.c:689: implicit declaration of function `atoi'
trace.c:692: warning: assignment makes pointer from integer without a  
cast
trace.c:697: warning: assignment makes pointer from integer without a  
cast
trace.c:701: warning: assignment makes pointer from integer without a  
cast
trace.c:713: warning: assignment makes pointer from integer without a  
cast
trace.c:717: warning: assignment makes pointer from integer without a  
cast
trace.c:742: implicit declaration of function `atexit'
trace.c: In function `_push_operand':
trace.c:902: implicit declaration of function `abort'
trace.c: In function `_emit_image':
trace.c:1406: warning: `ap' might be used uninitialized in this function
trace.c: In function `_emit_cairo_op':
trace.c:1713: warning: `ap' might be used uninitialized in this function
trace.c: In function `_emit_source_image':
trace.c:1893: warning: null format string
trace.c: In function `_emit_source_image_rectangle':
trace.c:1925: warning: null format string
trace.c: In function `cairo_image_surface_create_for_data':
trace.c:3054: warning: null format string
trace.c: In function `_emit_surface_op':
trace.c:3119: warning: `ap' might be used uninitialized in this function
trace.c: In function `_emit_pattern_op':
trace.c:3283: warning: `ap' might be used uninitialized in this function
trace.c: In function `cairo_image_surface_create_from_png_stream':
trace.c:3934: warning: null format string
trace.c: At top level:
trace.c:1023: warning: `_has_font_face_id' defined but not used
trace.c:1065: warning: `_get_pattern_id' defined but not used
trace.c:1688: warning: `_emit_font_face' defined but not used
trace.c:1700: warning: `_emit_scaled_font' defined but not used
make[4]: *** [cairo_trace_la-trace.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


From cworth at cworth.org  Fri Oct  9 17:04:38 2009
From: cworth at cworth.org (Carl Worth)
Date: Fri, 09 Oct 2009 17:04:38 -0700
Subject: [cairo] Compiling on old Linuxes
In-Reply-To: <D69F114A-01CA-410C-AAA2-61FD4201DFA8@cincom.com>
References: <7CFF99A6-FCF2-4065-90F9-DA765550B68D@cincom.com>
	<D69F114A-01CA-410C-AAA2-61FD4201DFA8@cincom.com>
Message-ID: <1255132807-sup-6896@yoom.home.cworth.org>

Excerpts from Travis Griggs's message of Fri Oct 09 15:45:21 -0700 2009:
> I did get some help with my last set of errors on irc. In particular,  
> Carl said "But all you need here is headers from a library new enough  
> to allow cairo to compile."
> 
> Which then leads me to ask will it run on that machine though? or is  
> it that Cairo is smart enough to dynamically figure out how much of  
> it's linked xrender support it can use?

Should work fine, yes.

Cairo asks the X server what version of the protocol it actually
supports, (independent of what version of the library cairo was
compiled against), and cairo then avoids using any Render requests
newer than supported. Of course, we could always have bugs in that,
but it *should* work, (and any such bugs would be fairly trivial to
fix).

> I have to modify cairo-xlib-screen to not include <FontConfig/ 
> FontConfig.h>. And it appears to compile everything in cairo proper.  
> But when it gets down into util/cairo-trace, it has issues. I've  
> copied the error's below the sig. Is there anyway to easily avoid it  
> even compiling the util stuff? I looked in ./configure --help, but  
> don't see a --disable-util ability. I don't think I necessarily NEED  
> the utils. Or perhaps there's a more refined make target I can use to  
> just compile the library?

Easiest thing to do would be to just hack Makefile.am to not compile
the util libary. You definitely don't need any of that to link an
application against cairo. (Or, even easier would be to just run "make
-k" and ignore the failures, knowing that the library itself is
compiling fine.)

But, yes, the next step would be to add a configure option to avoid
compiling these chunks you don't need. Or, just fix the bugs
below. Best would be to have this code automatically disabled if it
detects that something isn't present that cairo-trace needs.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091009/a7dae141/attachment.pgp 

From jody at gnome.org  Fri Oct  9 17:04:50 2009
From: jody at gnome.org (Jody Goldberg)
Date: Fri, 9 Oct 2009 20:04:50 -0400
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <57791255069700@webmail101.yandex.ru>
References: <57791255069700@webmail101.yandex.ru>
Message-ID: <20091010000450.GA7315@thegoldbergs.ca>

On Fri, Oct 09, 2009 at 10:28:20AM +0400, Kozhevnikov Mikhail wrote:
> Hi All,
> 
> If anybody tried cross-compiling cairo Windows binaries on Linux?

Gnumeric has a jhbuild based cross compilation script that includes
cairo.

From zweinberg at mozilla.com  Fri Oct  9 17:13:23 2009
From: zweinberg at mozilla.com (Zack Weinberg)
Date: Fri, 9 Oct 2009 17:13:23 -0700
Subject: [cairo] Compiling on old Linuxes
In-Reply-To: <1255132807-sup-6896@yoom.home.cworth.org>
References: <7CFF99A6-FCF2-4065-90F9-DA765550B68D@cincom.com>
	<D69F114A-01CA-410C-AAA2-61FD4201DFA8@cincom.com>
	<1255132807-sup-6896@yoom.home.cworth.org>
Message-ID: <20091009171323.7075685b@trurl>

Carl Worth <cworth at cworth.org> wrote:
> 
> Cairo asks the X server what version of the protocol it actually
> supports, (independent of what version of the library cairo was
> compiled against), and cairo then avoids using any Render requests
> newer than supported. Of course, we could always have bugs in that,
> but it *should* work, (and any such bugs would be fairly trivial to
> fix).

That turns out not to be the case... for instance, we're still looking
for a good solution to
https://bugzilla.mozilla.org/show_bug.cgi?id=468496#c11
(the actual bug is in the X video drivers, and Render can't tell Cairo
whether it's using one of the buggy ones)

zw


From cworth at cworth.org  Fri Oct  9 20:17:03 2009
From: cworth at cworth.org (Carl Worth)
Date: Fri, 09 Oct 2009 20:17:03 -0700
Subject: [cairo] Compiling on old Linuxes
In-Reply-To: <20091009171323.7075685b@trurl>
References: <7CFF99A6-FCF2-4065-90F9-DA765550B68D@cincom.com>
	<D69F114A-01CA-410C-AAA2-61FD4201DFA8@cincom.com>
	<1255132807-sup-6896@yoom.home.cworth.org>
	<20091009171323.7075685b@trurl>
Message-ID: <1255144338-sup-3554@yoom.home.cworth.org>

Excerpts from Zack Weinberg's message of Fri Oct 09 17:13:23 -0700 2009:
> > Cairo asks the X server what version of the protocol it actually
> > supports, (independent of what version of the library cairo was
> > compiled against), and cairo then avoids using any Render requests
> > newer than supported. Of course, we could always have bugs in that,
> > but it *should* work, (and any such bugs would be fairly trivial to
> > fix).
> 
> That turns out not to be the case... for instance, we're still looking
> for a good solution to
> https://bugzilla.mozilla.org/show_bug.cgi?id=468496#c11
> (the actual bug is in the X video drivers, and Render can't tell Cairo
> whether it's using one of the buggy ones)

Right. I was only talking about distinguishing between different
implementations of the Render extension advertising different numeric
versions of the specification.

Distinguishing between implementations that may or may not have bugs
is of course much harder, (since nothing about the numeric version of
the specification says whether there might be bugs in the
implementation).

You can see lots of pain that's gone into cairo trying to work around
bugs like these. Just grep for "buggy" within cairo-xlib-surface.c to
see some evidence of this.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091009/7b154398/attachment.pgp 

From mpsuzuki at hiroshima-u.ac.jp  Sat Oct 10 02:25:33 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Sat, 10 Oct 2009 18:25:33 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <26751255100580@webmail106.yandex.ru>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
	<26751255100580@webmail106.yandex.ru>
Message-ID: <20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>

Hi,

Maybe your script builds static zlib library (libz.a) directly,
and libtool of libpng, pixman and cairo could not write info
to track the shared library dependency into libpng.la,
libpixman.la and libcairo.la. If I disable shared library when
libpng is configured, the warnings you got will disappear. But,
DLL of cairo is either disabled.

To solve the problem, full GNU autotoolization of zlib is
expected. In the case of Fedora Core, a patched win32/Makefile
is used to build static & shared zlib, without GNU libtool.

If anybody (in cairo list) knows the patch to autotoolize zlib,
please let me know.

Regards,
mpsuzuki

On Fri, 09 Oct 2009 19:03:00 +0400
Kozhevnikov Mikhail <mikhailkozhevnikov at yandex.ru> wrote:

>Hi suzuki,
>
>I've just tried cross-compiling windows binaries on Ubuntu with the script attached. It has built something, but libtool has given me some warnings:
>
>*** Warning: This system can not link to static lib archive /home/qnan/Desktop/test/out/libpng/lib/libpng12.la.
>*** I have the capability to make that library automatically link in when
>*** you link to this library. But I can only do this if you have a
>*** shared version of the library, which you do not appear to have.
>libtool: link: rm -fr .libs/libcairo.a .libs/libcairo.la .libs/libcairo.lai
>
>*** Warning: linker path does not have real file for library -lgdi32.
>*** I have the capability to make that library automatically link in when
>*** you link to this library. But I can only do this if you have a
>*** shared version of the library, which you do not appear to have
>*** because I did check the linker path looking for a file starting
>*** with libgdi32 and none of the candidates passed a file format test
>*** using a file magic. Last file checked: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib//libgdi32.a
>
>*** Warning: linker path does not have real file for library -lmsimg32.
>*** I have the capability to make that library automatically link in when
>*** you link to this library. But I can only do this if you have a
>*** shared version of the library, which you do not appear to have
>*** because I did check the linker path looking for a file starting
>*** with libmsimg32 and none of the candidates passed a file format test
>*** using a file magic. Last file checked: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib//libmsimg32.a
>
>*** Warning: linker path does not have real file for library -lz.
>*** I have the capability to make that library automatically link in when
>*** you link to this library. But I can only do this if you have a
>*** shared version of the library, which you do not appear to have
>*** because I did check the linker path looking for a file starting
>*** with libz and none of the candidates passed a file format test
>*** using a file magic. Last file checked: /home/qnan/Desktop/test/out/zlib/lib/libz.a
>*** The inter-library dependencies that have been dropped here will be
>*** automatically added whenever a program is linked with this library
>*** or is declared to -dlopen it.
>
>*** Since this library must not contain undefined symbols,
>*** because either the platform does not support them or
>*** it was explicitly requested with -no-undefined,
>*** libtool will only create a static version of it.
>
>I have no idea why could libtool not accept these libraries. It's clear that it does check the files built, though. I'll try further.
>
>There's also a trouble with pkg-config finding some libraries for which I only have Linux binaries installed. That is why all these --enable-xxx=no options in cairo configure.
>
>Best regards,
>Mikhail. 
>
>09.10.09, 10:42, "suzuki toshiya" <mpsuzuki at hiroshima-u.ac.jp>:
>
>> Hi,
>> Yet I've not tried to rebuild it, Fedora Core has
>> mingw32-cairo package. According to its source rpm,
>> the package is configured and built on GNU/Linux.
>> http://rpmfind.net//linux/RPM/fedora/devel/src/mingw32-cairo-1.8.8-1.fc12.src.html
>> Have you experience any troubles?
>> Kozhevnikov Mikhail wrote (2009/10/09 15:28):
>> > Hi All,
>> > 
>> > If anybody tried cross-compiling cairo Windows binaries on Linux?
>> > 
>> > Thanks,
>> > Mikhail.
>> > _______________________________________________
>> > cairo mailing list
>> > cairo at cairographics.org
>> > http://lists.cairographics.org/mailman/listinfo/cairo

From tgriggs at cincom.com  Sat Oct 10 14:44:44 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Sat, 10 Oct 2009 14:44:44 -0700
Subject: [cairo] Building on Solaris
Message-ID: <F3D32F3D-F984-4F9C-9BC8-C4F626EB64AF@cincom.com>

Subject pretty much asks it all. I've got an old Sun box I need to  
build for. I'm no guru at this stuff. I found I didn't even have a  
'make' in my path; I've remedied that by downloading and building it  
(interesting meta problem, how do you 'make make without make'). It  
appears to be operational. Now I'm trying to get pkg-config built,  
it's got errors. Maybe I'll share those in a bit, but more generally,  
has anyone built CairoGraphics on Solaris, and would be wiling to  
share the recipe, in as much detail as possible, with me?

TIA

--
Travis Griggs
Objologist
10 2 letter words: "If it is to be, it is up to me"



From stonemcclane at gmail.com  Sat Oct 10 17:16:58 2009
From: stonemcclane at gmail.com (stoneMcClane)
Date: Sun, 11 Oct 2009 02:16:58 +0200
Subject: [cairo] cairo issues, empty output
Message-ID: <41b2dd910910101716p7ae949ckcda480aace2bb8a6@mail.gmail.com>

Hi all,
Today I digged out one of my old projects which makes use of cairo. It
used to work fine all the time, but now that I tried to compile it
again, cairo doesn't behave the way that I was expecting.
I got the binary+dev files from
http://www.gtk.org/download-windows.html , I also tried older versions
of cairo, but the behaviour was the same.

My application reads vector graphic specifications from files and
renders them automatically using cairo, therefore I placed appropriate
"printf"s to reconstruct the code that isn't working.

mSurface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 256, 128);
cairo_create(mSurface);
cairo_set_fill_rule(CAIRO_FILL_RULE_EVEN_ODD);

cairo_set_source_rgba(1, 0, 0, 1);

cairo_move_to(0.00, 0.00);
cairo_line_to(256.00, 0.00);
cairo_line_to(256.00, 128.00);
cairo_line_to(0.00, 128.00);
cairo_line_to(0.00, 0.00);

cairo_new_sub_path();

cairo_move_to(53.82, 27.43);
cairo_line_to(217.03, 27.43);
cairo_line_to(217.03, 97.96);
cairo_line_to(53.82, 97.96);
cairo_line_to(53.82, 27.43);

cairo_close_path();
cairo_fill();

cairo_set_source_rgba(0, 0, 1, 1);

cairo_move_to(53.82, 27.43);
cairo_line_to(217.03, 27.43);
cairo_line_to(217.03, 97.96);
cairo_line_to(53.82, 97.96);
cairo_line_to(53.82, 27.43);

cairo_close_path();
cairo_fill();

(I left out the mCairo variable, since it doesn't add to clarity of the code)

after these operations have finished I call
"cairo_image_surface_get_data" and write the buffer to an image file.
With the above code, the image is empty, meaning rgba(0,0,0,0) over
the full image.
However, if I add...

cairo_set_source_rgba(1, 0, 0, 1);
cairo_paint();

right before writing the buffer to the image file, I get a fully red
image, just like what you would expect, so I'm really puzzled what
could be wrong here.
Like said, this code used to work some months ago when I wrote it, but
now it doesn't draw anything at all.
I've changed from WinXP to Win7 since I last worked with this code,
could there be any issues with this ?
(yeah I've got the correct cairo binary version for my system, namely 32-bit)

As said, I'm really on a dead end here, and I've debugged this already
quite some time, without any solution.
I'd really appreciate it, if someone had an idea what could be wrong.

Thanks in advance,
sincerly, Wolfgang Steiner

From stonemcclane at gmail.com  Sat Oct 10 18:48:55 2009
From: stonemcclane at gmail.com (stoneMcClane)
Date: Sun, 11 Oct 2009 03:48:55 +0200
Subject: [cairo] cairo issues, empty output
In-Reply-To: <41b2dd910910101716p7ae949ckcda480aace2bb8a6@mail.gmail.com>
References: <41b2dd910910101716p7ae949ckcda480aace2bb8a6@mail.gmail.com>
Message-ID: <41b2dd910910101848j7368147aw21b217d22d9e2b96@mail.gmail.com>

I think I traced the bug down, in fact it's got nothing to do with
cairo itself as it seems.
It's more likely the combination with directx causing the bug.
I'm really sorry for this unnecessary thread, but I was pulling my
hair out after hours of debugging.

Cheers

From tgriggs at cincom.com  Sat Oct 10 19:02:34 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Sat, 10 Oct 2009 19:02:34 -0700
Subject: [cairo] cairo issues, empty output
In-Reply-To: <41b2dd910910101848j7368147aw21b217d22d9e2b96@mail.gmail.com>
References: <41b2dd910910101716p7ae949ckcda480aace2bb8a6@mail.gmail.com>
	<41b2dd910910101848j7368147aw21b217d22d9e2b96@mail.gmail.com>
Message-ID: <BB405DC8-F204-46E7-AE4E-8C09B248DA34@cincom.com>


On Oct 10, 2009, at 6:48 PM, stoneMcClane wrote:

> I think I traced the bug down, in fact it's got nothing to do with
> cairo itself as it seems.
> It's more likely the combination with directx causing the bug.
> I'm really sorry for this unnecessary thread, but I was pulling my
> hair out after hours of debugging.

No prob. See sig quote. :)

--
Travis Griggs
Objologist
"An idea, like a ghost, must be spoken to a little before it will  
explain itself." - Charles Dickens


From mpsuzuki at hiroshima-u.ac.jp  Sun Oct 11 00:19:09 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Sun, 11 Oct 2009 16:19:09 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>

Hi,

Just I've written a preliminary addon to autotoolize
zlib-1.2.3.

It can be used as:

$ tar xfz zlib-1.2.3.tar.gz
$ lzma -cd < zlib-1.2.3_addon-skel.tar.lzma | tar xf-
$ cd zlib-1.2.3/gnu-auto
$ sh ./autogen.sh
$ ./configure --host=i586-mswin32msvc --build=i386-pc-linux-gnu

# To avoid overwriting the genuine configure of zlib,
# I dig a subdirectory zlib-1.2.3/gnu-auto, and
# everything goes there. Using & building with autotool
# should be executed in zlib-1.2.3/gnu-auto, not
# zlib-1.2.3.

I also attached modified building script and its output.
You can find that libz.dll.a is built without special
technique. Also libtool warning about the dependency
tracking info is not found.

To reduce the size of attachment, addon-skel.tar.lzma
includes only 2 skeltons: Makefile.am & configure.ac.in,
and a script autogen.sh to generate autotool scripts.
No ready-to-use configure is included. For the people
who don't believe libtoolize/aclocal/automake/autoconf
on their systems, I uploaded large tarball including
ready-to-use configure.

https://sourceforge.net/projects/ttf2ttc/files/zlib-1.2.3_addon.tar.lzma/download

It can be used as:

$ tar xfz zlib-1.2.3.tar.gz
$ lzma -cd < zlib-1.2.3_addon.tar.lzma | tar xf-
$ cd zlib-1.2.3/gnu-auto
$ ./configure --host=i586-mswin32msvc --build=i386-pc-linux-gnu

I wish you can build Win32 DLL of zlib.

Regards,
mpsuzuki

On Sat, 10 Oct 2009 18:25:33 +0900
mpsuzuki at hiroshima-u.ac.jp wrote:

>Hi,
>
>Maybe your script builds static zlib library (libz.a) directly,
>and libtool of libpng, pixman and cairo could not write info
>to track the shared library dependency into libpng.la,
>libpixman.la and libcairo.la. If I disable shared library when
>libpng is configured, the warnings you got will disappear. But,
>DLL of cairo is either disabled.
>
>To solve the problem, full GNU autotoolization of zlib is
>expected. In the case of Fedora Core, a patched win32/Makefile
>is used to build static & shared zlib, without GNU libtool.
>
>If anybody (in cairo list) knows the patch to autotoolize zlib,
>please let me know.
>
>Regards,
>mpsuzuki
>
>On Fri, 09 Oct 2009 19:03:00 +0400
>Kozhevnikov Mikhail <mikhailkozhevnikov at yandex.ru> wrote:
>
>>Hi suzuki,
>>
>>I've just tried cross-compiling windows binaries on Ubuntu with the script attached. It has built something, but libtool has given me some warnings:
>>
>>*** Warning: This system can not link to static lib archive /home/qnan/Desktop/test/out/libpng/lib/libpng12.la.
>>*** I have the capability to make that library automatically link in when
>>*** you link to this library. But I can only do this if you have a
>>*** shared version of the library, which you do not appear to have.
>>libtool: link: rm -fr .libs/libcairo.a .libs/libcairo.la .libs/libcairo.lai
>>
>>*** Warning: linker path does not have real file for library -lgdi32.
>>*** I have the capability to make that library automatically link in when
>>*** you link to this library. But I can only do this if you have a
>>*** shared version of the library, which you do not appear to have
>>*** because I did check the linker path looking for a file starting
>>*** with libgdi32 and none of the candidates passed a file format test
>>*** using a file magic. Last file checked: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib//libgdi32.a
>>
>>*** Warning: linker path does not have real file for library -lmsimg32.
>>*** I have the capability to make that library automatically link in when
>>*** you link to this library. But I can only do this if you have a
>>*** shared version of the library, which you do not appear to have
>>*** because I did check the linker path looking for a file starting
>>*** with libmsimg32 and none of the candidates passed a file format test
>>*** using a file magic. Last file checked: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib//libmsimg32.a
>>
>>*** Warning: linker path does not have real file for library -lz.
>>*** I have the capability to make that library automatically link in when
>>*** you link to this library. But I can only do this if you have a
>>*** shared version of the library, which you do not appear to have
>>*** because I did check the linker path looking for a file starting
>>*** with libz and none of the candidates passed a file format test
>>*** using a file magic. Last file checked: /home/qnan/Desktop/test/out/zlib/lib/libz.a
>>*** The inter-library dependencies that have been dropped here will be
>>*** automatically added whenever a program is linked with this library
>>*** or is declared to -dlopen it.
>>
>>*** Since this library must not contain undefined symbols,
>>*** because either the platform does not support them or
>>*** it was explicitly requested with -no-undefined,
>>*** libtool will only create a static version of it.
>>
>>I have no idea why could libtool not accept these libraries. It's clear that it does check the files built, though. I'll try further.
>>
>>There's also a trouble with pkg-config finding some libraries for which I only have Linux binaries installed. That is why all these --enable-xxx=no options in cairo configure.
>>
>>Best regards,
>>Mikhail. 
>>
>>09.10.09, 10:42, "suzuki toshiya" <mpsuzuki at hiroshima-u.ac.jp>:
>>
>>> Hi,
>>> Yet I've not tried to rebuild it, Fedora Core has
>>> mingw32-cairo package. According to its source rpm,
>>> the package is configured and built on GNU/Linux.
>>> http://rpmfind.net//linux/RPM/fedora/devel/src/mingw32-cairo-1.8.8-1.fc12.src.html
>>> Have you experience any troubles?
>>> Kozhevnikov Mikhail wrote (2009/10/09 15:28):
>>> > Hi All,
>>> > 
>>> > If anybody tried cross-compiling cairo Windows binaries on Linux?
>>> > 
>>> > Thanks,
>>> > Mikhail.
>>> > _______________________________________________
>>> > cairo mailing list
>>> > cairo at cairographics.org
>>> > http://lists.cairographics.org/mailman/listinfo/cairo
>_______________________________________________
>cairo mailing list
>cairo at cairographics.org
>http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib-1.2.3_addon-skel.tar.lzma
Type: application/octet-stream
Size: 2108 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091011/7a1305a4/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_mingw32.sh.lzma
Type: application/octet-stream
Size: 561 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091011/7a1305a4/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_mingw32.log.lzma
Type: application/octet-stream
Size: 18545 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091011/7a1305a4/attachment-0005.obj 

From tml at iki.fi  Sun Oct 11 00:42:03 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Sun, 11 Oct 2009 10:42:03 +0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp> 
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp> 
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>

> I wish you can build Win32 DLL of zlib.

Of course, it's a bit sad that people have to try so hard to build
zlib themselves, when zlib is one of the few open source libraries
that have an official DLL right on its upstream website... which is
up-to-date and works fine, zlib hasn't changed in years. Why can't
libraries like zlib be considered part of the existing infrastructure,
just like it is on Linux? (Yeah, I know, it's not provided as part of
the operating system, or from the OS vendor through something that
would correspond to Linux package management.)

--tml

From mpsuzuki at hiroshima-u.ac.jp  Sun Oct 11 01:05:39 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Sun, 11 Oct 2009 17:05:39 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
Message-ID: <20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>

On Sun, 11 Oct 2009 10:42:03 +0300
Tor Lillqvist <tml at iki.fi> wrote:

>> I wish you can build Win32 DLL of zlib.
>
>Of course, it's a bit sad that people have to try so hard to build
>zlib themselves, when zlib is one of the few open source libraries
>that have an official DLL right on its upstream website... which is
>up-to-date and works fine, zlib hasn't changed in years.

Umm, I guess, one of the reason why the people builds
zlib DLL from source instead of using prebuilt official
zlib DLL binary, would be the library naming convention.

In most Unix systems, built zlib is named as libz.XXX.
And, many configure scripts developed on Unix search
zlib by testing linker flag "-lz". But, official zlib
DLL has different naming convention: there are zdll.exp,
zdll.lib, zlib1.dll. So, configure script looking for
libz.XXX cannot detect them. Is it expected to write
autoconf macro that can find these DLL under different
naming convention?

Regards,
mpsuzuki

From tml at iki.fi  Sun Oct 11 01:11:57 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Sun, 11 Oct 2009 11:11:57 +0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp> 
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp> 
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com> 
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com>

> So, configure script looking for
> libz.XXX cannot detect them.

So, which one is easier, rebuilding the library, or renaming or
copying an *import* library (still having it refer to the DLL named as
in its upstream, zlib1.dll)?

--tml

From behdad at behdad.org  Sun Oct 11 01:05:44 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sun, 11 Oct 2009 01:05:44 -0700
Subject: [cairo] Subpixel Positioning w/FreeType
In-Reply-To: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
References: <1E174A9E-38F3-438C-B3AF-8352154934DD@witherden.org>
Message-ID: <4AD191D8.1030604@behdad.org>

Hi Freddie,

Adding subpixel positioning support is indeed in my longterm plan for cairo. I 
have discussed it before on the list.  But I'm by no way close to making a 
firm commitment to a deadline right now.

Cheers,
behdad

On 10/06/2009 12:58 PM, Freddie Witherden wrote:
> Hi all,
>
> I am wondering about any current or future proposals for supporting
> subpixel positioning with FreeType. Subpixel positioning -- not to be
> confused with subpixel rendering/anti-aliasing -- allows for more
> accurate glyph positioning.
>
> Much like subpixel rendering, subpixel positioning takes advantage of
> the fact that LCD screens are made up of three subpixels in a specific
> order. This order is usually RGB. The predictable subpixel order
> allows for three times the horizontal resolution. The same technique
> can be applied to glyph positions. Instead of having to start on a
> pixel boundary glyphs are instead able to start on a subpixel
> boundary. This allows for spacing accurate to 1/3 of a pixel in most
> cases.
>
> It is my understanding (from looking over the source) that Cairo does
> not currently support subpixel positing under FreeType. Further, I
> also understand that the FreeType code has been recently re-written
> (there was a note on the 1.10 roadmap) to take advantage of the
> subpixel filtering API exported by FreeType.
>
> I believe that basic, 1/3 of a pixel, subpixel positing could be
> implemented in Cairo without a huge amount of work. It would of course
> only be applicable when subpixel rendering is enabled. Since Cairo and
> Pango both already use fractional co-ordinates this should not break
> backwards compatibility.
>
> Both Quartz (OS X) and ClearType (Windows) support this already.
>
> Polemically yours, Freddie.
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>

From mpsuzuki at hiroshima-u.ac.jp  Sun Oct 11 01:21:25 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Sun, 11 Oct 2009 17:21:25 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com>
Message-ID: <20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>

On Sun, 11 Oct 2009 11:11:57 +0300
Tor Lillqvist <tml at iki.fi> wrote:

>> So, configure script looking for
>> libz.XXX cannot detect them.
>
>So, which one is easier, rebuilding the library, or renaming or
>copying an *import* library (still having it refer to the DLL named as
>in its upstream, zlib1.dll)?

I don't know if Windows DLL has any record of its name
in the binary, but if I copy zlib1.dll to libz.dll.a
(and zlib.dll to libz.a), most configure of libpng finds
it correctly, and libpng is built without warning.

OK, I will stop to promote self building of zlib.
Thank you!

Regards,
mpsuzuki


From tml at iki.fi  Sun Oct 11 05:39:14 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Sun, 11 Oct 2009 15:39:14 +0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp> 
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp> 
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com> 
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com> 
	<20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <c9b6d9a50910110539t13283a76wfbdafb5f59f8b7b2@mail.gmail.com>

> I don't know if Windows DLL has any record of its name
> in the binary,

I don't think so, but still I recommend against renaming DLLs.

> but if I copy zlib1.dll to libz.dll.a
> (and zlib.dll to libz.a),

That sounds quite a bit confusing. Copying a dll into a .dll.a, which
is one naming convention for import libraries, does not make sense.
Did you mistype? If not, what you did most probably worked just by
accident. There is a huge difference between a DLL and an import
library referring to it.

What I meant was just to copy the import library you have, whatever it
might be called, to such a name so that your mingw GNU ld will find it
when you specify -lz , which I think was what you wanted? I.e.,
libz.dll.a or libz.a. Copying or renaming the DLL itself is wrong as
the import library (whatever the name of the import library) refers to
the DLL under its original name.

--tml

From mpsuzuki at hiroshima-u.ac.jp  Sun Oct 11 06:47:56 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Sun, 11 Oct 2009 22:47:56 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <c9b6d9a50910110539t13283a76wfbdafb5f59f8b7b2@mail.gmail.com>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com>
	<20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110539t13283a76wfbdafb5f59f8b7b2@mail.gmail.com>
Message-ID: <20091011224756.7387ae6a.mpsuzuki@hiroshima-u.ac.jp>

Hi,

I'm sorry for posting about Win32 DLL,
not about cairo but about zlib.

On Sun, 11 Oct 2009 15:39:14 +0300
Tor Lillqvist <tml at iki.fi> wrote:

>> I don't know if Windows DLL has any record of its name
>> in the binary,
>
>I don't think so, but still I recommend against renaming DLLs.
>
>> but if I copy zlib1.dll to libz.dll.a
>> (and zlib.dll to libz.a),
>
>That sounds quite a bit confusing. Copying a dll into a .dll.a, which
>is one naming convention for import libraries, does not make sense.
>Did you mistype?

I'm sorry, I mistyped. zlib1.dll to libz.dll,
and zlib.lib to libz.a.

>What I meant was just to copy the import library you have, whatever it
>might be called, to such a name so that your mingw GNU ld will find it
>when you specify -lz , which I think was what you wanted? I.e.,
>libz.dll.a or libz.a. Copying or renaming the DLL itself is wrong as
>the import library (whatever the name of the import library) refers to
>the DLL under its original name.

When I execute "i586-mingw32msvc-objdump -p libz.dll",
I can find such line:

Name                            000000000000f416 zlib1.dll

And, from libpng12-0.dll built with renamed DLL,
I can find such line in the output of objdump

 00027028       000270d0 00000000 00000000 00027448 00027178

        DLL Name: zlib1.dll
        vma:  Hint/Ord Member-Name Bound-To
        2731c       4  crc32
        27324       5  deflate
        27330       8  deflateEnd
        27340       9  deflateInit2_
        27350      13  deflateReset
        27360      35  inflate
        2736c      40  inflateEnd
        2737c      42  inflateInit_
        2738c      43  inflateReset

So, now I think I SHOULD copy or symlink DLL to
the names that the linker can resolves, and I
MUST NOT rename DLL, because runtime dynamic loader
cannot find the required DLL. Am I understanding correctly?

Regards,
mpsuzuki

From tml at iki.fi  Sun Oct 11 07:17:52 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Sun, 11 Oct 2009 17:17:52 +0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <20091011224756.7387ae6a.mpsuzuki@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<26751255100580@webmail106.yandex.ru> 
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp> 
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com> 
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com> 
	<20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110539t13283a76wfbdafb5f59f8b7b2@mail.gmail.com> 
	<20091011224756.7387ae6a.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <c9b6d9a50910110717i1af16297jfdb9fec4d9b3a9f9@mail.gmail.com>

This is getting quite confusing now and I am sorry I entered this
discussion. Let me just restate the facts:

- the name for the zlib DLL that its official site distributes is
zlib1.dll. (Their build is then redistributed by me from the
ftp.gnome.org/download.gnome.org site.)

- an import library for the zlib DLL should be called either libz.a or
libz.dll.a if you want it to be found by mingw ld using the option -lz
. (I am leaving out some other combinations; read the ld documentation
for completeness.)

- there doesn't have to be any direct relation between the name of an
import library and the name of the DLL that the import stubs in the
import library refer to. (Although in most cases, including those
where libtool takes care of naming the DLL and import library, there
of course is a consistent pattern.) (Mingw ld also knows to
automatically generate import stubs on the fly if you mention a DLL on
the command line, but I generally don't take advantage of that
feature.)

--tml

From mpsuzuki at hiroshima-u.ac.jp  Sun Oct 11 07:28:36 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Sun, 11 Oct 2009 23:28:36 +0900
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <c9b6d9a50910110717i1af16297jfdb9fec4d9b3a9f9@mail.gmail.com>
References: <57791255069700@webmail101.yandex.ru>
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com>
	<20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110539t13283a76wfbdafb5f59f8b7b2@mail.gmail.com>
	<20091011224756.7387ae6a.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110717i1af16297jfdb9fec4d9b3a9f9@mail.gmail.com>
Message-ID: <20091011232836.150b6421.mpsuzuki@hiroshima-u.ac.jp>

On Sun, 11 Oct 2009 17:17:52 +0300
Tor Lillqvist <tml at iki.fi> wrote:
>- an import library for the zlib DLL should be called either libz.a or
>libz.dll.a if you want it to be found by mingw ld using the option -lz
>. (I am leaving out some other combinations; read the ld documentation
>for completeness.)

Anybody distributes import library to link
official zlib1.dll by mingw ld?

Regards,
mpsuzuki

From taoufik.dachraoui at wanadoo.fr  Sun Oct 11 07:47:42 2009
From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui)
Date: Sun, 11 Oct 2009 16:47:42 +0200
Subject: [cairo] cl-cairo with X11 examples with mouse events handling
Message-ID: <A4E2F14C-6B28-4D63-8C5E-202EFD2EE6FF@wanadoo.fr>

Dear,

I am new to cl-cairo2 and would like to know how to write an X11  
application using CL-CAIRO2

I installed cl-cairo2 on openmcl (Clozure CL) and run the tests (e.g  
tutorial/x11-example.lisp)

The X11 tests works fine but I could not figure out how to use and  
handle mouse events (e.g. button-press, exposure,...)

I will appreciate if someone can send me an example of how to create a  
X11 window and to define lisp functions to handle mouse and keyboard  
events.

I prefer to use X window with cairo and not GTK with cairo.

Kind regards
Taoufik






From tml at iki.fi  Sun Oct 11 07:50:00 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Sun, 11 Oct 2009 17:50:00 +0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <20091011232836.150b6421.mpsuzuki@hiroshima-u.ac.jp>
References: <57791255069700@webmail101.yandex.ru>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp> 
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com> 
	<20091011170539.5d1d883d.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110111kdc00e80yb4f464630dbb2da2@mail.gmail.com> 
	<20091011172125.78223b22.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110539t13283a76wfbdafb5f59f8b7b2@mail.gmail.com> 
	<20091011224756.7387ae6a.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110717i1af16297jfdb9fec4d9b3a9f9@mail.gmail.com> 
	<20091011232836.150b6421.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <c9b6d9a50910110750k211f3c76p94a574ba8dedf426@mail.gmail.com>

> Anybody distributes import library to link
> official zlib1.dll by mingw ld?

http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/zlib-dev-1.2.3.zip

--tml

From danielko.listas at gmail.com  Sun Oct 11 15:54:42 2009
From: danielko.listas at gmail.com (Daniel K. O.)
Date: Sun, 11 Oct 2009 19:54:42 -0300
Subject: [cairo] cross-compiling on Linux for Windows
In-Reply-To: <c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
References: <57791255069700@webmail101.yandex.ru>
	<4ACEDB60.10004@hiroshima-u.ac.jp>
	<26751255100580@webmail106.yandex.ru>
	<20091010182533.02efd43d.mpsuzuki@hiroshima-u.ac.jp>
	<20091011161909.639bb43e.mpsuzuki@hiroshima-u.ac.jp>
	<c9b6d9a50910110042xf98faafk294f8e9145ca573a@mail.gmail.com>
Message-ID: <a3070a8c0910111554s2d5ec05cl52b87d13710ddea5@mail.gmail.com>

2009/10/11 Tor Lillqvist <tml at iki.fi>:
> Of course, it's a bit sad that people have to try so hard to build
> zlib themselves, when zlib is one of the few open source libraries
> that have an official DLL right on its upstream website... which is
> up-to-date and works fine, zlib hasn't changed in years. Why can't
> libraries like zlib be considered part of the existing infrastructure,
> just like it is on Linux? (Yeah, I know, it's not provided as part of
> the operating system, or from the OS vendor through something that
> would correspond to Linux package management.)

As a side note, I had to build zlib myself yesterday, on a 32-bit
GNU/Linux system (Mandriva), because by default it is compiled with
32-bit file offsets (and my program was failing to gzseek with +4 GB
files). I wish it had the autoconf magic to enable large files like
almost everything else. So much for being part of the
infrastructure...


-- 
Daniel K. O.
"The only way to succeed is to build success yourself"

From ml3p at onghu.com  Mon Oct 12 07:38:13 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Mon, 12 Oct 2009 22:38:13 +0800
Subject: [cairo] Problems with building Cairo for Windows CE
In-Reply-To: <4ACF5CCF.6070104@onghu.com>
References: <4ACDD95E.4050006@onghu.com> <4ACF5CCF.6070104@onghu.com>
Message-ID: <4AD33F55.5040709@onghu.com>

Mohit Sindhwani wrote:
> Mohit Sindhwani wrote:
>
> Next on, I'm stuck at an error in building win32-surface.c - there seem 
> to be some errors related to the function:
> * _cairo_win32_save_initial_clip -> called from 
> _cairo_win32_surface_finish, _cairo_win32_surface_set_clip_region
>   

Can anyone explain the function of the methods:
* cairo_int_status_t _cairo_win32_save_initial_clip (HDC hdc, 
cairo_win32_surface_t *surface)
* cairo_int_status_t _cairo_win32_restore_initial_clip 
(cairo_win32_surface_t *surface)

These throw up warning/ errors when compiling and eventually results in 
missing symbols when on Windows CE.  On the other hand, these were not 
there in 1.4.4.  These functions are called from:
1>_cairo_win32_restore_initial_clip referenced in function 
_cairo_win32_surface_finish
1>_cairo_win32_save_initial_clip referenced in function 
cairo_win32_surface_create

What do these two functions provide?  Can I remove them and replace them 
with an older version.  Any advice?

Cheers,
Mohit.
10/12/2009 | 10:38 PM.









From spitzak at gmail.com  Mon Oct 12 09:53:20 2009
From: spitzak at gmail.com (Bill Spitzak)
Date: Mon, 12 Oct 2009 09:53:20 -0700
Subject: [cairo] cl-cairo with X11 examples with mouse events handling
In-Reply-To: <A4E2F14C-6B28-4D63-8C5E-202EFD2EE6FF@wanadoo.fr>
References: <A4E2F14C-6B28-4D63-8C5E-202EFD2EE6FF@wanadoo.fr>
Message-ID: <4AD35F00.3030100@gmail.com>

I fully agree that such an example is very much needed. One of the big 
points in favor of Cairo is that it is not tied to a toolkit, but all 
the examples being tied to a toolkit mean that is not really true...

As FLTK can draw using Cairo, I think I may be able to extract the 
necessary information and make a program that works that does not use 
GTK (or FLTK). I hope this will be a useful example.

Taoufik Dachraoui wrote:
> Dear,
> 
> I am new to cl-cairo2 and would like to know how to write an X11  
> application using CL-CAIRO2
> 
> I installed cl-cairo2 on openmcl (Clozure CL) and run the tests (e.g  
> tutorial/x11-example.lisp)
> 
> The X11 tests works fine but I could not figure out how to use and  
> handle mouse events (e.g. button-press, exposure,...)
> 
> I will appreciate if someone can send me an example of how to create a  
> X11 window and to define lisp functions to handle mouse and keyboard  
> events.
> 
> I prefer to use X window with cairo and not GTK with cairo.
> 
> Kind regards
> Taoufik
> 
> 
> 
> 
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo

From samuel.w.sirlin at jpl.nasa.gov  Mon Oct 12 10:35:20 2009
From: samuel.w.sirlin at jpl.nasa.gov (sam sirlin)
Date: Mon, 12 Oct 2009 10:35:20 -0700
Subject: [cairo] Building on Solaris
In-Reply-To: <F3D32F3D-F984-4F9C-9BC8-C4F626EB64AF@cincom.com>
References: <F3D32F3D-F984-4F9C-9BC8-C4F626EB64AF@cincom.com>
Message-ID: <20091012103520.c592ef12.samuel.w.sirlin@jpl.nasa.gov>

On Sat, 10 Oct 2009 14:44:44 -0700
Travis Griggs <tgriggs at cincom.com> wrote:

> Subject pretty much asks it all. I've got an old Sun box I need to  
> build for. I'm no guru at this stuff. I found I didn't even have a  
> 'make' in my path; I've remedied that by downloading and building it  
> (interesting meta problem, how do you 'make make without make'). It  
> appears to be operational. Now I'm trying to get pkg-config built,  
> it's got errors. Maybe I'll share those in a bit, but more generally,  
> has anyone built CairoGraphics on Solaris, and would be wiling to  
> share the recipe, in as much detail as possible, with me?

I've got 1.8.8 running on solaris 10, so it can be done.

- you don't mention solaris version; troubles increase with older
  versions. 

- sun does include an (old) version of cairo with their (old) gnome
  stuff...  if it works for you it's probably easier than building
  your own.  On the other hand, if it is installed it can be a pain to
  then build/install your own more recent versions of stuff.

- there's also sunfreeware

If you do build your own from source, be prepared for building lots of
stuff, debuging Makefiles, configure scripts...

- make sure you have gnu make; you probably want gnu sed as well, ... 

- gcc is probably easier than sun cc 

- consider gargnome

- decide how/where you want to install  all the stuff, whether or not
  you like LDLIBRARYPATH; I  don't, and put stuff in non-standard
  places so I have a shell script to call configure with CFLAGS,
  CXXFLAGS, LDFLAGS, --prefix, etc defined.

-- 
sam sirlin <samuel.w.sirlin at jpl.nasa.gov>

From taoufik.dachraoui at wanadoo.fr  Mon Oct 12 11:11:51 2009
From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui)
Date: Mon, 12 Oct 2009 20:11:51 +0200
Subject: [cairo] cl-cairo with X11 examples with mouse events handling
In-Reply-To: <4AD35F00.3030100@gmail.com>
References: <A4E2F14C-6B28-4D63-8C5E-202EFD2EE6FF@wanadoo.fr>
	<4AD35F00.3030100@gmail.com>
Message-ID: <6B857DCC-CA30-40B5-8DA5-E12B276A71F1@wanadoo.fr>

I managed to write the following (this is not complete but I know how  
to handle xevents)

load the file and do >(cl-cairo2:runit)
then press mouse button on windows

 >>>> xclui.lisp
(in-package :cl-cairo2)

(defun my-create-window (display parent x y width height visual  
background-pixel
		      event-mask &optional (backing-store t))
   "Create an x11 window with the given attributes."
   ;; call xcreatewindow with attributes
   (with-foreign-object (attributes 'xsetwindowattributes)
     (setf (foreign-slot-value attributes 'xsetwindowattributes 'event- 
mask)
	  event-mask
	  (foreign-slot-value attributes 'xsetwindowattributes 'background- 
pixel)
	  background-pixel
	  (foreign-slot-value attributes 'xsetwindowattributes 'backing-store)
	  (if backing-store 1 0))
     (xcreatewindow display parent x y width height
		   0 			; zero border width
		   0 			; depth - copy from parent
		   1 ;inputoutput ; class
		   visual
		   (logior cwbackpixel cwbackingstore cweventmask)
		   attributes)))

(defclass my-xlib-context (context)
   ((display :initarg :display)
    (window :initarg :window)
    (xlib-context :initarg :xlib-context :accessor xlib-context)
    (wm-delete-window :initarg :wm-delete-window :accessor wm-delete- 
window)
    (width :initarg :width)
    (height :initarg :height)))

;create cairo context; link X Window to cairo surface
(defun my-create-context (display visual window width height)
   ;(xsynchronize display 1)
   (let* ((xlib-surface (cairo_xlib_surface_create display window visual
                                                  width height))
         (xlib-context (cairo_create xlib-surface)))
     (cairo_surface_destroy xlib-surface)
     (let*  ((surface (cairo_image_surface_create :CAIRO_FORMAT_RGB24
                                                  width height))
             (*context* (make-instance 'my-xlib-context :width  
width :height height :pixel-based-p t
                          :display display :window window :xlib- 
context xlib-context
                          :wm-delete-window (xinternatom display  
"WM_DELETE_WINDOW" 1)
                          :pointer (cairo_create surface))))
       (with-foreign-object (prot 'xatom)
         (setf (mem-aref prot 'xatom) (wm-delete-window *context*))
         (xsetwmprotocols display window prot 1))
       (cairo_set_source_surface xlib-context surface 0 0) ; link  
window to surface
       (cairo_surface_destroy surface)
       ;(xsynchronize display 0)
       *context*)))

(defun destroy-context (context)
   (with-slots (display window pointer
		       xlib-context)
       context
     (force-output t)
     (let ((saved-pointer pointer))
       (setf pointer nil) ; invalidate first so it can't be used
       (cairo_destroy saved-pointer))
     (cairo_destroy xlib-context)
     ;; !! free xlib-context, surface
     (xdestroywindow display window)))


(defmacro application (x y width height window-name &rest body)
   `(let* ((*display* (xopendisplay ":0.0"))
           (*screen* (xdefaultscreen *display*))
           (*root* (xdefaultrootwindow *display*))
           (*visual* (xdefaultvisual *display* *screen*))
           (*depth* (xdefaultdepth *display* *screen*))
           (*whitepixel* (xwhitepixel *display* *screen*))
           (*window*
                   (my-create-window *display*  
*root* ,x ,y ,width ,height *visual*
                                  *whitepixel*
                                  (logior exposuremask buttonpressmask
                                          structurenotifymask)
                                  t))
	  (*parent* *window*)
           (*context* (my-create-context *display* *visual*  
*window* ,width ,height))
	  (*width* ,width) (*height* ,height)
	  (*all-contexts* nil))
      (set-window-size-hints *display*  
*window* ,width ,width ,height ,height)
      (xstorename *display* *window* ,window-name)
      (xmapwindow *display* *window*)
      (progn
        , at body)
      (labels
          (;; Repaint the xlib context with the image surface
               ;; (previously set as source during initialization.
               (refresh ()
                 (dolist (c (reverse *all-contexts*)) (cairo_paint  
(xlib-context c)))
		(cairo_paint (xlib-context *context*)))
               ;; The main event loop, started as a separate thread
               ;; when initialization is complete.  The main thread is
               ;; supposed to communicate with this one via X signals
               ;; using an unmapped InputOnly window (see
               ;; send-message-to-signal-window).
               (event-loop ()
                   (let ((wm-protocols (xinternatom *display*  
"WM_PROTOCOLS" 1)))
                     (with-foreign-object (xev :long 24)
                       (do ((got-close-signal nil))
                           (got-close-signal)
                         ;; get next event
                         (xnextevent *display* xev)
                         ;; decipher structure, at least partially
                         (with-foreign-slots ((type window serial) xev  
xanyevent)
			  (format t "event ~A window ~A *window* ~A~%" type window *window*)
                           ;; action based on event type
                           (cond
                            ;; expose events
                            ((and (= type 12) (= window *window*))  
(refresh))
                            ;; clientnotify event
                            ((= type 33)
                             (with-foreign-slots ((message-type data0)  
xev
                                                  xclientmessageevent)
                               (cond
                                ((or (= data0 +destroy-message+)
                                     (and (= window *window*)
                                          (= message-type wm-protocols)
                                          (= data0 (wm-delete-window  
*context*))))
                                 (setf got-close-signal t))
                                ((= data0 +refresh-message+)
                                 (refresh)))))))) ))
                 ;; close down everything
		(dolist (c (reverse *all-contexts*)) (destroy-context c))
		(xclosedisplay *display*)))
        (event-loop))))

(defmacro view (x y width height  &rest body)
   `(let* ((*window*
	   (my-create-window *display* *parent* ,x ,y ,width ,height *visual*
			     *whitepixel*
			     (logior exposuremask buttonpressmask
				     structurenotifymask)
			     t))
	  (*context* (my-create-context *display* *visual*  
*window* ,width ,height))
	  (*width* ,width) (*height* ,height)
	  (*parent* *window*))
      (push *context* *all-contexts*)
      (xmapwindow *display* *window*)
      (progn
       , at body)))


;
;
; view body fires at exposue event; draw

(defun x-on-window (width height)
       (rectangle 0 0 width height)
       (set-source-rgb 0.2 0.2 0.5)
       (fill-path)
       ;; draw a white diagonal line
       (move-to width 0)
       (line-to 0 height)
       (set-source-rgb 1 1 1)
       (set-line-width 5)
       (stroke)
       ;; draw a green diagonal line
       (move-to 0 0)
       (line-to width height)
       (set-source-rgb 0 1 0)
       (set-line-width 5)
       (stroke))

(defun runit ()
   (application 100 100 400 400 "test"
	       (view 0 0 100 50
		     (rectangle 0 0 *width* *height*)
		     (set-source-rgb 0.2 0.2 1.0)
		     (fill-path)
		     (move-to 20 20)
		     (set-source-rgb 1.0 1.0 1.0)
		     (show-text "test"))
	       (view 100 100 100 100 (x-on-window *width* *height*))
	       (view 200 200 150 150 (x-on-window *width* *height*))))

(export 'runit)

 >>> end file

Regards
Taoufik

On Oct 12, 2009, at 6:53 PM, Bill Spitzak wrote:

>
> I fully agree that such an example is very much needed. One of the  
> big points in favor of Cairo is that it is not tied to a toolkit,  
> but all the examples being tied to a toolkit mean that is not really  
> true...
>
> As FLTK can draw using Cairo, I think I may be able to extract the  
> necessary information and make a program that works that does not  
> use GTK (or FLTK). I hope this will be a useful example.
>
> Taoufik Dachraoui wrote:
>> Dear,
>> I am new to cl-cairo2 and would like to know how to write an X11   
>> application using CL-CAIRO2
>> I installed cl-cairo2 on openmcl (Clozure CL) and run the tests  
>> (e.g  tutorial/x11-example.lisp)
>> The X11 tests works fine but I could not figure out how to use and   
>> handle mouse events (e.g. button-press, exposure,...)
>> I will appreciate if someone can send me an example of how to  
>> create a  X11 window and to define lisp functions to handle mouse  
>> and keyboard  events.
>> I prefer to use X window with cairo and not GTK with cairo.
>> Kind regards
>> Taoufik
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>




From tgriggs at cincom.com  Mon Oct 12 11:57:16 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Mon, 12 Oct 2009 11:57:16 -0700
Subject: [cairo] Building on Solaris
In-Reply-To: <20091012103520.c592ef12.samuel.w.sirlin@jpl.nasa.gov>
References: <F3D32F3D-F984-4F9C-9BC8-C4F626EB64AF@cincom.com>
	<20091012103520.c592ef12.samuel.w.sirlin@jpl.nasa.gov>
Message-ID: <131650A1-A0D9-4E8D-9CB9-5ADDE277CF3A@cincom.com>


On Oct 12, 2009, at 10:35 AM, sam sirlin wrote:

> On Sat, 10 Oct 2009 14:44:44 -0700
> Travis Griggs <tgriggs at cincom.com> wrote:
>
>> Subject pretty much asks it all. I've got an old Sun box I need to
>> build for. I'm no guru at this stuff. I found I didn't even have a
>> 'make' in my path; I've remedied that by downloading and building it
>> (interesting meta problem, how do you 'make make without make'). It
>> appears to be operational. Now I'm trying to get pkg-config built,
>> it's got errors. Maybe I'll share those in a bit, but more generally,
>> has anyone built CairoGraphics on Solaris, and would be wiling to
>> share the recipe, in as much detail as possible, with me?
>
> I've got 1.8.8 running on solaris 10, so it can be done.
>
> - you don't mention solaris version; troubles increase with older
>  versions.

We try and support customers running as old as Solaris 8/SunOS 5.8.

> - sun does include an (old) version of cairo with their (old) gnome
>  stuff...  if it works for you it's probably easier than building
>  your own.  On the other hand, if it is installed it can be a pain to
>  then build/install your own more recent versions of stuff.

> - there's also sunfreeware


Looks like they did 1.4.10 a long time ago for 8. We'd like to be able  
to do the newer version, especially since the newer cairo versions  
have the hope of not *requiring* fontconfig/freetype.
>
> If you do build your own from source, be prepared for building lots of
> stuff, debuging Makefiles, configure scripts...

Sigh. Wish I was better prepared. This is not my regular zone of  
comfort. I guess I'll be learning some things. And begging for lots of  
hints/help.

> - make sure you have gnu make; you probably want gnu sed as well, ...
>
> - gcc is probably easier than sun cc

I've got gcc 3.3.2 on this machine.

> - consider gargnome
>
> - decide how/where you want to install  all the stuff, whether or not
>  you like LDLIBRARYPATH; I  don't, and put stuff in non-standard
>  places so I have a shell script to call configure with CFLAGS,
>  CXXFLAGS, LDFLAGS, --prefix, etc defined.


Thanks much.

If you had a list of steps you did to get it built for 10, that would  
be greatly appreciated.

--
Travis Griggs
Objologist
If you can't say "Did it First!", you'd better be able to say "Did it  
Better!"



From gerdusvanzyl at gmail.com  Mon Oct 12 12:02:25 2009
From: gerdusvanzyl at gmail.com (Gerdus van Zyl)
Date: Mon, 12 Oct 2009 21:02:25 +0200
Subject: [cairo] Problems with building Cairo for Windows CE
In-Reply-To: <4AD33F55.5040709@onghu.com>
References: <4ACDD95E.4050006@onghu.com> <4ACF5CCF.6070104@onghu.com>
	<4AD33F55.5040709@onghu.com>
Message-ID: <91882ea90910121202x583b0fbcn3c8e43e1d869341@mail.gmail.com>

You might be interested in this patch in the mozilla source code for cairo:
http://hg.mozilla.org/mozilla-central/file/3205228e9838/gfx/cairo/wince-fixes.patch

If you don't get a reply on the ML you might try asking on the cairo IRC
channel, people are sometimes more talkative on there.

~G

On Mon, Oct 12, 2009 at 4:38 PM, Mohit Sindhwani <ml3p at onghu.com> wrote:

> Mohit Sindhwani wrote:
> > Mohit Sindhwani wrote:
> >
> > Next on, I'm stuck at an error in building win32-surface.c - there seem
> > to be some errors related to the function:
> > * _cairo_win32_save_initial_clip -> called from
> > _cairo_win32_surface_finish, _cairo_win32_surface_set_clip_region
> >
>
> Can anyone explain the function of the methods:
> * cairo_int_status_t _cairo_win32_save_initial_clip (HDC hdc,
> cairo_win32_surface_t *surface)
> * cairo_int_status_t _cairo_win32_restore_initial_clip
> (cairo_win32_surface_t *surface)
>
> These throw up warning/ errors when compiling and eventually results in
> missing symbols when on Windows CE.  On the other hand, these were not
> there in 1.4.4.  These functions are called from:
> 1>_cairo_win32_restore_initial_clip referenced in function
> _cairo_win32_surface_finish
> 1>_cairo_win32_save_initial_clip referenced in function
> cairo_win32_surface_create
>
> What do these two functions provide?  Can I remove them and replace them
> with an older version.  Any advice?
>
> Cheers,
> Mohit.
> 10/12/2009 | 10:38 PM.
>
>
>
>
>
>
>
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091012/303c20d0/attachment.html 

From spitzak at gmail.com  Mon Oct 12 13:49:31 2009
From: spitzak at gmail.com (Bill Spitzak)
Date: Mon, 12 Oct 2009 13:49:31 -0700
Subject: [cairo] cl-cairo with X11 examples with mouse events handling
In-Reply-To: <4AD35F00.3030100@gmail.com>
References: <A4E2F14C-6B28-4D63-8C5E-202EFD2EE6FF@wanadoo.fr>
	<4AD35F00.3030100@gmail.com>
Message-ID: <4AD3965B.1060600@gmail.com>

This works. The code is extracted from the fltk2.0 source code so it has 
been somewhat tested.

   cc x11cairo.c -o x11cairo -lX11 -lcairo

It might be a good idea to add this to the Cairo examples, provided 
everybody considers it ok.

Another nice idea would be to make a portable "toy" toolkit that lets 
you create windows and draw with Cairo into them, and recompile on 
Windows and Linux and maybe OS/X. Sort of like Glut, which I think is 
part of the popularity of OpenGL.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: x11cairo.c
Type: text/x-csrc
Size: 6991 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091012/5d067876/attachment.c 

From ml3p at onghu.com  Mon Oct 12 18:46:19 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Tue, 13 Oct 2009 09:46:19 +0800
Subject: [cairo] Problems with building Cairo for Windows CE
In-Reply-To: <91882ea90910121202x583b0fbcn3c8e43e1d869341@mail.gmail.com>
References: <4ACDD95E.4050006@onghu.com> <4ACF5CCF.6070104@onghu.com>	
	<4AD33F55.5040709@onghu.com>
	<91882ea90910121202x583b0fbcn3c8e43e1d869341@mail.gmail.com>
Message-ID: <4AD3DBEB.1000404@onghu.com>

Gerdus van Zyl wrote:
> You might be interested in this patch in the mozilla source code for 
> cairo:
> http://hg.mozilla.org/mozilla-central/file/3205228e9838/gfx/cairo/wince-fixes.patch
>
> If you don't get a reply on the ML you might try asking on the cairo 
> IRC channel, people are sometimes more talkative on there.
Thanks Gerdus,

You're right - the list has been quiet on these issues, but I guess 
there are not that many people using it on Windows CE then... all the 
same, I do like Cairo and if it works on Windows CE, it'll be great for 
what I'm planning.  But I need it to work so that I can do a meaningful 
benchmark.

Cheers,
Mohit.
10/13/2009 | 9:46 AM.


From maarten.mostert at wanadoo.fr  Mon Oct 12 21:41:20 2009
From: maarten.mostert at wanadoo.fr (Maarten MOSTERT)
Date: Tue, 13 Oct 2009 06:41:20 +0200
Subject: [cairo] Cairo pdf printing
Message-ID: <2DAA4BCBFE7B402CA11A1C049057CEFC@MacBookWindows>

Hi,

When I a writing text to the pdf context it will give a 'Bad status: out of memory' whenever my the number of characters is bigger then 12.
Their is no difference wheter I do this with Pango or Cairo. I don't have problems writing many smaller text portions. The code I use is identical to the one I use to write to the screen.

I use version  '1.8.0' on windows.

Regards,

@+Maarten,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091013/53030d38/attachment.html 

From zeng.shixin at gmail.com  Mon Oct 12 22:33:43 2009
From: zeng.shixin at gmail.com (Shixin Zeng)
Date: Tue, 13 Oct 2009 00:33:43 -0500
Subject: [cairo] Fwd:  SVG to EMF quality
In-Reply-To: <7a9157a40910122230i16503e03hb499e78355e4278a@mail.gmail.com>
References: <7a9157a40909021042u5b6dab2s677ae7c49718c54f@mail.gmail.com>
	<7a9157a40909021119i6f3f1ecdq5c2fb5ffc4f51eaa@mail.gmail.com>
	<4AA7B6A7.4040403@redneon.com>
	<7a9157a40910122230i16503e03hb499e78355e4278a@mail.gmail.com>
Message-ID: <7a9157a40910122233l4641cde4g53568819fd3d5ba@mail.gmail.com>

Forwarding with zipped attachment

Best Regards

Shixin Zeng




---------- Forwarded message ----------
From: Shixin Zeng <zeng.shixin at gmail.com>
Date: Tue, Oct 13, 2009 at 12:30 AM
Subject: Re: [cairo] SVG to EMF quality
To: Adrian Johnson <ajohnson at redneon.com>
Cc: cairo at cairographics.org


Hi, Adrian

Thanks for that patch, but I'm sorry to say that it doesn't seem to
improve anything, at least to my eyes.

I found your emf was deleted, I pulled it a month ago, so I still have
that patch. I'm sorry for responding so late, but it took me quite a
time to compile cairo and librsvg(which turns out to depend on gtk) on
windows.

The output is attached.

axial2.emf is produced this the cairo with your patch, axial.emf is
produced by pristine cairo, and axial.svg is the source.

Best Regards

Shixin Zeng



On Wed, Sep 9, 2009 at 9:07 AM, Adrian Johnson <ajohnson at redneon.com> wrote:
> Shixin Zeng wrote:
>>
>> Hi,
>>
>> I've produced some pictures with matplotlib for my paper, which
>> prefers enhanced MetaFile (EMF). However, current maplotlib doesn't
>> support EMF output, but svg. So I tried to convert svg to emf via
>> cairo, as mentioned in this
>>
>> thread:http://lists.cairographics.org/archives/cairo/2009-January/016215.html
>>
>> But the problem is that the quality of the output emf file is pretty
>> low. Is this caused by my badly programming or the limitation of this
>> method itself? Thanks
>
> After discovering EMFexplorer [1] and examining some different EMF files I
> have found the cause of the low quality EMF output from the win32-printing
> surface.
>
> In GDI all path functions use integer coordinates. For small drawings this
> causes rounding problems. Using EMFexplorer I could see that other
> applications were scaling down the GDI current transformation matrix and
> scaling up path coordinates to increase the precision.
>
> This was something I previously tried with the win32-printing surface
> without success. Using EMFexplorer to check the output I could immediately
> see what the problem is. The win32-print surface is resetting the GDI CTM to
> identity to preventing rounding errors when printing where the GDI units are
> in dpi.
>
> The patch on my emf branch [2] is an initial attempt at fixing this. It
> needs further testing to ensure I have not caused any regressions when
> printing. With this patch it is possible to get good EMF output with the
> following code:
>
> void create_emf (char *filename)
> {
> ? ?HDC dc;
> ? ?HDC ref_dc;
> ? ?XFORM xform;
> ? ?cairo_surface_t *surface;
> ? ?cairo_t *cr;
>
> ? ?ref_dc = GetDC (NULL);
> ? ?dc = CreateEnhMetaFile (ref_dc, filename, NULL, NULL);
> ? ?ReleaseDC (NULL, dc);
>
> ? ?/* Scale the GDI CTM by 1/16. This allows all coordinates to
> ? ? * be scaled up by 16 to increase precision */
> ? ?SetGraphicsMode (dc, GM_ADVANCED);
> ? ?xform.eM11 = 1.0/16;
> ? ?xform.eM12 = 0;
> ? ?xform.eM21 = 0;
> ? ?xform.eM22 = 1.0/16;
> ? ?xform.eDx = 0;
> ? ?xform.eDy = 0;
> ? ?SetWorldTransform (dc, &xform);
>
> ? ?surface = cairo_win32_printing_surface_create (dc);
> ? ?cr = cairo_create (surface);
>
> ? ?/* Undo the scale applied to the GDI CTM */
> ? ?cairo_scale (cr, 16, 16);
>
> ? ?draw (cr);
> ? ?cairo_destroy (cr);
> ? ?cairo_surface_destroy (surface);
> ? ?CloseEnhMetaFile (dc);
> }
>
>
> [1] http://frazmitic.free.fr/emfexplorer/
> [2] http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=emf
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svg2emf.zip
Type: application/zip
Size: 43205 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091013/d6064047/attachment-0001.zip 

From ajohnson at redneon.com  Tue Oct 13 03:47:30 2009
From: ajohnson at redneon.com (Adrian Johnson)
Date: Tue, 13 Oct 2009 21:17:30 +1030
Subject: [cairo] SVG to EMF quality
In-Reply-To: <7a9157a40910122230i16503e03hb499e78355e4278a@mail.gmail.com>
References: <7a9157a40909021042u5b6dab2s677ae7c49718c54f@mail.gmail.com>	
	<7a9157a40909021119i6f3f1ecdq5c2fb5ffc4f51eaa@mail.gmail.com>	
	<4AA7B6A7.4040403@redneon.com>
	<7a9157a40910122230i16503e03hb499e78355e4278a@mail.gmail.com>
Message-ID: <4AD45AC2.3000504@redneon.com>

Shixin Zeng wrote:
> Hi, Adrian
> 
> Thanks for that patch, but I'm sorry to say that it doesn't seem to
> improve anything, at least to my eyes.
> 

It works for me:

http://people.freedesktop.org/~ajohnson/axial.emf

> I found your emf was deleted, I pulled it a month ago, so I still have
> that patch. I'm sorry for responding so late, but it took me quite a
> time to compile cairo and librsvg(which turns out to depend on gtk) on
> windows.

I'm using git master. The patch I pushed to master is here:

http://cgit.freedesktop.org/cairo/commit/?id=7658635c654b694b516e5dd44a43611d94e91abd

I no longer have that emf branch so I can't check if I fixed anything 
anything before pushing to master. Try it with the new patch or just use 
git master.

From ajohnson at redneon.com  Tue Oct 13 04:02:13 2009
From: ajohnson at redneon.com (Adrian Johnson)
Date: Tue, 13 Oct 2009 21:32:13 +1030
Subject: [cairo] fallback resolution bug?
In-Reply-To: <3c78ff030910041939o7c7dbd5di4a9d5e6512265109@mail.gmail.com>
References: <3c78ff030909291609n78f61fc7u2018a47b3630446a@mail.gmail.com>	
	<4AC94C27.4050600@redneon.com>
	<3c78ff030910041939o7c7dbd5di4a9d5e6512265109@mail.gmail.com>
Message-ID: <4AD45E35.2050107@redneon.com>

bulia byak wrote:
> On Sun, Oct 4, 2009 at 10:30 PM, Adrian Johnson <ajohnson at redneon.com> wrote:
>> I have a branch that contains a fix for Carl's patch for this bug. It works
>> for me.
>>
>> http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=acquire_source_image_transformed
> 
> 1. Do you have, by chance, a Windows build of this branch?

No.

> 2. Do you have an idea what official cairo version will have this fix?

No. I have not received any feedback from Carl on my patches for Carl's fix.

> 
> Thanks!
> 


From aymen.chehaider at gmail.com  Tue Oct 13 04:13:37 2009
From: aymen.chehaider at gmail.com (aymen chehaider)
Date: Tue, 13 Oct 2009 12:13:37 +0100
Subject: [cairo] cairo-trace and cairo-perf-trace with new backend
Message-ID: <ab9501820910130413r18964002h8179dfa20c603be4@mail.gmail.com>

Hi,

I have developped a new backend for Cairo 1.9.2. *(Embedded environment)*

I want to know, how can I test perfs of this new backend ???

How can I use cairo-trace and cairo-perf-trace for this backend ?

I have tried to use cairo-trace : *cairo-trace --profile my_application*
the result in the file is : *% Unknown object of type cairo_surface_t, trace
is incomplete.*


Help plz,

Thanks.

Best Regards,
Aymen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091013/3a5a77b6/attachment.html 

From chris at chris-wilson.co.uk  Tue Oct 13 04:42:58 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 13 Oct 2009 12:42:58 +0100
Subject: [cairo] cairo-trace and cairo-perf-trace with new backend
In-Reply-To: <ab9501820910130413r18964002h8179dfa20c603be4@mail.gmail.com>
References: <ab9501820910130413r18964002h8179dfa20c603be4@mail.gmail.com>
Message-ID: <1255433592-sup-3603@broadwater.alporthouse.com>

Excerpts from aymen chehaider's message of Tue Oct 13 12:13:37 +0100 2009:
> I have developped a new backend for Cairo 1.9.2. *(Embedded environment)*
> 
> I want to know, how can I test perfs of this new backend ???
> 
> How can I use cairo-trace and cairo-perf-trace for this backend ?

First I presume that you have coupled in the boilerplate/ for your
backend and are satisfied with the results from the test suite.
 
> I have tried to use cairo-trace : *cairo-trace --profile my_application*
> the result in the file is : *% Unknown object of type cairo_surface_t, trace
> is incomplete.*

Indeed, it means that util/cairo-trace/trace.c does not have the
appropriate hook for backend surface constructor. Simply add the
relevant function wrappers by doing a copy'n'paste from one of the other
backends.

But recording new traces is not strictly relevant for performance
testing, since you can just use the existing traces from cairo-traces.git
with cairo-perf-trace. The trick here is that cairo-perf-trace uses a
default value of FALSE for target_is_measurable(), so you need to add
your surface type to that switch. And the same for the micro-benchmark
suite, called cairo-perf for 1.9.2. And whilst we're on that subject,
beware the interface changes that are in master.

Hope this helps, and you have fun with cairo. Please do share any
experiences you gained whilst developing a novel backend -- especially
if they may help shape the internal interfaces both for easing
maintenance and improving performance.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From cairouser at yahoo.com  Tue Oct 13 10:07:25 2009
From: cairouser at yahoo.com (cu)
Date: Tue, 13 Oct 2009 13:07:25 -0400
Subject: [cairo] Windows font rendering issue
Message-ID: <4AD4B3CD.4050902@yahoo.com>

Good day all!

I seem to recall the issue discussed previously, but can't find what it
was or whether there was a resolution.

The Cairo version is 1.8.6 (which we'd like to keep, if possible, since
it seems to perform a better for us). Essentially, when rendering text
using Windows font backend and image surface, text sometimes gets cut
off - usually on the bottom or right by what appears to be a line
exactly one pixel wide. It would almost seem like there is a clip mask
around it and it is a bit too small for the output. Examples would be
trivial - simply create image surface, select a font ("arial") for
example, and keep changing font and surface size, then repainting.

As a side issue, windows font sizes seem to adjust much less gracefully
than those on Mac/Linux (essentially in jumps, and also occasionally
font appearance seems to change as size is increased/decreased by 1 unit).

Same code does not exhibit this behavior on Mac/Linux using FreeType
font backend.

Any help/advice would be appreciated.



From behdad at behdad.org  Tue Oct 13 10:26:13 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 13 Oct 2009 10:26:13 -0700
Subject: [cairo] Windows font rendering issue
In-Reply-To: <4AD4B3CD.4050902@yahoo.com>
References: <4AD4B3CD.4050902@yahoo.com>
Message-ID: <4AD4B835.8050504@behdad.org>

Hi,

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=445087

behdad

On 10/13/2009 10:07 AM, cu wrote:
> Good day all!
>
> I seem to recall the issue discussed previously, but can't find what it
> was or whether there was a resolution.
>
> The Cairo version is 1.8.6 (which we'd like to keep, if possible, since
> it seems to perform a better for us). Essentially, when rendering text
> using Windows font backend and image surface, text sometimes gets cut
> off - usually on the bottom or right by what appears to be a line
> exactly one pixel wide. It would almost seem like there is a clip mask
> around it and it is a bit too small for the output. Examples would be
> trivial - simply create image surface, select a font ("arial") for
> example, and keep changing font and surface size, then repainting.
>
> As a side issue, windows font sizes seem to adjust much less gracefully
> than those on Mac/Linux (essentially in jumps, and also occasionally
> font appearance seems to change as size is increased/decreased by 1 unit).
>
> Same code does not exhibit this behavior on Mac/Linux using FreeType
> font backend.
>
> Any help/advice would be appreciated.
>
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>

From tgriggs at cincom.com  Tue Oct 13 12:39:33 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Tue, 13 Oct 2009 12:39:33 -0700
Subject: [cairo] Windows font rendering issue
In-Reply-To: <4AD4B835.8050504@behdad.org>
References: <4AD4B3CD.4050902@yahoo.com> <4AD4B835.8050504@behdad.org>
Message-ID: <42392358-2953-4B85-ABEF-10F26B0EC84B@cincom.com>


On Oct 13, 2009, at 10:26 AM, Behdad Esfahbod wrote:

> Hi,
>
> See:
> https://bugzilla.mozilla.org/show_bug.cgi?id=445087

Wow. That's quite a read. I admit to glazing over and going into skim  
mode after 5+ minutes of reading. My question at this point is.. is it  
fixed now? Or was it fixed in a recent release? Or a future release?  
Or is it still open? Says it was resolved at the top. But it's still  
blocking 1.9.3? Or...?

It would be nice to have this fixed. I've had VisualWorks programmers  
using Cairo point this flaw out to me as well.

--
Travis Griggs
Objologist
"The project was so plagued by politics and ego that when the  
engineers requested technical oversight, our manager hired a  
psychologist instead." -- Ron Avitzur


From jonathan at jfkew.plus.com  Tue Oct 13 12:54:38 2009
From: jonathan at jfkew.plus.com (Jonathan Kew)
Date: Tue, 13 Oct 2009 20:54:38 +0100
Subject: [cairo] Windows font rendering issue
In-Reply-To: <42392358-2953-4B85-ABEF-10F26B0EC84B@cincom.com>
References: <4AD4B3CD.4050902@yahoo.com> <4AD4B835.8050504@behdad.org>
	<42392358-2953-4B85-ABEF-10F26B0EC84B@cincom.com>
Message-ID: <B78147D2-9F4E-47C6-9037-BA7A8FE4572F@jfkew.plus.com>

On 13 Oct 2009, at 20:39, Travis Griggs wrote:

>
> On Oct 13, 2009, at 10:26 AM, Behdad Esfahbod wrote:
>
>> Hi,
>>
>> See:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=445087
>
> Wow. That's quite a read. I admit to glazing over and going into skim
> mode after 5+ minutes of reading. My question at this point is.. is it
> fixed now? Or was it fixed in a recent release? Or a future release?
> Or is it still open? Says it was resolved at the top. But it's still
> blocking 1.9.3? Or...?
>
> It would be nice to have this fixed. I've had VisualWorks programmers
> using Cairo point this flaw out to me as well.
>

I believe that specific Mozilla bug report is fixed for Firefox 3.6  
(beta coming shortly....), but it was patched locally within our copy  
of Cairo; I don't know if the upstream Cairo project has done anything  
about the issue yet.

JK


From siarhei.siamashka at gmail.com  Tue Oct 13 15:13:17 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Wed, 14 Oct 2009 01:13:17 +0300
Subject: [cairo] pixman: New ARM NEON optimizations
Message-ID: <200910140113.17147.siarhei.siamashka@gmail.com>

Hello,

This branch has new ARM NEON optimizations:
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=arm-neon-update

It uses GNU assembler and its macro preprocessor to generate fast path
functions from a common template, so that only a minor part of the inner
loop code needs to be implemented for each function, saving a lot of work.
For example, the core function for performing x8r8g8b8->r5g6b5 conversion
uses as little as this much code:
http://cgit.freedesktop.org/~siamashka/pixman/commit/?h=arm-neon-update&id=b17297cf15122e5b38c082c9fe6f1ff708b7efa4

The template supports any kind of combinations of source, destination and mask
images with 8bpp, 16bpp and 32bpp color formats (24bpp support is a bit more
tricky, but can be done too). The code has comments which should help to get
the idea about how to implement new fast path functions. If comments are not
sufficient or not completely clear, I will try to update them.

The reasons to use GNU assembler are:
1. Full control over registers allocation (there are not too many of them, 
considering that up to 3 images are supported with their strides, pointers, 
prefetch stuff). I encountered problems running out of registers with inline
assembly and compiling with frame pointer.
2. This allows the use of more or less advanced macro preprocessor and makes
everything easier. A bit more flexible option would be to use JIT code
generation here (this is actually something to consider later).

Technically, there should be no problem catching up with SSE2, especially if
instructions scheduling perfection could be skipped at the first stage. Right
now only the existing NEON fast path functions are reimplemented plus just a
few more.

Now the thing to solve is how to handle the systems other than linux. There is
a potential problem with ABI compatibility - the functions must be fully
compatible with the calling conventions, etc. For now I'm only sure that
they are compatible with Linux EABI. Most likely the other systems should be
fine too, or will be fine with a few tweaks.

Benchmarks show that this new code generally has the same or substantially
better performance than the current pixman NEON fast path functions. Log
from cairo-perf is attached.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
Speedups
========
image-rgba-???  paint-with-alpha_similar_rgba_over-512-0     11.14 (11.23 0.50%) ->   5.55 (5.74 1.46%):  2.01x speedup
image-rgb-???  one-rectangle_image_rgba_over-512-0     10.80 (10.83 0.49%) ->   5.55 (5.62 0.78%):  1.95x speedup
image-rgb-???  paint-with-alpha_image_rgba_over-512-0     11.14 (11.26 2.48%) ->   5.74 (5.92 1.01%):  1.94x speedup
image-rgba-???   paint_image_rgba_over-512-0     10.80 (10.86 0.21%) ->   5.58 (5.68 0.81%):  1.93x speedup
image-rgba-???  paint_similar_rgba_over-512-0     10.74 (10.77 0.51%) ->   5.62 (5.83 1.43%):  1.91x speedup
image-rgb-???  paint_similar_rgba_over-512-0     10.77 (10.83 0.42%) ->   5.71 (5.80 0.71%):  1.89x speedup
image-rgb-???   paint_image_rgba_over-512-0     10.77 (10.83 0.50%) ->   5.74 (5.74 0.61%):  1.88x speedup
image-rgba-???  one-rectangle_image_rgba_over-512-0     10.80 (10.86 0.35%) ->   5.80 (5.89 0.81%):  1.86x speedup
image-rgba-???  paint-with-alpha_image_rgba_over-256-0      2.59 (2.62 1.88%) ->   1.43 (1.47 0.96%):  1.81x speedup
image-rgba-???   paint_image_rgba_over-256-0      2.65 (2.69 2.32%) ->   1.53 (1.59 3.08%):  1.74x speedup
image-rgba-???  paint_similar_rgba_over-256-0      2.35 (2.41 1.79%) ->   1.37 (1.37 0.03%):  1.71x speedup
image-rgba-???  paint-with-alpha_similar_rgba_over-256-0      2.38 (2.44 2.43%) ->   1.40 (1.40 0.04%):  1.70x speedup
image-rgb-???   paint_image_rgba_over-256-0      2.26 (2.35 2.66%) ->   1.37 (1.43 1.49%):  1.65x speedup
image-rgb-???  paint-with-alpha_similar_rgba_over-256-0      2.44 (2.47 2.26%) ->   1.53 (1.56 2.57%):  1.60x speedup
image-rgb-???  paint-with-alpha_image_rgba_over-256-0      2.41 (2.50 2.43%) ->   1.53 (1.56 0.95%):  1.58x speedup
image-rgb-???  paint_similar_rgba_over-256-0      2.26 (2.35 2.03%) ->   1.43 (1.44 0.03%):  1.57x speedup
image-rgba-???  one-rounded-rectangle_solid_rgba_over-512-0     11.44 (11.54 0.40%) ->   8.09 (8.18 0.47%):  1.42x speedup
image-rgba-???  one-rounded-rectangle_solid_rgb_over-512-0     11.41 (11.57 0.56%) ->   8.18 (8.18 0.01%):  1.40x speedup
image-rgb-???  one-rectangle_similar_rgb_source-512-0      3.69 (3.72 1.06%) ->   3.27 (3.45 2.30%):  1.13x speedup
image-rgb-???  paint_similar_rgba_source-256-0      0.89 (0.89 1.40%) ->   0.79 (0.79 4.80%):  1.12x speedup
image-rgba-???  rectangles_similar_rgba_over-512-0     90.09 (90.76 0.70%) ->  81.18 (83.56 1.15%):  1.11x speedup
image-rgb-???  rectangles_similar_rgba_over-512-0     89.91 (91.43 0.69%) ->  81.60 (82.89 0.81%):  1.10x speedup
image-rgb-???  rectangles_similar_rgba_source-512-0     69.76 (70.98 0.99%) ->  64.64 (65.22 0.40%):  1.08x speedup
image-rgb-???  rectangles_image_rgba_source-512-0     69.55 (70.89 0.95%) ->  65.06 (65.55 0.46%):  1.07x speedup
image-rgba-???     fill_solid_rgb_over-256-0      3.66 (3.75 1.64%) ->   3.45 (3.54 1.56%):  1.06x speedup
image-rgba-???    fill_solid_rgba_over-256-0      3.66 (3.69 1.16%) ->   3.48 (3.48 1.12%):  1.05x speedup
Slowdowns
========
image-rgb-???  paint_solid_rgba_source-256-0      0.28 (0.28 0.00%) ->   0.30 (0.30 4.63%):  1.11x slowdown

From siarhei.siamashka at gmail.com  Tue Oct 13 15:35:30 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Wed, 14 Oct 2009 01:35:30 +0300
Subject: [cairo] Faster bilinear scaling
In-Reply-To: <ye8ljjoz3qt.fsf@camel24.daimi.au.dk>
References: <ye8ljjoz3qt.fsf@camel24.daimi.au.dk>
Message-ID: <200910140135.30335.siarhei.siamashka@gmail.com>

On Tuesday 06 October 2009, Soeren Sandmann wrote:
> Hi,
>
> This branch:
>
>         http://cgit.freedesktop.org/~sandmann/pixman/log/?h=bilinear
>
> contains a fast path for fetching of bilinearly filtered, scaled
> images. It is basically Andre's work, described here:
>
>        
> http://lists.cairographics.org/archives/cairo/2008-December/016170.html
>
> What I did was
>
>         - Update scaling-test to also test bilinear scaling
>
>         - Remove bilinear_interpolation_left/right() functions in
>           favor of just calling bilinear_interpolation().
>
>         - Fix coding style.

Nice, any improvements in this area are very much welcome.

> The performance improvement for the swfdec-youtube benchmark on a
> 3.8GHz P4 is around 17%:
>
> Before:
>
> [ # ]  backend                         test   min(s) median(s)  stddev.
> count [  0]    image               swfdec-youtube    8.375    8.431   0.44%
>   6/6
>
> After:
>
> [ # ]  backend                         test   min(s) median(s) stddev.
> count [  0]    image               swfdec-youtube    6.942    7.019   0.61%
>  6/6
>
> Much of the profile of this benchmark is in radial gradients, so other
> users of bilinear scaling may see more improvement.

More specialized benchmarks would be nice to see too. For example benchmark
scaling 99x99 to 101x101 and compare it to a simple copy of 100x100 image.
That would give an estimate about how much this operation is memory throughput
limited and how much it can be potentially improved.

> Also, if anyone is interested in adding support for SIMD acceeleration
> of fetchers, the the bilinear_interpolation() function is begging to
> be written with SSE2 or NEON.

This can be tried indeed.

Also an alternative option for the bilinear filter can be to have two
temporary fetch buffers, don't do any kind of interpolation in the fetcher,
but put pairs of pixels into these buffers. Then do interpolation in a bulk.
Full width of SIMD registers may be utilized better in this case. 
Interpolation can be also combined with some compositing operation, for
example OVER is the primary candidate.

Another variation of this is to do horizontal interpolation first and put
partly processed data into two temporary buffers. A possible advantage
of this approach is that horizontally interpolated data can be reused
multiple times quite often, especially when upscaling.

There are many things to try. It also can happen that optimal implementations
may be different for different platforms. But as long as the code is well
covered by regression tests, having more than one implementation should not be
a problem.

-- 
Best regards,
Siarhei Siamashka

From britten at caris.com  Wed Oct 14 07:57:20 2009
From: britten at caris.com (Ian Britten)
Date: Wed, 14 Oct 2009 11:57:20 -0300
Subject: [cairo] NO_HINTING problems with custom FT_Face
Message-ID: <4AD5E6D0.60807@caris.com>

Hi all,
   [ Cairo v1.8.8, FreeType v2.3.9 ]
I was hoping that someone could help me get to the root of a problem
I'm having when using my custom FreeType font driver via Cairo.  I
realize it's not truly a Cairo problem per-se, but I know that there
are some people here knowledgeable about this stuff, and I'm almost at
wits end ... :(

Problem:
- When I create+draw my text upright and use load_flags=0, the text
   draws as expected.  However, when I use load_flags=FT_LOAD_NO_HINTING,
   my text no longer draws.

Background:
- I have a custom FT fontdriver, for accessing our custom font format
   seamlessly as a FT_Face.
- I have a non-Cairo rendering system, in which the driver works as
   needed (Admittedly, in very limited/controlled workflows).
- I'm trying to render this text through Cairo, which is putting
   untested expectations on my driver, and which I'm trying to fix.
- Although I obviously can't reproduce this in a sample (due to the
   custom font driver), the Cairo code is pretty generic.  I simply
   get my FT font, set it in the context, set the colour/size/etc, and
   do a show_glyphs().  The same code works with TT fonts though.

I'm reasonably certain the problem is with my font driver, specifically
the FT_Slot_LoadFunc callback(*) not handling the given load_flags
parameter correctly.  However, I'm not sure what Cairo is expecting
of my driver, since Cairo sets some of those flags when loading
glyphs, and the FT documentation of those flags is a bit sparse.
(*) Called by FT_Load_Glyph(), called by _cairo_ft_scaled_glyph_init()

In the case that works (I set load_flags=0), my driver received a
load_flags=2571:
   FT_LOAD_NO_SCALE  FT_LOAD_NO_HINTING  FT_LOAD_NO_BITMAP
   FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH  FT_LOAD_IGNORE_TRANSFORM
In the case that doesn't work (load_flags=FT_LOAD_NO_HINTING), my
driver received a load_flags=514
   FT_LOAD_NO_HINTING  FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH

I suspect that the problem is that my driver doesn't do anything when
FT_LOAD_IGNORE_TRANSFORM is absent, and Cairo is expecting it to have
done _something_ to various fields...  I'm just not sure what, and in
what units/format (eg: double? 26.6? 16.16?).  I've been flailing
around some, but with no success yet.

So, is anyone familiar with this realm?  (And, is anyone still reading
this? :P )  Can anyone offer any description or suggestion of what I
need to do?
Or, if I'm completely off-base, does anyone have any other ideas why
my text doesn't draw when I turn off hinting?

Many thanks for any help!
Ian

From bluepower1983 at yahoo.com  Wed Oct 14 08:14:03 2009
From: bluepower1983 at yahoo.com (Liang Wang)
Date: Wed, 14 Oct 2009 08:14:03 -0700 (PDT)
Subject: [cairo] a question of cairo printer
Message-ID: <589551.42422.qm@web113109.mail.gq1.yahoo.com>

Hello, I am a software? engineer in china. We are developing a new product, but we experiencing a problem. When we use cairo transparency effect to draw graphics on text or graphics drawed by gdi, after printing, we found the effect of transparency is enable. The graphics drawed by cairo will cover the graphic drawed by gdi. But when we use that on a graphic drawed by cairo, after printing, it is correct. So, I wanna know why and how to resolve? this problem.


I am looking forward to your reply as soon as possible.
Thank you very much.




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091014/181ecec3/attachment.html 

From mikhailkozhevnikov at yandex.ru  Wed Oct 14 08:54:03 2009
From: mikhailkozhevnikov at yandex.ru (Kozhevnikov Mikhail)
Date: Wed, 14 Oct 2009 19:54:03 +0400
Subject: [cairo] windows fonts bug
Message-ID: <126901255535643@webmail107.yandex.ru>

Hi All,

There was a bug (see code and resulting picture attached) in cairo on Windows we've discussed in the thread "Toy text api, PNG, and magic numbers" some time ago. Jonathan Kew proposed an uncomplicated patch by Mozilla (http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/win32-cleartype-clipping.patch?raw=1) which does solve the problem. 

Why not include the patch in the next release?

I've verified that the bug persists in cairo 1.8.8.

I admit the problem occurs frequently only in some special cases and has several solutions, simplest one being to avoid using Windows fonts.

Best regards, 
Mikhail.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: magicnum.cpp
Url: http://lists.cairographics.org/archives/cairo/attachments/20091014/aa89cd60/attachment.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: magicnum.png
Type: image/png
Size: 6320 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091014/aa89cd60/attachment-0001.png 

From gerdusvanzyl at gmail.com  Wed Oct 14 08:51:38 2009
From: gerdusvanzyl at gmail.com (Gerdus van Zyl)
Date: Wed, 14 Oct 2009 17:51:38 +0200
Subject: [cairo] a question of cairo printer
In-Reply-To: <589551.42422.qm@web113109.mail.gq1.yahoo.com>
References: <589551.42422.qm@web113109.mail.gq1.yahoo.com>
Message-ID: <91882ea90910140851p4bff3485u42345a357fa623c3@mail.gmail.com>

Do you have a minimal test case you can show us? Do you use the windows
surface or windows printing surface backend? What version of cairo do you
use? Also check you are not using unconstrianed operations like paint
without clip.

~G


On Wed, Oct 14, 2009 at 5:14 PM, Liang Wang <bluepower1983 at yahoo.com> wrote:

> Hello, I am a software  engineer in china. We are developing a new product,
> but we experiencing a problem. When we use cairo transparency effect to draw
> graphics on text or graphics drawed by gdi, after printing, we found the
> effect of transparency is enable. The graphics drawed by cairo will cover
> the graphic drawed by gdi. But when we use that on a graphic drawed by
> cairo, after printing, it is correct. So, I wanna know why and how to
> resolve  this problem.
>
> I am looking forward to your reply as soon as possible.
> Thank you very much.
>
>
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091014/e98e137e/attachment.htm 

From david at bjorkevik.se  Wed Oct 14 08:36:50 2009
From: david at bjorkevik.se (=?ISO-8859-1?Q?David_Bj=F6rkevik?=)
Date: Wed, 14 Oct 2009 17:36:50 +0200
Subject: [cairo] a question of cairo printer
In-Reply-To: <589551.42422.qm@web113109.mail.gq1.yahoo.com>
References: <589551.42422.qm@web113109.mail.gq1.yahoo.com>
Message-ID: <4AD5F012.10005@bjorkevik.se>

Liang Wang wrote:
> Hello, I am a software  engineer in china. We are developing a new
> product, but we experiencing a problem. When we use cairo
> transparency effect to draw graphics on text or graphics drawed by
> gdi, after printing, we found the effect of transparency is enable.
> The graphics drawed by cairo will cover the graphic drawed by gdi.
> But when we use that on a graphic drawed by cairo, after printing, it
> is correct. So, I wanna know why and how to resolve  this problem.

You shouldn't mix cairo and non-cairo drawing operations on a printer
device context. Transparency will not work.

You have two options:
1. Rewrite your program to use cairo exclusively
2. Draw to a bitmap device context before printing. You should be able
to mix GDI and cairo, but be sure to calll cairo_surface_flush when
switching between drawing modes.

/David

From chris at chris-wilson.co.uk  Wed Oct 14 09:14:44 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Wed, 14 Oct 2009 17:14:44 +0100
Subject: [cairo] Whatever happened to the XCloseDisplay() hooks?
Message-ID: <1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk>


In cairo we maintain various per-screen caches that we need to reap when
the connection is closed, otherwise we are liable to return stale and
invalid data on new connections. (In particular the test suite will
crash, or on a good day just report an error, as it tries to use a new
connection that just happens to have been allocated at the same location
as the old one.)

For cairo-xlib we call XAddExtension() and thus have a callback on
XCloseDisplay(). There is no similar mechanism for xcb. Instead, as per
the renderutil, you seem to favour an explicit call to
xcb_render_util_disconnect() upon client disconnection, thus moving the
burden of work onto the client. Carl Worth has already complained about me
inflicting similar bookkeeping onto the user, and so I propose these
callbacks before I incur his wrath again.
-ickle

From chris at chris-wilson.co.uk  Wed Oct 14 09:14:45 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Wed, 14 Oct 2009 17:14:45 +0100
Subject: [cairo] [PATCH] Disconnect hooks.
In-Reply-To: <1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk>
References: <1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk>
Message-ID: <1255536885-3669-2-git-send-email-chris@chris-wilson.co.uk>

---
 src/xcb.h      |   14 ++++++++++++++
 src/xcb_conn.c |   33 +++++++++++++++++++++++++++++++--
 src/xcb_ext.c  |    9 +++++----
 src/xcbint.h   |    9 +++++++++
 4 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/src/xcb.h b/src/xcb.h
index f951276..be18b2f 100644
--- a/src/xcb.h
+++ b/src/xcb.h
@@ -395,6 +395,20 @@ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info);
  */
 void xcb_disconnect(xcb_connection_t *c);
 
+/**
+ * @brief Adds a callback to be called on disconnection.
+ * @param c: The connection.
+ * @param callback: The callback.
+ * @param closure: The data to be passed to the callback.
+ * @return 0 on failure, non 0 otherwise.
+ *
+ * Adds a callback that will be when the connection is closed.
+ */
+int xcb_add_disconnect_hook(xcb_connection_t *c,
+			    void (*callback) (xcb_connection_t *,
+					      void *closure),
+			    void (*closure));
+
 
 /* xcb_util.c */
 
diff --git a/src/xcb_conn.c b/src/xcb_conn.c
index 251d62e..34b8880 100644
--- a/src/xcb_conn.c
+++ b/src/xcb_conn.c
@@ -215,6 +215,7 @@ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info)
         return (xcb_connection_t *) &error_connection;
 
     c->fd = fd;
+    c->disconnect_hooks = NULL;
 
     if(!(
         set_fd_flags(fd) &&
@@ -236,8 +237,15 @@ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info)
 
 void xcb_disconnect(xcb_connection_t *c)
 {
-    if(c->has_error)
-        return;
+    if  (c == (xcb_connection_t *) &error_connection)
+	return;
+
+    while (c->disconnect_hooks != NULL) {
+	_xcb_hook *hook = c->disconnect_hooks;
+	c->disconnect_hooks = hook->next;
+	hook->callback (c, hook->closure);
+	free (hook);
+    }
 
     free(c->setup);
     close(c->fd);
@@ -252,6 +260,27 @@ void xcb_disconnect(xcb_connection_t *c)
     free(c);
 }
 
+int xcb_add_disconnect_hook(xcb_connection_t *c,
+			    void (*callback) (xcb_connection_t *,
+					      void *closure),
+			    void (*closure))
+{
+    _xcb_hook *hook;
+
+    if  (c == (xcb_connection_t *) &error_connection)
+	return 0;
+
+    hook = malloc (sizeof (_xcb_hook));
+    if (! hook)
+	return 0;
+
+    hook->callback = callback;
+    hook->closure = closure;
+    hook->next = c->disconnect_hooks;
+    c->disconnect_hooks = hook;
+    return 1;
+}
+
 /* Private interface */
 
 void _xcb_conn_shutdown(xcb_connection_t *c)
diff --git a/src/xcb_ext.c b/src/xcb_ext.c
index 68bb29b..d013781 100644
--- a/src/xcb_ext.c
+++ b/src/xcb_ext.c
@@ -62,10 +62,11 @@ static lazyreply *get_lazyreply(xcb_connection_t *c, xcb_extension_t *ext)
 
     lazyreply *data;
 
-    pthread_mutex_lock(&global_lock);
-    if(!ext->global_id)
-        ext->global_id = ++next_global_id;
-    pthread_mutex_unlock(&global_lock);
+    if(!ext->global_id) {
+	pthread_mutex_lock(&global_lock);
+	ext->global_id = ++next_global_id;
+	pthread_mutex_unlock(&global_lock);
+    }
 
     data = get_index(c, ext->global_id);
     if(data && data->tag == LAZY_NONE)
diff --git a/src/xcbint.h b/src/xcbint.h
index 154cca0..29ce018 100644
--- a/src/xcbint.h
+++ b/src/xcbint.h
@@ -172,6 +172,14 @@ void _xcb_ext_destroy(xcb_connection_t *c);
 
 /* xcb_conn.c */
 
+typedef struct _xcb_hook {
+    struct _xcb_hook *next;
+
+    void (*callback) (xcb_connection_t *connection,
+		      void *closure);
+    void *closure;
+} _xcb_hook;
+
 struct xcb_connection_t {
     int has_error;
 
@@ -187,6 +195,7 @@ struct xcb_connection_t {
     /* misc data */
     _xcb_ext ext;
     _xcb_xid xid;
+    _xcb_hook *disconnect_hooks;
 };
 
 void _xcb_conn_shutdown(xcb_connection_t *c);
-- 
1.6.4.3


From jamey at minilop.net  Wed Oct 14 12:17:19 2009
From: jamey at minilop.net (Jamey Sharp)
Date: Wed, 14 Oct 2009 12:17:19 -0700
Subject: [cairo] Whatever happened to the XCloseDisplay() hooks?
In-Reply-To: <200910141852.n9EIqWs3024002@murzim.cs.pdx.edu>
References: <1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk> 
	<200910141852.n9EIqWs3024002@murzim.cs.pdx.edu>
Message-ID: <e2ed954f0910141217l18ab58a6t58dbdaf63a7e6d70@mail.gmail.com>

I agree with the general sentiments of Bart's note here: libxcb
currently provides no callbacks under any circumstances, and I want to
see a very convincing argument before changing that. That isn't a
"no", just a request for more discussion.

Of course as Julien pointed out after I started composing this, we
can't have every library providing its own disconnect wrapper, so
Bart, I think your proposal can't work.

I'd argue in a different direction: higher layers should manage
caches. The cairo XCB surface constructors could take a
cairo-xcb-connection object instead of the xcb_connection_t. That
object would be constructed from an xcb_connection_t and contain any
caches you want. The caller can decide when to allocate and free that
association.

What nightmare arises if you take that approach?

Jamey

From jamey at minilop.net  Wed Oct 14 13:20:06 2009
From: jamey at minilop.net (Jamey Sharp)
Date: Wed, 14 Oct 2009 13:20:06 -0700
Subject: [cairo] Whatever happened to the XCloseDisplay() hooks?
In-Reply-To: <eaa105840910141243j75c69dccr673bdcfab4a2d01c@mail.gmail.com>
References: <1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk> 
	<200910141852.n9EIqWs3024002@murzim.cs.pdx.edu>
	<e2ed954f0910141217l18ab58a6t58dbdaf63a7e6d70@mail.gmail.com> 
	<eaa105840910141243j75c69dccr673bdcfab4a2d01c@mail.gmail.com>
Message-ID: <e2ed954f0910141320l88bb36fr28cd0b8b21fec603@mail.gmail.com>

On Wed, Oct 14, 2009 at 12:43 PM, Peter Harris <git at peter.is-a-geek.org> wrote:
> On Wed, Oct 14, 2009 at 3:17 PM, Jamey Sharp wrote:
>> I'd argue in a different direction: higher layers should manage
>> caches. The cairo XCB surface constructors could take a
>> cairo-xcb-connection object instead of the xcb_connection_t. That
>> object would be constructed from an xcb_connection_t and contain any
>> caches you want. The caller can decide when to allocate and free that
>> association.
>
> What if the app uses xcb_render_util directly? The
> cairo-xcb-connection destructor cannot safely call
> xcb_render_util_disconnect.

This is a red herring. Presumably xcb_render_util_disconnect isn't
usable for all the reasons we're discussing, so it needs to be fixed.
If the solution works for cairo, it ought to work for other libraries
as well, including renderutil and your planned atom bits.

So is there something fundamentally wrong with the idiom I suggested?

> If callbacks in libxcb proper are out of the question, ...

Well, they aren't, as I said. I'd just strongly prefer an alternative
if we can agree on a reasonable one. The general design principle is
"don't put anything in libxcb if it can be reasonably implemented in a
higher layer instead."

If the only choices are adding a magic xcb_aux_disconnect that
applications have to know to call, or adding callbacks to
xcb_disconnect directly, I think I'd rather put them in libxcb. But I
want my "tertium quid". :-)

Jamey

From tgriggs at cincom.com  Wed Oct 14 15:41:29 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Wed, 14 Oct 2009 15:41:29 -0700
Subject: [cairo] windows fonts bug
In-Reply-To: <126901255535643@webmail107.yandex.ru>
References: <126901255535643@webmail107.yandex.ru>
Message-ID: <B4581AC9-8564-449F-A9D3-74E54B103CBA@cincom.com>


On Oct 14, 2009, at 8:54 AM, Kozhevnikov Mikhail wrote:

> Hi All,
>
> There was a bug (see code and resulting picture attached) in cairo  
> on Windows we've discussed in the thread "Toy text api, PNG, and  
> magic numbers" some time ago. Jonathan Kew proposed an uncomplicated  
> patch by Mozilla (http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/win32-cleartype-clipping.patch?raw=1 
> ) which does solve the problem.

+1

--
Travis Griggs
tgriggs at cincom.com
"The dissenter is every human being at those moments of his life when  
he resigns momentarily from the herd and thinks for himself." - 
Archibald MacLeish, poet and librarian




From a.g.nienhuis at gmail.com  Wed Oct 14 16:24:14 2009
From: a.g.nienhuis at gmail.com (Arjen Nienhuis)
Date: Thu, 15 Oct 2009 01:24:14 +0200
Subject: [cairo] Overflow bug painting from PixBuf?
Message-ID: <11ddbd200910141624o167de224n26984e97f4bc7353@mail.gmail.com>

Hi,

I'm using cairo 1.8.8 and python to create some png files.

I load jpeg files with a gtk.gdk.PixbufLoader and use

ctx.translate(dst_x, dst_y)
ctx.scale(scale, scale)
gdk_ctx = gtk.gdk.CairoContext(ctx)
gdk_ctx.set_source_pixbuf(src_pixbuf, 0, 0)
ctx.paint()

This works fine until dst_x / scale > 32000. Then garbage is copied to
ctx. This also occurs with the PDF backend.

This means I cannot put a small thumbnail on the right side of an
image. (see attachment, the last photo is missing)

Is this a known bug? Is there anything I can do? Pre-scaling the
pixbuf might work.

Groeten, Arjen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12.png
Type: image/png
Size: 37979 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091015/e8992a5d/attachment-0001.png 

From chris at chris-wilson.co.uk  Wed Oct 14 16:47:09 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 15 Oct 2009 00:47:09 +0100
Subject: [cairo] [PATCH] [API] Support component-alpha.
Message-ID: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>

Within our code base we carried a few hacks to utilize the component
alpha capabilities of pixman, whilst not supporting the concept for our
own masks. Thus we were setting it upon the pixman_image_t that we
passed around through code that was blissfully unaware and indeed the
component-alpha property was forgotten (e.g. upgrading glyph masks).

The real issue is that without explicit support that a pattern carries
subpixel masking information, that information is lost when using that
pattern with composite. Again we can look at the example of compositing
a sub-pixel glyph mask onto a remote xlib surface for further failure.

So we need component-alpha support on patterns internally, so present
the same power to the users as well. For indeed, they may well be
dreaming of demonstrating sub-pixel geometry masks...

[This patch is hastily written and requires testing.]
---
 src/cairo-ft-font.c              |    5 ---
 src/cairo-gl-surface.c           |   45 ++++++++++++++++++++---------
 src/cairo-gstate.c               |    7 +---
 src/cairo-image-surface.c        |   58 ++++++++++++++++++++++++++++----------
 src/cairo-pattern.c              |   56 ++++++++++++++++++++++++++++++++++--
 src/cairo-scaled-font.c          |   11 ++++---
 src/cairo-types-private.h        |    1 +
 src/cairo-win32-font.c           |   10 ++----
 src/cairo-xlib-surface-private.h |    1 +
 src/cairo-xlib-surface.c         |   43 +++++++++++++++++++++++-----
 src/cairo.h                      |   22 ++++++++++++++
 src/cairoint.h                   |    1 +
 12 files changed, 198 insertions(+), 62 deletions(-)

diff --git a/src/cairo-ft-font.c b/src/cairo-ft-font.c
index 1c5edc1..02ab6cc 100644
--- a/src/cairo-ft-font.c
+++ b/src/cairo-ft-font.c
@@ -803,7 +803,6 @@ _get_bitmap_surface (FT_Bitmap		     *bitmap,
     int width, height, stride;
     unsigned char *data;
     int format = CAIRO_FORMAT_A8;
-    cairo_bool_t subpixel = FALSE;
 
     width = bitmap->width;
     height = bitmap->rows;
@@ -971,7 +970,6 @@ _get_bitmap_surface (FT_Bitmap		     *bitmap,
 	    data = data_rgba;
 	    stride = stride_rgba;
 	    format = CAIRO_FORMAT_ARGB32;
-	    subpixel = TRUE;
 	    break;
 	}
 	}
@@ -994,9 +992,6 @@ _get_bitmap_surface (FT_Bitmap		     *bitmap,
 	return (*surface)->base.status;
     }
 
-    if (subpixel)
-	pixman_image_set_component_alpha ((*surface)->pixman_image, TRUE);
-
     _cairo_image_surface_assume_ownership_of_data ((*surface));
 
     _cairo_debug_check_image_surface_is_defined (&(*surface)->base);
diff --git a/src/cairo-gl-surface.c b/src/cairo-gl-surface.c
index 8ebfbc0..39c8fcc 100644
--- a/src/cairo-gl-surface.c
+++ b/src/cairo-gl-surface.c
@@ -1342,20 +1342,37 @@ _cairo_gl_surface_composite (cairo_operator_t		  op,
 	    _cairo_gl_set_texture_surface (1, setup.mask.operand.texture.tex,
 					   mask_attributes);
 
-	    /* IN: dst.argb = src.argb * mask.aaaa */
-	    glTexEnvi (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_MODULATE);
-
-	    glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_RGB, GL_PREVIOUS);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_ALPHA, GL_PREVIOUS);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA);
-
-	    glTexEnvi (GL_TEXTURE_ENV, GL_SRC1_RGB, GL_TEXTURE1);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_SRC1_ALPHA, GL_TEXTURE1);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_ALPHA);
-	    glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, GL_SRC_ALPHA);
+	    if (mask_attributes.component_alpha == CAIRO_SINGLE_ALPHA) {
+		/* IN: dst.argb = src.argb * mask.aaaa */
+		glTexEnvi (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
+		glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE);
+		glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_MODULATE);
+
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_RGB, GL_PREVIOUS);
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_ALPHA, GL_PREVIOUS);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA);
+
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC1_RGB, GL_TEXTURE1);
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC1_ALPHA, GL_TEXTURE1);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_ALPHA);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, GL_SRC_ALPHA);
+	    } else {
+		/* IN: dst.argb = src.argb * mask.argb */
+		glTexEnvi (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
+		glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE);
+		glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_MODULATE);
+
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_RGB, GL_PREVIOUS);
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_ALPHA, GL_PREVIOUS);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA);
+
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC1_RGB, GL_TEXTURE1);
+		glTexEnvi (GL_TEXTURE_ENV, GL_SRC1_ALPHA, GL_TEXTURE1);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR);
+		glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, GL_SRC_ALPHA);
+	    }
 	    break;
 	}
     }
diff --git a/src/cairo-gstate.c b/src/cairo-gstate.c
index 6f58bcf..98e2205 100644
--- a/src/cairo-gstate.c
+++ b/src/cairo-gstate.c
@@ -999,12 +999,9 @@ _cairo_gstate_mask (cairo_gstate_t  *gstate,
     _cairo_gstate_copy_transformed_source (gstate, &source_pattern.base);
     _cairo_gstate_copy_transformed_mask (gstate, &mask_pattern.base, mask);
 
-    /* XXX: This optimization assumes that there is no color
-     * information in mask, so this will need to change if we
-     * support RENDER-style 4-channel masks.
-     */
     if (source_pattern.type == CAIRO_PATTERN_TYPE_SOLID &&
-	mask_pattern.type == CAIRO_PATTERN_TYPE_SOLID)
+	mask_pattern.type == CAIRO_PATTERN_TYPE_SOLID &&
+	mask_pattern.base.component_alpha == CAIRO_SINGLE_ALPHA)
     {
 	cairo_color_t combined;
 
diff --git a/src/cairo-image-surface.c b/src/cairo-image-surface.c
index 49ce7a5..06d9f3e 100644
--- a/src/cairo-image-surface.c
+++ b/src/cairo-image-surface.c
@@ -927,33 +927,61 @@ _cairo_image_surface_set_filter (cairo_image_surface_t *surface,
 }
 
 static cairo_status_t
-_cairo_image_surface_set_attributes (cairo_image_surface_t      *surface,
-				     cairo_surface_attributes_t *attributes,
-				     double xc, double yc)
+_cairo_image_surface_set_extend (cairo_image_surface_t *surface,
+				 cairo_extend_t extend)
 {
-    cairo_int_status_t status;
-
-    status = _cairo_image_surface_set_matrix (surface, &attributes->matrix,
-					      xc, yc);
-    if (unlikely (status))
-	return status;
+    pixman_repeat_t pixman_repeat;
 
-    switch (attributes->extend) {
+    switch (extend) {
     case CAIRO_EXTEND_NONE:
-        pixman_image_set_repeat (surface->pixman_image, PIXMAN_REPEAT_NONE);
+	pixman_repeat = PIXMAN_REPEAT_NONE;
 	break;
     case CAIRO_EXTEND_REPEAT:
-        pixman_image_set_repeat (surface->pixman_image, PIXMAN_REPEAT_NORMAL);
+	pixman_repeat = PIXMAN_REPEAT_NORMAL;
 	break;
     case CAIRO_EXTEND_REFLECT:
-        pixman_image_set_repeat (surface->pixman_image, PIXMAN_REPEAT_REFLECT);
+	pixman_repeat = PIXMAN_REPEAT_REFLECT;
 	break;
     case CAIRO_EXTEND_PAD:
-        pixman_image_set_repeat (surface->pixman_image, PIXMAN_REPEAT_PAD);
+	pixman_repeat = PIXMAN_REPEAT_PAD;
 	break;
     }
 
-    status = _cairo_image_surface_set_filter (surface, attributes->filter);
+    pixman_image_set_repeat (surface->pixman_image, pixman_repeat);
+    return CAIRO_STATUS_SUCCESS;
+}
+
+static cairo_status_t
+_cairo_image_surface_set_component_alpha (cairo_image_surface_t *surface,
+					  cairo_component_alpha_t ca)
+{
+    pixman_image_set_component_alpha (surface->pixman_image,
+				      ca != CAIRO_SINGLE_ALPHA);
+    return CAIRO_STATUS_SUCCESS;
+}
+
+static cairo_status_t
+_cairo_image_surface_set_attributes (cairo_image_surface_t      *surface,
+				     cairo_surface_attributes_t *attributes,
+				     double xc, double yc)
+{
+    cairo_int_status_t status;
+
+    status = _cairo_image_surface_set_matrix (surface, &attributes->matrix,
+					      xc, yc);
+    if (unlikely (status))
+	return status;
+
+    status = _cairo_image_surface_set_filter (surface, attributes->extend);
+    if (unlikely (status))
+	return status;
+
+    status = _cairo_image_surface_set_extend (surface, attributes->extend);
+    if (unlikely (status))
+	return status;
+
+    status = _cairo_image_surface_set_component_alpha (surface,
+						       attributes->component_alpha);
     if (unlikely (status))
 	return status;
 
diff --git a/src/cairo-pattern.c b/src/cairo-pattern.c
index 1888d83..7a8e8b0 100644
--- a/src/cairo-pattern.c
+++ b/src/cairo-pattern.c
@@ -130,6 +130,8 @@ _cairo_pattern_init (cairo_pattern_t *pattern, cairo_pattern_type_t type)
 
     pattern->filter    = CAIRO_FILTER_DEFAULT;
 
+    pattern->component_alpha = CAIRO_SINGLE_ALPHA;
+
     cairo_matrix_init_identity (&pattern->matrix);
 }
 
@@ -1523,6 +1525,7 @@ _cairo_pattern_acquire_surface_for_gradient (const cairo_gradient_pattern_t *pat
 	attr->matrix = matrix;
 	attr->extend = pattern->base.extend;
 	attr->filter = CAIRO_FILTER_NEAREST;
+	attr->component_alpha = pattern->base.component_alpha;
 
 	*out = &image->base;
 
@@ -1619,6 +1622,7 @@ _cairo_pattern_acquire_surface_for_gradient (const cairo_gradient_pattern_t *pat
     cairo_matrix_init_identity (&attr->matrix);
     attr->extend = repeat ? CAIRO_EXTEND_REPEAT : CAIRO_EXTEND_NONE;
     attr->filter = CAIRO_FILTER_NEAREST;
+    attr->component_alpha = pattern->base.component_alpha;
 
     return status;
 }
@@ -1763,6 +1767,7 @@ NOCACHE:
     cairo_matrix_init_identity (&attribs->matrix);
     attribs->extend = CAIRO_EXTEND_REPEAT;
     attribs->filter = CAIRO_FILTER_NEAREST;
+    attribs->component_alpha = pattern->base.component_alpha;
 
     status = CAIRO_STATUS_SUCCESS;
 
@@ -1849,6 +1854,9 @@ _cairo_pattern_is_opaque (const cairo_pattern_t *abstract_pattern)
 {
     const cairo_pattern_union_t *pattern;
 
+    if (abstract_pattern->component_alpha)
+	return FALSE;
+
     pattern = (cairo_pattern_union_t *) abstract_pattern;
     switch (pattern->base.type) {
     case CAIRO_PATTERN_TYPE_SOLID:
@@ -1958,6 +1966,7 @@ _cairo_pattern_acquire_surface_for_surface (const cairo_surface_pattern_t   *pat
     attr->matrix = pattern->base.matrix;
     attr->extend = pattern->base.extend;
     attr->filter = _cairo_pattern_analyze_filter (&pattern->base, &pad);
+    attr->component_alpha = pattern->base.component_alpha;
 
     attr->x_offset = attr->y_offset = tx = ty = 0;
     if (_cairo_matrix_is_integer_translation (&attr->matrix, &tx, &ty)) {
@@ -2378,11 +2387,10 @@ _cairo_pattern_acquire_surfaces (const cairo_pattern_t	    *src,
     /* If src and mask are both solid, then the mask alpha can be
      * combined into src and mask can be ignored. */
 
-    /* XXX: This optimization assumes that there is no color
-     * information in mask, so this will need to change when we
-     * support RENDER-style 4-channel masks. */
     if (src->type == CAIRO_PATTERN_TYPE_SOLID &&
-	mask && mask->type == CAIRO_PATTERN_TYPE_SOLID)
+	mask &&
+	mask->component_alpha == CAIRO_SINGLE_ALPHA &&
+	mask->type == CAIRO_PATTERN_TYPE_SOLID)
     {
 	cairo_color_t combined;
 	cairo_solid_pattern_t *src_solid = (cairo_solid_pattern_t *) src;
@@ -2648,6 +2656,8 @@ _cairo_pattern_hash (const cairo_pattern_t *pattern)
 				  &pattern->filter, sizeof (pattern->filter));
 	hash = _cairo_hash_bytes (hash,
 				  &pattern->extend, sizeof (pattern->extend));
+	hash = _cairo_hash_bytes (hash,
+				  &pattern->component_alpha, sizeof (pattern->component_alpha));
     }
 
     switch (pattern->type) {
@@ -2799,6 +2809,9 @@ _cairo_pattern_equal (const cairo_pattern_t *a, const cairo_pattern_t *b)
     if (a->type != b->type)
 	return FALSE;
 
+    if (a->component_alpha != b->component_alpha)
+	return FALSE;
+
     if (a->type != CAIRO_PATTERN_TYPE_SOLID) {
 	if (memcmp (&a->matrix, &b->matrix, sizeof (cairo_matrix_t)))
 	    return FALSE;
@@ -3079,6 +3092,41 @@ cairo_pattern_get_radial_circles (cairo_pattern_t *pattern,
     return CAIRO_STATUS_SUCCESS;
 }
 
+/**
+ * cairo_pattern_set_component_alpha:
+ * @pattern: a #cairo_pattern_t
+ * @value: Enable use of per-component alpha mask?
+ *
+ * When used as a mask a pattern with content CAIRO_CONTENT_COLOR,
+ * i.e. a pattern with red, green, blue components as well as an
+ * alpha component (which may be implicitly 1) the value used for the
+ * mask may either be per-component or the single alpha value.
+ *
+ * The default is to use the single alpha channel for masking. Using
+ * per-component alpha may be used in conjunction with sub-pixel
+ * antialiasing to improve clarity on pixellated displays, e.g. LCDs.
+ *
+ * Since: 1.10
+ **/
+void
+cairo_pattern_set_component_alpha (cairo_pattern_t *pattern,
+				   cairo_component_alpha_t ca)
+{
+    if (unlikely (pattern->status))
+	return;
+
+    pattern->component_alpha = ca;
+}
+
+cairo_component_alpha_t
+cairo_pattern_get_component_alpha (cairo_pattern_t *pattern)
+{
+    if (unlikely (pattern->status))
+	return CAIRO_SINGLE_ALPHA;
+
+    return pattern->component_alpha;
+}
+
 void
 _cairo_pattern_reset_static_data (void)
 {
diff --git a/src/cairo-scaled-font.c b/src/cairo-scaled-font.c
index 48451a6..357ce46 100644
--- a/src/cairo-scaled-font.c
+++ b/src/cairo-scaled-font.c
@@ -2170,6 +2170,8 @@ _cairo_scaled_font_show_glyphs (cairo_scaled_font_t	*scaled_font,
 	    }
 
 	    _cairo_pattern_init_for_surface (&mask_pattern, mask);
+	    if (mask_format == CAIRO_FORMAT_ARGB32)
+		mask_pattern.base.component_alpha = CAIRO_COMPONENT_ALPHA;
 
 	    status = _cairo_surface_composite (CAIRO_OPERATOR_ADD,
 					       &white_pattern.base,
@@ -2204,6 +2206,8 @@ _cairo_scaled_font_show_glyphs (cairo_scaled_font_t	*scaled_font,
 
 	    _cairo_pattern_init_for_surface (&glyph_pattern,
 					     &glyph_surface->base);
+	    if (mask_format == CAIRO_FORMAT_ARGB32)
+		glyph_pattern.base.component_alpha = CAIRO_COMPONENT_ALPHA;
 
 	    status = _cairo_surface_composite (CAIRO_OPERATOR_ADD,
 					       &white_pattern.base,
@@ -2223,12 +2227,9 @@ _cairo_scaled_font_show_glyphs (cairo_scaled_font_t	*scaled_font,
 	}
     }
 
-    /* XXX ComponentAlpha needs to be a cairo pattern property! */
-    if (mask_format == CAIRO_FORMAT_ARGB32) {
-	pixman_image_set_component_alpha (((cairo_image_surface_t*) mask)->
-					  pixman_image, TRUE);
-    }
     _cairo_pattern_init_for_surface (&mask_pattern, mask);
+    if (mask_format == CAIRO_FORMAT_ARGB32)
+	mask_pattern.base.component_alpha = CAIRO_COMPONENT_ALPHA;
 
     status = _cairo_surface_composite (op, pattern, &mask_pattern.base,
 				       surface,
diff --git a/src/cairo-types-private.h b/src/cairo-types-private.h
index 068c261..0e216f3 100644
--- a/src/cairo-types-private.h
+++ b/src/cairo-types-private.h
@@ -350,6 +350,7 @@ struct _cairo_pattern {
     cairo_matrix_t		matrix;
     cairo_filter_t		filter;
     cairo_extend_t		extend;
+    cairo_component_alpha_t	component_alpha;
 };
 
 struct _cairo_solid_pattern {
diff --git a/src/cairo-win32-font.c b/src/cairo-win32-font.c
index 71bad77..8e9e44d 100644
--- a/src/cairo-win32-font.c
+++ b/src/cairo-win32-font.c
@@ -1438,10 +1438,6 @@ _cairo_win32_scaled_font_show_glyphs (void			*abstract_font,
 		_invert_argb32_mask (tmp_surface);
 
 	    mask_surface = &tmp_surface->base;
-
-	    /* XXX: Hacky, should expose this in cairo_image_surface */
-	    pixman_image_set_component_alpha (((cairo_image_surface_t *)tmp_surface->image)->pixman_image, TRUE);
-
 	} else {
 	    mask_surface = _compute_a8_mask (tmp_surface);
 	    cairo_surface_destroy (&tmp_surface->base);
@@ -1455,6 +1451,10 @@ _cairo_win32_scaled_font_show_glyphs (void			*abstract_font,
 	 * destination
 	 */
 	_cairo_pattern_init_for_surface (&mask, mask_surface);
+	cairo_surface_destroy (mask_surface);
+
+	if (scaled_font->quality == CLEARTYPE_QUALITY) {
+	    mask.base.component_alpha = CAIRO_COMPONENT_ALPHA;
 
 	status = _cairo_surface_composite (op, pattern,
 					   &mask.base,
@@ -1467,8 +1467,6 @@ _cairo_win32_scaled_font_show_glyphs (void			*abstract_font,
 
 	_cairo_pattern_fini (&mask.base);
 
-	cairo_surface_destroy (mask_surface);
-
 	return status;
     }
 }
diff --git a/src/cairo-xlib-surface-private.h b/src/cairo-xlib-surface-private.h
index 92107e7..b40ee59 100644
--- a/src/cairo-xlib-surface-private.h
+++ b/src/cairo-xlib-surface-private.h
@@ -95,6 +95,7 @@ struct _cairo_xlib_surface {
     XRenderPictFormat *xrender_format;
     cairo_filter_t filter;
     cairo_extend_t extend;
+    cairo_component_alpha_t component_alpha;
     XTransform xtransform;
 
     uint32_t a_mask;
diff --git a/src/cairo-xlib-surface.c b/src/cairo-xlib-surface.c
index f3ebc9d..91e4113 100644
--- a/src/cairo-xlib-surface.c
+++ b/src/cairo-xlib-surface.c
@@ -1549,11 +1549,11 @@ _cairo_xlib_surface_set_filter (cairo_xlib_surface_t *surface,
 }
 
 static cairo_status_t
-_cairo_xlib_surface_set_repeat (cairo_xlib_surface_t *surface,
-				cairo_extend_t extend)
+_cairo_xlib_surface_set_repeat (cairo_xlib_surface_t	*surface,
+				cairo_extend_t		 extend,
+				unsigned long		*mask,
+				XRenderPictureAttributes *pa)
 {
-    XRenderPictureAttributes pa;
-    unsigned long	     mask;
     int repeat;
 
     if (surface->extend == extend)
@@ -1583,12 +1583,26 @@ _cairo_xlib_surface_set_repeat (cairo_xlib_surface_t *surface,
 	return CAIRO_INT_STATUS_UNSUPPORTED;
     }
 
-    mask = CPRepeat;
-    pa.repeat = repeat;
+    *mask |= CPRepeat;
+    pa->repeat = repeat;
 
-    XRenderChangePicture (surface->dpy, surface->src_picture, mask, &pa);
     surface->extend = extend;
+    return CAIRO_STATUS_SUCCESS;
+}
+
+static cairo_status_t
+_cairo_xlib_surface_set_component_alpha (cairo_xlib_surface_t *surface,
+					 cairo_component_alpha_t ca,
+					 unsigned long		*mask,
+					 XRenderPictureAttributes *pa)
+{
+    if (surface->component_alpha == ca)
+	return CAIRO_STATUS_SUCCESS;
 
+    *mask |= CPComponentAlpha;
+    pa->component_alpha = !! ca;
+
+    surface->component_alpha = ca;
     return CAIRO_STATUS_SUCCESS;
 }
 
@@ -1599,6 +1613,8 @@ _cairo_xlib_surface_set_attributes (cairo_xlib_surface_t	    *surface,
 				    double			     yc)
 {
     cairo_int_status_t status;
+    XRenderPictureAttributes pa;
+    unsigned long mask = 0;
 
     _cairo_xlib_surface_ensure_src_picture (surface);
 
@@ -1607,7 +1623,14 @@ _cairo_xlib_surface_set_attributes (cairo_xlib_surface_t	    *surface,
     if (unlikely (status))
 	return status;
 
-    status = _cairo_xlib_surface_set_repeat (surface, attributes->extend);
+    status = _cairo_xlib_surface_set_repeat (surface, attributes->extend,
+					     &mask, &pa);
+    if (unlikely (status))
+	return status;
+
+    status = _cairo_xlib_surface_set_component_alpha (surface,
+						      attributes->component_alpha,
+						      &mask, &pa);
     if (unlikely (status))
 	return status;
 
@@ -1615,6 +1638,9 @@ _cairo_xlib_surface_set_attributes (cairo_xlib_surface_t	    *surface,
     if (unlikely (status))
 	return status;
 
+    if (mask)
+	XRenderChangePicture (surface->dpy, surface->src_picture, mask, &pa);
+
     return CAIRO_STATUS_SUCCESS;
 }
 
@@ -2969,6 +2995,7 @@ found:
     surface->depth = depth;
     surface->filter = CAIRO_FILTER_NEAREST;
     surface->extend = CAIRO_EXTEND_NONE;
+    surface->component_alpha = CAIRO_SINGLE_ALPHA;
     surface->xtransform = identity;
 
     surface->clip_region = NULL;
diff --git a/src/cairo.h b/src/cairo.h
index c239dea..a91c824 100644
--- a/src/cairo.h
+++ b/src/cairo.h
@@ -2374,6 +2374,28 @@ cairo_pattern_set_filter (cairo_pattern_t *pattern, cairo_filter_t filter);
 cairo_public cairo_filter_t
 cairo_pattern_get_filter (cairo_pattern_t *pattern);
 
+/**
+ * cairo_component_alpha_t:
+ * @CAIRO_SINGLE_ALPHA: Use the alpha component when masking
+ * @CAIRO_COMPONENT_ALPHA: Use the component value when masking
+ *
+ * #cairo_component_alpha_t is used to indicate which channel to use
+ * when masking with the pattern.  See cairo_pattern_set_component_alpha()
+ * for how this affects masking with a particular pattern.
+ */
+typedef enum cairo_component_alpha {
+    CAIRO_SINGLE_ALPHA = 0,
+    CAIRO_COMPONENT_ALPHA,
+} cairo_component_alpha_t;
+
+cairo_public void
+cairo_pattern_set_component_alpha (cairo_pattern_t *pattern,
+				   cairo_component_alpha_t ca);
+
+cairo_public cairo_component_alpha_t
+cairo_pattern_get_component_alpha (cairo_pattern_t *pattern);
+
+
 cairo_public cairo_status_t
 cairo_pattern_get_rgba (cairo_pattern_t *pattern,
 			double *red, double *green,
diff --git a/src/cairoint.h b/src/cairoint.h
index 8706488..464cf33 100644
--- a/src/cairoint.h
+++ b/src/cairoint.h
@@ -874,6 +874,7 @@ typedef struct _cairo_surface_attributes {
     cairo_matrix_t matrix;
     cairo_extend_t extend;
     cairo_filter_t filter;
+    cairo_component_alpha_t component_alpha;
     int		   x_offset;
     int		   y_offset;
     void	   *extra;
-- 
1.6.4.3


From chris at chris-wilson.co.uk  Wed Oct 14 17:01:49 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 15 Oct 2009 01:01:49 +0100
Subject: [cairo] Overflow bug painting from PixBuf?
In-Reply-To: <11ddbd200910141624o167de224n26984e97f4bc7353@mail.gmail.com>
References: <11ddbd200910141624o167de224n26984e97f4bc7353@mail.gmail.com>
Message-ID: <1255564733-sup-75@broadwater.alporthouse.com>

Excerpts from Arjen Nienhuis's message of Thu Oct 15 00:24:14 +0100 2009:
> I'm using cairo 1.8.8 and python to create some png files.

[snip]

> This works fine until dst_x / scale > 32000. Then garbage is copied to
> ctx. This also occurs with the PDF backend.
> 
> This means I cannot put a small thumbnail on the right side of an
> image. (see attachment, the last photo is missing)
> 
> Is this a known bug? Is there anything I can do? Pre-scaling the
> pixbuf might work.

It is a known bug, a limitation of the fixed-point 16.16 matrix that we
use to transform images with pixman. In cairo-1.9.2, we have a
workaround that takes advantage of the fact that we can do the
translation independently of the matrix that extends our operating range
a bit (but still leaves worse than desired inaccuracies). In short, try
1.9.2, it's probably good enough for the task at hand.

Hope this helps, and you have fun with cairo!
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From BrandonThomas08 at gmail.com  Wed Oct 14 19:29:59 2009
From: BrandonThomas08 at gmail.com (Brandon Thomas)
Date: Wed, 14 Oct 2009 22:29:59 -0400
Subject: [cairo] librsvg and cairo on Windows
In-Reply-To: <3dae054a0910131609l7734d991wb9cd6970fbdfcfef@mail.gmail.com>
References: <3dae054a0910131609l7734d991wb9cd6970fbdfcfef@mail.gmail.com>
Message-ID: <3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>

So after doing a bit of digging on finding a SVG parser and something
to render it I have come across cairo. But cario, as I understand it,
can't actually read svg files, but can simply output to them. But that
apparently is were librsvg comes in and seem to be the standard paring
w/ cairo. Does anyone know where I can get a a development build of
the latest stable version of librsvg for windows? The librsvg website
doesn't have a version that is easy to build on Windows, they all use
makefiles, and I don't know how to use makefiles in Visual Studio.
Also I didn't see anywhere that already compiled it to a dll and
provided the headers in a nice development build of librsvg like the
gtk site provides for cairo. So does anyone know where I can get the
latest dll of librsvg ?or have any pointers on how to build it myself?

Or if what I am saying is complete nonsense, please say so.

Thanks

From cairouser at yahoo.com  Wed Oct 14 20:40:45 2009
From: cairouser at yahoo.com (cu)
Date: Wed, 14 Oct 2009 23:40:45 -0400
Subject: [cairo] windows fonts bug
In-Reply-To: <126901255535643@webmail107.yandex.ru>
References: <126901255535643@webmail107.yandex.ru>
Message-ID: <4AD699BD.3090505@yahoo.com>

Thanks for the patch - will apply asap (of course now I have to remember
to update all local copies of Cairo, oops).

I'd gladly dump windows fonts somehow and use the same fonts I have on
Mac, but can FreeType fonts be used under Windows? What would I have to
do to use them in Cairo?


Kozhevnikov Mikhail wrote:
> Hi All,
>
> There was a bug (see code and resulting picture attached) in cairo on Windows we've discussed in the thread "Toy text api, PNG, and magic numbers" some time ago. Jonathan Kew proposed an uncomplicated patch by Mozilla (http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/win32-cleartype-clipping.patch?raw=1) which does solve the problem. 
>
> Why not include the patch in the next release?
>
> I've verified that the bug persists in cairo 1.8.8.
>
> I admit the problem occurs frequently only in some special cases and has several solutions, simplest one being to avoid using Windows fonts.
>
> Best regards, 
> Mikhail.
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From tml at iki.fi  Thu Oct 15 02:54:08 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Thu, 15 Oct 2009 12:54:08 +0300
Subject: [cairo] windows fonts bug
In-Reply-To: <4AD699BD.3090505@yahoo.com>
References: <126901255535643@webmail107.yandex.ru> <4AD699BD.3090505@yahoo.com>
Message-ID: <c9b6d9a50910150254u5c0b01b2he8c71b03ba86f7d7@mail.gmail.com>

> can FreeType fonts be used under Windows? What would I have to
> do to use them in Cairo?

I don't know what you mean with "FreeType fonts", FreeType is a
library that can use fonts in a lot of different formats, so
practically *any* font you come across these days is a "FreeType font"
(including those provided with, and 3rd-party ones commonly used on,
Windows).

But I am just nitpicking, I guess what you are asking is whether cairo
can be built on Windows to include the FreeType font backend, and the
answer is yes, sure. Of course you will then need a build of FreeType
and fontconfig, too, to build cairo against.

(The builds of cairo I provide for use in the GTK+ stack on Windows
nowadays do include the FreeType font backend, this is a recent change
in my policy. See
http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies . The
latest cairo, fontconfig, freetype, libpng and zlib packages there
should form a consistent stack. But I don't claim these builds would
have any "official" status, feel free to ignore them.)

--tml

From tml at iki.fi  Thu Oct 15 03:13:53 2009
From: tml at iki.fi (Tor Lillqvist)
Date: Thu, 15 Oct 2009 13:13:53 +0300
Subject: [cairo] librsvg and cairo on Windows
In-Reply-To: <3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>
References: <3dae054a0910131609l7734d991wb9cd6970fbdfcfef@mail.gmail.com> 
	<3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>
Message-ID: <c9b6d9a50910150313m474d459fncf9cdbd6fdc5c2e8@mail.gmail.com>

> The librsvg website
> doesn't have a version that is easy to build on Windows, they all use
> makefiles, and I don't know how to use makefiles in Visual Studio.
> Also I didn't see anywhere that already compiled it to a dll and
> provided the headers in a nice development build of librsvg like the
> gtk site provides for cairo.

Check http://ftp.gnome.org/pub/gnome/binaries/win32/librsvg/2.26/ .

The librsvg DLL there depends on quite a bunch of other DLLs:
libcairo-2.dll, libgio-2.0-0.dll, libglib-2.0-0.dll,
libgobject-2.0-0.dll,  libgdk_pixbuf-2.0-0.dll, libcroco-0.6-3.dll,
libgsf-1-114.dll, libxml2-2.dll, libpango-1.0-0.dll and
libpangocairo-1.0-0.dll. And those then add dependency on
libfontconfig-1.dll, freetype6.dll, libpng12-0.dll and zlib1.dll.
Hopefully I got them all.

To get all these you need the corresponding packages from the same
site, i.e. cairo, glib, gtk+, libcroco, libgsf, libxml2, pango,
fontconfig, freetype, libpng and zlib. Hope I didn't miss any. Quite a
load, and I certainly admit that manually finding out what all you
need to download, and keeping a look for new versions as they are
released and built and provided, is a chore. Some kind of package
management would be nice.

There is no .lib (import library) for librsvg there, though. But it is
relatively trivial to build one such yourself: run link -dump -exports
on the DLL and edit the output into a .def file. (The librsvg API is
luckily a purely functional one, as far as I know, no pesky DATA
exports involved.) Then run lib on the .def file to produce a .lib
file, i.e. import library. How to do this should be explained in the
Microsoft documentation.

It might also work to just copy the librsvg-2.dll.a to rsvg-2.lib
(that would be the logical name for it I think). As far as I know the
import library format produced by the GNU ("mingw") tool-chain is
usable also by Microsoft's tools. (Not necessarily the other way
around, though. If one uses newer versions of Microsoft's tool-chain
to produce a .lib import library I think that one can't use that .lib
import library with GNU ld.) (And this is for an API that is plain C;
for C++ one cannot mix compilers, and that is intentional.)

--tml

From chris at chris-wilson.co.uk  Thu Oct 15 05:15:50 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 15 Oct 2009 13:15:50 +0100
Subject: [cairo] Overflow bug painting from PixBuf?
In-Reply-To: <11ddbd200910150507o1a923746idc7ba49522e04eb7@mail.gmail.com>
References: <11ddbd200910141624o167de224n26984e97f4bc7353@mail.gmail.com>
	<1255564733-sup-75@broadwater.alporthouse.com>
	<11ddbd200910150507o1a923746idc7ba49522e04eb7@mail.gmail.com>
Message-ID: <1255608884-sup-2587@broadwater.alporthouse.com>

Excerpts from Arjen Nienhuis's message of Thu Oct 15 13:07:41 +0100 2009:
> Hmm, after an hour of dpkg, easy_install, git clone and all sorts of
> dependency problems I finally got:
> 
> cairo.cairo_version_string() == '1.9.2'
> 
> and then I got a segfault.

Well it shouldn't be doing that! Can you grab a backtrace as it is
hopefully a trivial build/system issue.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From a.g.nienhuis at gmail.com  Thu Oct 15 06:22:05 2009
From: a.g.nienhuis at gmail.com (Arjen Nienhuis)
Date: Thu, 15 Oct 2009 15:22:05 +0200
Subject: [cairo] Overflow bug painting from PixBuf?
In-Reply-To: <1255608884-sup-2587@broadwater.alporthouse.com>
References: <11ddbd200910141624o167de224n26984e97f4bc7353@mail.gmail.com>
	<1255564733-sup-75@broadwater.alporthouse.com>
	<11ddbd200910150507o1a923746idc7ba49522e04eb7@mail.gmail.com>
	<1255608884-sup-2587@broadwater.alporthouse.com>
Message-ID: <11ddbd200910150622m1867823cg97da6a6924b56b43@mail.gmail.com>

It's probably because i'm doing this:

http://cairographics.org/freetypepython/

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2669774 in cairo_set_font_face () from /usr/lib/libcairo.so.2
(gdb) bt
#0  0x00007ffff2669774 in cairo_set_font_face () from /usr/lib/libcairo.so.2
#1  0x00007fffea682bec in ffi_call_unix64 () from
/usr/lib/python2.6/lib-dynload/_ctypes.so
#2  0x00007fffea6822d3 in ffi_call () from
/usr/lib/python2.6/lib-dynload/_ctypes.so
#3  0x00007fffea67cd64 in _CallProc () from
/usr/lib/python2.6/lib-dynload/_ctypes.so
#4  0x00007fffea674bf7 in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so
#5  0x000000000041d6e7 in PyObject_Call ()
#6  0x00000000004a199c in PyEval_EvalFrameEx ()
#7  0x00000000004a40e0 in PyEval_EvalCodeEx ()
#8  0x00000000004a245f in PyEval_EvalFrameEx ()
#9  0x00000000004a40e0 in PyEval_EvalCodeEx ()
#10 0x00000000004a245f in PyEval_EvalFrameEx ()
#11 0x00000000004a40e0 in PyEval_EvalCodeEx ()
#12 0x00000000004a41b2 in PyEval_EvalCode ()
#13 0x00000000004b5d5e in PyImport_ExecCodeModuleEx ()
#14 0x00000000004b7bee in ?? ()
#15 0x00000000004b8a23 in ?? ()
#16 0x00000000004b8caf in ?? ()
#17 0x00000000004b924c in ?? ()
#18 0x00000000004b98b4 in PyImport_ImportModuleLevel ()
#19 0x000000000049c1cb in ?? ()
#20 0x000000000041d6e7 in PyObject_Call ()
#21 0x000000000049cd8f in ?? ()
#22 0x000000000049fc8e in PyEval_EvalFrameEx ()
#23 0x00000000004a40e0 in PyEval_EvalCodeEx ()
#24 0x00000000004a41b2 in PyEval_EvalCode ()
#25 0x00000000004b5d5e in PyImport_ExecCodeModuleEx ()
#26 0x00000000004b7bee in ?? ()
#27 0x00000000004b8a23 in ?? ()
#28 0x00000000004b8caf in ?? ()
#29 0x00000000004b924c in ?? ()
#30 0x00000000004b98b4 in PyImport_ImportModuleLevel ()
#31 0x000000000049c1cb in ?? ()
#32 0x000000000041d6e7 in PyObject_Call ()
#33 0x000000000049cd8f in ?? ()
#34 0x000000000049fc8e in PyEval_EvalFrameEx ()
#35 0x00000000004a40e0 in PyEval_EvalCodeEx ()
#36 0x00000000004a41b2 in PyEval_EvalCode ()
#37 0x00000000004c33a0 in PyRun_FileExFlags ()
#38 0x00000000004c3564 in PyRun_SimpleFileExFlags ()
#39 0x0000000000418ab7 in Py_Main ()
#40 0x00007ffff6fd0abd in __libc_start_main () from /lib/libc.so.6
#41 0x0000000000417ca9 in _start ()


On Thu, Oct 15, 2009 at 2:15 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Excerpts from Arjen Nienhuis's message of Thu Oct 15 13:07:41 +0100 2009:
>> Hmm, after an hour of dpkg, easy_install, git clone and all sorts of
>> dependency problems I finally got:
>>
>> cairo.cairo_version_string() == '1.9.2'
>>
>> and then I got a segfault.
>
> Well it shouldn't be doing that! Can you grab a backtrace as it is
> hopefully a trivial build/system issue.
> -ickle
> --
> Chris Wilson, Intel Open Source Technology Centre
>

From britten at caris.com  Thu Oct 15 06:44:57 2009
From: britten at caris.com (Ian Britten)
Date: Thu, 15 Oct 2009 10:44:57 -0300
Subject: [cairo] NO_HINTING problems with custom FT_Face
In-Reply-To: <4AD5E6D0.60807@caris.com>
References: <4AD5E6D0.60807@caris.com>
Message-ID: <4AD72759.7070607@caris.com>

Ian Britten wrote:
> I was hoping that someone could help me get to the root of a problem
> I'm having when using my custom FreeType font driver via Cairo.
   [ snip ]
> Problem:
> - When I create+draw my text upright and use load_flags=0, the text
>    draws as expected.  However, when I use load_flags=FT_LOAD_NO_HINTING,
>    my text no longer draws.
   [ snip ]

Ok, here's some more info that I hope will illuminate something for
someone:
Attached are two stack traces, showing the calls between my call to
cairo_show_glyphs() until my slotLoadCB() is called, to load the
requested glyph.  The two traces are for the two cases where
load_flags=0 (DEFAULT.txt), and where load_flags=FT_LOAD_NO_HINTING
(NOHINTING.txt).  DEFAULT.txt is the case that works.

The flow through the Cairo code seems to be the same until Cairo
calls FT_Load_Glyph().  In the working case (DEFAULT.txt), the
code goes through some extra FT calls (Autohinter?) while in the
non-working case, the FT_Load_Glyph() calls my slotLoadCB().

I should note that my slotLoadCB() is actually called twice from
cairo_show_glyphs() - Once as shown in the attachments, and a
second time via _cairo_surface_old_show_glyphs_draw_func()/etc.
Since the parameters to my slotLoadCB() were the same in both
cases, I didn't bother to include the second traces here.  However
I can, if requested.

So, is anyone familiar with this FT autohinter stuff, and does
it's presence/absence alter what Cairo does with glyphs?  Might
I be in an untested (broken?) code path (ie: Rendering text with
hinting turned off)?  Is there any other info I could offer to
help get to the bottom of this?

Many thanks for any help...
Ian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DEFAULT.txt
Url: http://lists.cairographics.org/archives/cairo/attachments/20091015/4cedcb74/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: NOHINTING.txt
Url: http://lists.cairographics.org/archives/cairo/attachments/20091015/4cedcb74/attachment-0001.txt 

From freddie at witherden.org  Thu Oct 15 09:12:27 2009
From: freddie at witherden.org (Freddie Witherden)
Date: Thu, 15 Oct 2009 17:12:27 +0100
Subject: [cairo] librsvg and cairo on Windows
In-Reply-To: <c9b6d9a50910150313m474d459fncf9cdbd6fdc5c2e8@mail.gmail.com>
References: <3dae054a0910131609l7734d991wb9cd6970fbdfcfef@mail.gmail.com>
	<3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>
	<c9b6d9a50910150313m474d459fncf9cdbd6fdc5c2e8@mail.gmail.com>
Message-ID: <200910151712.27824.freddie@witherden.org>

On Thursday 15 October 2009 11:13:53 Tor Lillqvist wrote:
> The librsvg DLL there depends on quite a bunch of other DLLs:
> libcairo-2.dll, libgio-2.0-0.dll, libglib-2.0-0.dll,
> libgobject-2.0-0.dll,  libgdk_pixbuf-2.0-0.dll, libcroco-0.6-3.dll,
> libgsf-1-114.dll, libxml2-2.dll, libpango-1.0-0.dll and
> libpangocairo-1.0-0.dll. And those then add dependency on
> libfontconfig-1.dll, freetype6.dll, libpng12-0.dll and zlib1.dll.
> Hopefully I got them all.
> 
> To get all these you need the corresponding packages from the same
> site, i.e. cairo, glib, gtk+, libcroco, libgsf, libxml2, pango,
> fontconfig, freetype, libpng and zlib. Hope I didn't miss any. Quite a
> load, and I certainly admit that manually finding out what all you
> need to download, and keeping a look for new versions as they are
> released and built and provided, is a chore. Some kind of package
> management would be nice.

Not a nice set of dependencies to satisfy, IMO.

My understanding from your original message is that you want to parse and 
render SVG files. If this is the case then I highly recommend you look into 
using Qt - http://qt.nokia.com/products ; which like Cairo and friends is LGPL 
licensed.

Don't let the fact that it is a full-blown widget toolkit put you off :) The 
SVG module (QtSVG) is reasonably full-featured and extremely easy to use. In 
addition the Qt source as downloaded has *no* external dependencies, compiles 
under both MinGW and MSVC and can easily be statically compiled. Many build-
time configurations are provided. On my desktop I have full-blown statically 
linked Qt applications than come in at under 1.5MiB. (And yes, they do make 
use of the SVG functionality for icon rendering.)

It is worth pointing out that Qt is C++ based which may or may not pose a 
problem.

This approach will significantly reduce the size of your application and reduce 
the amount of manual dependency management you need to perform.

rsvg is great if you're writing a GTK+ based desktop application, but a 
nightmare if you just want to add SVG functionality to a cross-platform 
application. 

Regards, Freddie.

From zeng.shixin at gmail.com  Thu Oct 15 09:14:02 2009
From: zeng.shixin at gmail.com (Shixin Zeng)
Date: Thu, 15 Oct 2009 11:14:02 -0500
Subject: [cairo] librsvg and cairo on Windows
In-Reply-To: <3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>
References: <3dae054a0910131609l7734d991wb9cd6970fbdfcfef@mail.gmail.com>
	<3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>
Message-ID: <7a9157a40910150914h486f6d7fw2fc076760145756a@mail.gmail.com>

Hi,

I have a repositories on github to build these modules on windows with
MSVC, based on scons, with which I've successfully compiled all
modules for librsvg, except for fontconfig, xft2.

If you look at my repositories, you'll find a scons branch for each
module, just checkout that branch. and you'll be ready to go.

#prerequisite
1. pkg-config, you must have a working pkg-config in your path
2. scons, which is written in Python, so you need python
3. Perl, gtk build system uses perl a lot
4. the site-init.py from http://github.com/zsx/super-totem

The command to compile, say, cairo, would be:
#cd cairo
#scons --site-dir=where_your_site_init_py_is PREFIX=your_prefix DEBUG=1
#scons --site-dir=where_your_site_init_py_is PREFIX=your_prefix DEBUG=1 install

With this method, you can merge upstream changes, if my repository is
not new enough.

Best Regards

Shixin Zeng



On Wed, Oct 14, 2009 at 9:29 PM, Brandon Thomas
<BrandonThomas08 at gmail.com> wrote:
> So after doing a bit of digging on finding a SVG parser and something
> to render it I have come across cairo. But cario, as I understand it,
> can't actually read svg files, but can simply output to them. But that
> apparently is were librsvg comes in and seem to be the standard paring
> w/ cairo. Does anyone know where I can get a a development build of
> the latest stable version of librsvg for windows? The librsvg website
> doesn't have a version that is easy to build on Windows, they all use
> makefiles, and I don't know how to use makefiles in Visual Studio.
> Also I didn't see anywhere that already compiled it to a dll and
> provided the headers in a nice development build of librsvg like the
> gtk site provides for cairo. So does anyone know where I can get the
> latest dll of librsvg ?or have any pointers on how to build it myself?
>
> Or if what I am saying is complete nonsense, please say so.
>
> Thanks
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>

From zeng.shixin at gmail.com  Thu Oct 15 09:18:00 2009
From: zeng.shixin at gmail.com (Shixin Zeng)
Date: Thu, 15 Oct 2009 11:18:00 -0500
Subject: [cairo] librsvg and cairo on Windows
In-Reply-To: <7a9157a40910150914h486f6d7fw2fc076760145756a@mail.gmail.com>
References: <3dae054a0910131609l7734d991wb9cd6970fbdfcfef@mail.gmail.com>
	<3dae054a0910141929j1bd6a77p2f2614cbae0060c4@mail.gmail.com>
	<7a9157a40910150914h486f6d7fw2fc076760145756a@mail.gmail.com>
Message-ID: <7a9157a40910150918g7e4f9a86s1ce87b857c7bbe4d@mail.gmail.com>

Best Regards

Shixin Zeng



On Thu, Oct 15, 2009 at 11:14 AM, Shixin Zeng <zeng.shixin at gmail.com> wrote:
> Hi,
>
> I have a repositories on github to build these modules on windows with
> MSVC, based on scons, with which I've successfully compiled all
> modules for librsvg, except for fontconfig, xft2.
>
> If you look at my repositories, you'll find a scons branch for each
> module, just checkout that branch. and you'll be ready to go.
>
> #prerequisite
> 1. pkg-config, you must have a working pkg-config in your path
> 2. scons, which is written in Python, so you need python
> 3. Perl, gtk build system uses perl a lot
> 4. the site-init.py from http://github.com/zsx/super-totem
>
> The command to compile, say, cairo, would be:
> #cd cairo
> #scons --site-dir=where_your_site_init_py_is PREFIX=your_prefix DEBUG=1
> #scons --site-dir=where_your_site_init_py_is PREFIX=your_prefix DEBUG=1 install
>

forgot to specify perl PATH:
#scons --site-dir=where_your_site_init_py_is PREFIX=your_prefix
DEBUG=1 PERL=C:\Perl\bin\perl.exe

I just assumed that perl was installed in the default directory, in
which case it could be left over.

> With this method, you can merge upstream changes, if my repository is
> not new enough.
>
> Best Regards
>
> Shixin Zeng
>
>
>
> On Wed, Oct 14, 2009 at 9:29 PM, Brandon Thomas
> <BrandonThomas08 at gmail.com> wrote:
>> So after doing a bit of digging on finding a SVG parser and something
>> to render it I have come across cairo. But cario, as I understand it,
>> can't actually read svg files, but can simply output to them. But that
>> apparently is were librsvg comes in and seem to be the standard paring
>> w/ cairo. Does anyone know where I can get a a development build of
>> the latest stable version of librsvg for windows? The librsvg website
>> doesn't have a version that is easy to build on Windows, they all use
>> makefiles, and I don't know how to use makefiles in Visual Studio.
>> Also I didn't see anywhere that already compiled it to a dll and
>> provided the headers in a nice development build of librsvg like the
>> gtk site provides for cairo. So does anyone know where I can get the
>> latest dll of librsvg ?or have any pointers on how to build it myself?
>>
>> Or if what I am saying is complete nonsense, please say so.
>>
>> Thanks
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>>
>

From cworth at cworth.org  Thu Oct 15 11:48:18 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 15 Oct 2009 11:48:18 -0700
Subject: [cairo] Whatever happened to the XCloseDisplay() hooks?
In-Reply-To: <e2ed954f0910141217l18ab58a6t58dbdaf63a7e6d70@mail.gmail.com>
References: <1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk>
	<200910141852.n9EIqWs3024002@murzim.cs.pdx.edu>
	<e2ed954f0910141217l18ab58a6t58dbdaf63a7e6d70@mail.gmail.com>
Message-ID: <1255632222-sup-3367@yoom.home.cworth.org>

Excerpts from Jamey Sharp's message of Wed Oct 14 12:17:19 -0700 2009:
> I'd argue in a different direction: higher layers should manage
> caches. The cairo XCB surface constructors could take a
> cairo-xcb-connection object instead of the xcb_connection_t. That
> object would be constructed from an xcb_connection_t and contain any
> caches you want. The caller can decide when to allocate and free that
> association.
> 
> What nightmare arises if you take that approach?

Extra objects that the user has to juggle. That's what I want to avoid
in cairo.

The way things work in all current supported cairo surfaces is that
the user talks to the native backend API, (Xlib, Quartz, etc.), to
create a native "surface" and then calls a cairo-backend specific API
to create a cairo_surface_t from that.

Your proposals calls for the user of cairo-xcb to have an additional
cairo-wrapped object that the user must manage with its own lifetime
constraints, etc.

To me, that just makes cairo-xcb harder to use than any other cairo
backend. So I'd much prefer that any additional object necessary here
be created and managed by cairo itself, entirely transparent to the
user.

And so far, the callback approach is the only means I've seen proposed
for that.

-Carl

PS. For what it's worth: I fought hard the first time callbacks were
proposed for cairo too. I finally relented and the callbacks have
really worked out just fine so far.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091015/3b0fee0b/attachment.pgp 

From cworth at cworth.org  Thu Oct 15 11:57:36 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 15 Oct 2009 11:57:36 -0700
Subject: [cairo] [Xcb] Whatever happened to the XCloseDisplay() hooks?
In-Reply-To: <200910142119.n9ELJlrC026731@murzim.cs.pdx.edu>
References: <e2ed954f0910141320l88bb36fr28cd0b8b21fec603@mail.gmail.com>
	<1255536885-3669-1-git-send-email-chris@chris-wilson.co.uk>
	<200910141852.n9EIqWs3024002@murzim.cs.pdx.edu>
	<e2ed954f0910141217l18ab58a6t58dbdaf63a7e6d70@mail.gmail.com>
	<eaa105840910141243j75c69dccr673bdcfab4a2d01c@mail.gmail.com>
	<200910142119.n9ELJlrC026731@murzim.cs.pdx.edu>
Message-ID: <1255632576-sup-3416@yoom.home.cworth.org>

Excerpts from Barton C Massey's message of Wed Oct 14 14:19:47 -0700 2009:
> Cairo is built with a really simple model: if you opened it,
> you close it.  I don't think I get why having both XCB and
> xcb_render_util be built on this same model is somehow a
> design defect.

Yes, but in cairo we did end up adding lifetime-management callbacks
for one specific case: cairo_set_user_data, (and other _set_user_data
calls).

What that looks like is this:

    /**                                                                             
     * cairo_destroy_func_t:                                                        
     * data: The data element being destroyed.                                     
     *                                                                              
     * cairo_destroy_func_t the type of function which is called when a            
     * data element is destroyed. It is passed the pointer to the data              
     * element and should free any memory and resources allocated for it.           
     **/
    typedef void (*cairo_destroy_func_t) (void *data);

    /**                                                                             
     * cairo_user_data_key_t:                                                       
     * unused: not used; ignore.                                                   
     *                                                                              
     * cairo_user_data_key_t is used for attaching user data to cairo              
     * data structures.  The actual contents of the struct is never used,           
     * and there is no need to initialize the object; only the unique               
     * address of a cairo_data_key_t object is used.  Typically, you               
     * would just use the address of a static cairo_data_key_t object.
     **/
    typedef struct _cairo_user_data_key {
        int unused;
    } cairo_user_data_key_t;

    cairo_status_t
    cairo_set_user_data (cairo_t                     *cr,
                         const cairo_user_data_key_t *key,
                         void                        *user_data,
                         cairo_destroy_func_t         destroy);

I fought the inclusion of the destroy callback for a long time on a
"callbacks are evil basis", but I eventually relented.

And pretty much all the authors of bindings for cairo have found this
essential. They end up needing to make little "wrapper objects" around
cairo's native objects and need a tight association between the two
with synchronized lifetime management.

I'm actually surprised you haven't had binding authors require the
same thing for XCB yet. (Or maybe it's different since you instead
generate their bindings in their language rather than wrapping the C
implementation?)

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091015/ed2eada5/attachment.pgp 

From cworth at cworth.org  Thu Oct 15 16:34:18 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 15 Oct 2009 16:34:18 -0700
Subject: [cairo] [cairo-announce] cairo snapshot 1.9.4 now available
Message-ID: <1255649244-sup-6905@yoom.home.cworth.org>

A new cairo snapshot 1.9.4 is now available.

This is a slightly more "raw" snapshot than many we've done in the
past. But it's been over 4 months since the last cairo snapshot, and
cairo internals have been shaken up quite a bit since then, (thanks,
Chris!).

We hope that most of the fallout from the big rewrites is over now,
(such as a recent fix to prevent WebKit from misrendering images). But
we are aware that some bugs still remain, (such as issues with images
in PDF output as well as PS and EPS page sizes).

As you encounter any major bugs, please ensure that the bugs are
listed as dependencies of the following tracker bug so that we will be
sure to fix them before the cairo 1.10 release:

http://bugs.freedesktop.org/show_bug.cgi?id=cairo-1.10

And of course, as with all cairo snapshots (as opposed to "releases"),
any API that is new in cairo 1.9 compared to 1.8 is subject to
change. (For example, I'm not totally happy with the
cairo_gl_surface_create functions so they might be changing.)

Please have fun with cairo, everyone!

-Carl

Where to obtain cairo 1.9.4
---------------------------
  http://cairographics.org/snapshots/cairo-1.9.4.tar.gz

    which can be verified with:

    http://cairographics.org/snapshots/cairo-1.9.4.tar.gz.sha1
    144d80cf01758a0f048b149b4c54aa792e401ae3  cairo-1.9.4.tar.gz

    http://cairographics.org/snapshots/cairo-1.9.4.tar.gz.sha1.asc
    (signed by Carl Worth)

  Additionally, a git clone of the source tree:

  git clone git://git.cairographics.org/git/cairo

    will include a signed 1.9.4 tag which points to a commit named:
    ad6334b9870c63e641b531d6e910c084b587d0f9

    which can be verified with:
    git verify-tag 1.9.4

    and can be checked out with a command such as:
    git checkout -b build 1.9.4

Changes from cairo 1.9.2 to cairo 1.9.4
---------------------------------------
Adrian Johnson (28):
      Fix PDF pattern embedding
      PDF: Don't round pattern y location to an integer
      [pdf] Add support for the extra blend modes
      PDF: Fix glyph 0 in toUnicode stream when using user fonts
      PDF: Only Type 3 fonts should include glyph 0 in /ToUnicode
      Ensure Type 3 fonts do not add a .notdef glyph
      Ensure Type 3 fonts do not use the name .notdef in the PS encoding
      PDF: Fix bug when when embedding surfaces
      PDF: Avoid using patterns when painting surfaces with EXTEND_NONE
      PDF: Avoid using patterns when filling a surface with EXTEND_NONE
      Update ref images
      PDF: Reset alpha to 1.0 before painting a surface
      PDF: Flush operators before writing to the PDF stream
      PDF: Ensure operator is selected before painting surface
      Use _WIN32 to check for win32 mutex
      Add WINVER defines to cairo-mutex-impl-privaye.h
      Fix compiler error on cygwin
      Fix compiler warnings in win32-surface
      Make win32 fonts work in EMF files created by win32-printing
      win32-printing: Allow GDI CTM with scale < 1 to be set
      win32-printing: fix meta surface pattern regression caused by bed2701e
      win32-printing: correct the use of the CAIRO_HAS_WIN32_FONT #ifdef
      Add EPS test
      PS: Add DocumentMedia/PageMedia DSC comments
      PS: Use standard page size names for some common sizes
      Fix truetype subset crash
      PDF: Fix regression caused by 1ae5a419
      PDF: Fix regression caused by 1ae5a419

Andrea Canciani (2):
      [quartz] Fix one more compile error
      [quartz] Compile fix for show_glyphs

Behdad Esfahbod (4):
      [utils] Remove unused code
      [build] Fix typo
      [build] Remove bogus warning that we require at least one native font backend
      Set LC_ALL=C instead of LANG=C

Benjamin Otte (11):
      Use new pixman extended blend operators
      [xlib] Add support for new operators
      [xlib] DO_XCOPYAREA and DO_XTILE optimizations break with Window source
      [image] Move setting of is_clear to _create_with_pixman_format()
      [image] Return cairo_bool_t from _pixman_format_to_masks
      [xlib] Handle case in draw_image() where pixman format is not RGB
      [image] Fix masks computation for BGRx format
      [xlib] Handle 24bpp formats during dithering
      [xlib] Set proper bpp when computing format from masks
      [API] Make _cairo_meta_surface_replay() private again
      [test] Add clip-device-offset

Carl Worth (12):
      Increment version to 1.9.3 after the 1.9.2 snapshot.
      Makefile: Fix two typos preventing doc-publish from working
      Add new test: curve-to-as-line-to
      Merge branch 'master' of git.cairographics.org:/git/cairo
      Revert "[spline] Treat a straight spline as degenerate."
      Revert "[path] Convert straight curve-to to line-to"
      Mark curve-to-as-line-to as XFAIL for PS backend.
      NEWS: Update with correct data for 1.9.4 snapshot
      Remove stale references to non-existant reference images.
      Update version to 1.9.4
      Mark in-fill-empty-trapezoid as an XFAIL test.
      Add mising images to REFERENCE_IMAGES list.

Carlos Garcia Campos (17):
      [test] Use poppler_page_render with a transparent surface
      [test] Remove PDF reference images for paint-source-alpha
      [test] Remove PDF reference images for paint-with-alpha
      [test] Remove PDF reference images for scale-source-surface-paint
      [test] Update argb32 pdf reference image for clip-operator
      [test] Update pdf reference image for filter-nearest-offset
      [test] Update pdf reference image for filter-nearest-transformed
      [test] Update pdf reference image for text-transform
      [test] Update argb32 and rgb24 pdf reference image for text-pattern
      [test] Update pdf reference image for surface-pattern
      [test] Update argb32 and rgb24 pdf reference image for mask
      [test] Add pdf reference image for mask-transformed-image
      [test] Add pdf reference image for rotate-image-surface-paint
      [test] Mark all smask tests as XFAIL for pdf
      [test] Update argb32 pdf reference image for trap-clip
      [configure] Bump pixman dependency
      [build] Fix a typo in configure.ac

Chris Wilson (452):
      [gl] Add EGL target
      [boilerplate] Export cairo_boilerplate_get_image_target()
      [boilerplate] Make array of targets const.
      [test] Add cairo-test-trace
      [perf] Mention cairo-perf-compare-backends in the README
      [test] Code review after sleep
      [test] Never, ever, blame a crashing test on external factors.
      [script] Disable compilation of examples
      [trace] Handle wrapping python
      [trace] Strip absolute path off name when profiling
      [surface] Mark cairo_surface_show_page() with begin-modification
      [surface] Give ownership of the snapshot to the snapshotter.
      [util] Disable default build of font-view
      [test] Remove dlmalloc
      [configure] Check for shm_open()
      [test] Disable compilation of cairo-test-trace without shm_open()
      [test] Need SOURCE when copying image data
      [test] Minor tweak to cairo-test-trace
      [configure] Rephrase warning message for disabling core features.
      [trace] Add sticky bit to (system-wide) trace output dir
      Expose _cairo_null_surface_create() via a test surface
      Missing header file for cairo-test-null-surface.
      [region] Add PLT entry for cairo_region_create_rectangles()
      [perf] Report iteration count
      [perf] Report errors during replays
      [cairo] Remove instance of 'return free()'
      [NEWS] Add release notes from 1.8.8
      [clip] Avoid copying region within  _cairo_clip_intersect_region()
      [clip] During _clip() limit the extracted traps to the current clip extents
      [clip] Missing {} (coding style)
      [xlib] Improve GC caching efficacy
      [analysis] Restore nops for the analysis null surface
      [test] Move calls to the getters from out of the innermost loops.
      [scaled-font-subset] Check for matching font-face implementors
      [test] Add the sha1sum of the required fonts
      [scaled-font] Check the MRU font before resolving the implementor
      [svg] Break circular snapshot reference by explicit finish
      [pattern] Add _cairo_pattern_fini_snapshot
      [ft] Substitute twin if there are no fonts
      [trace] Change the threshold at which pixel data is immediately copied
      [script] Report line number
      [perf] Report line of error during trace
      [trace] Prevent a child process from writing to the same file
      [boilerplate] Missing static on pdf user data key.
      [xlib] Remove redundant code to query a xrender_format from a visual
      [test] Experiment with reference targets
      [test] Add group-clip
      [cairo] Offset the current path when pushing/popping groups.
      [test] Add cairo-test-trace to .gitignore
      [test] Fix the image compare
      [perf] Show speedup/slowdownn labels on graph
      [perf] Add a non-build mode to graph
      [perf] Need to version surface types
      [perf] Force rebuild if make fails
      [boilerplate] Implement a reference xlib surface
      [atomic] Silence compiler warnings by defining an intptr_t
      [cairo] Trivial code tidy
      [pdf] Restore original surface size after emitting group mask
      [test] Add group-unaligned
      [test] Remove invalid smask PDF reference images
      [test] Remove broken PDF reference images for push-group
      [ft] Cache the resolved font face
      [perf] Enable the null-backend for trace replays.
      [gstate] Avoid temporary allocation for transformed patterns
      [cairo] Mark cr->status guard as unlikely
      [cairo] Report true error via pattern from cairo_pop_group()
      [script] Use setjmp exception handling during scanning
      [test] Disable fallback16 testing
      [boilerplate] Propagate original error from create_from_png()
      [script] Reuse glyph advance cache over multiple invocations
      [trace] Compile fix for --enable-script
      [script] Enable error handling for recursive scanners
      [test] Timeout support for tests
      [pattern] Mark _cairo_pattern_nil as static
      [test] Only run fallback-resolution for enabled targets
      [ft] Correct reference counting for implementation font face
      [perf] Enable trace directory recursion.
      [xlib] Remove redundant checks for src_picture==None
      [boilerplate] Only include null-test-surface >= cairo-1.9.3
      [perf] Exclude the xlib-reference target from cairo-perf
      [perf] Enable cairo-perf-trace in cairo-perf-diff
      [perf] Unbreak cairo-perf-diff builder
      [perf] Fix use-after-free when retrieving error line number
      [surface] Expose a SURFACE_TYPE_MISMATCH nil object
      [surface] Allocate temporary region on stack
      [test] Record trace to an in-memory meta-surface
      [test-meta] Lazily allocate image
      [test-meta] Initialize image
      [script] Trim some excess verbage
      Export meta-surface
      [script] Insert spaces around '<<' and '>>'
      [script] Add missing include <string.h>
      [trace] Remove a few transient pattern def/undef
      [meta] Copy extents on snapshotting.
      [meta] Cache replays when used as a pattern source
      [surface] Refactor meta-surface clone
      [script] Prototypical binary translator
      [boilerplate] Read whole RGB lines at a time
      [any2ppm] Choose a more appropriate format for the replay content
      [script] Fix the trivial errors running the test suite
      [script] Tidy dict construction for glyphs
      [boilerpate] Move target definition to backends.
      Remove the defunct test-meta surface
      [boilerplate] Add missing header file.
      [test] Rename some structures within cairo-test-trace
      [path] Evaluate is_box && is_region during construction
      [path] Add path watch debugging
      [path] Use cairo_list_t instead of open-coding its own
      [path] Don't include current-point in hash
      [test] Update reference images for gs 8.64
      [test] Sanitise REFERENCE_IMAGES
      [test] Track XFAIL using expected results stored as xfail.png
      [cairo] Remove trailing spaces in comments.
      [script] Extended blend mode support.
      [pdf] Silence copmiler.
      [glitz] Extended blend mode support
      [directfb] Silence compiler warnings.
      [test] Reconstruct REFERENCE_IMAGES
      [perf] Add cairo-traces to .gitignore
      [boilerplate] Add make-...-constructors to .gitignore
      Fix build under distcheck
      [xlib] Enable Render support for the extended PDF operators
      Add OpenVG backend.
      [test] Add a simplified CLEAR test.
      Compile fixes for mingw32.
      Add a jhbuild moduleset.
      [test] Misidentification of XFAIL as NEW
      [test] Fallback to comparing the base image references
      [test] Summarise tests that fail during the preamble.
      [build] Use ${CC} as the default value for CC_FOR_BUILD
      [build] And export CC_FOR_BUILD so that we can actually use it!
      [perf] Search multiple directories for traces
      [perf] Include trace comparison in html output
      [perf] Don't override CAIRO_TRACE_DIR in cairo-perf-diff
      Merge commit 'anholt/gl'
      [gl] Constrain image sources to max texture size
      [gl] Construct a dummy window for the initial context
      [gl] Avoid temporary allocation of pixman trapezoids
      [gl] Remove dead code.
      [gl] Whitespace
      [gl] Use QUADS for drawing fill_rectangles() not TRIFAN
      Merge commit 'anholt/gl-span-renderer'
      [gl] Another whitespace pass.
      [gl] Apply pixel sample bias for spans
      [gl] Add warning about missing hook for XCloseDisplay().
      [gl] Copy font options from image backend.
      [gl] Update reference images
      [NEWS] Add stub for OpenGL.
      [gl] Enable GL backend for cairo-perf-trace
      [vg] Compile fixes for EGL boilerplate
      [perf] Add a simple report printer.
      [gl] Do not use unchecked GL v1.5 features
      [gl] Simplify the common CLEAR of a surface
      Remove clip handling from generic surface layer.
      [drm] Add an accelerated image surface.
      [test] clip representation is no longer surface dependent
      [script] Decompress font sources
      [perf] Compare performance against most recent tag.
      [perf] Specify html file on cmdline instead of redirecting all output
      [scaled-font] Skip empty glyphs
      [scaled-font] cairo_scaled_font_glyph_extents() initialise extents
      [test] Trap SIGFPE
      [test] Fix use of uninitialized widths.
      [test] Extend radial gradients to check r2 < r1
      [xlib] Check workqueue before taking the display mutex
      [script] mark scan_read() inline
      [image] Discard redundant clears
      [boilerplate] Fix compilation against old revisions (as old as 1.9.2!)
      [pdf] Eliminate redundant whole-page clip.
      [script] Fix reference to font source after transferring to mmap
      [spline] Treat a straight spline as degenerate.
      [path] Convert straight curve-to to line-to
      Add a simple rectangle tree (rtree) implementation
      [xlib] Fast-path the likely case of retrieving a known xrender_format
      [test] Overlapping glyphs
      [paginated] Propagate error return during finish.
      [rtree] Merge the common unpin_and_evict_unused() routine
      [xlib] Add a timely reminder to ensure that bugs are properly filed.
      [gl] Switch to using the common rtree implementation.
      [gl] Actually remove the glyph from the rtree on scaled_font_fini
      [test] Add degenerate-curve-to
      [path] Remove the erroneous conversion of a 'zero-length' curve-to
      [test] Add timeouts around finishing and converting surfaces to images.
      [script] Add cvi, cvr, mod
      [test] Wrap yet another call to get_image_surface() inside a timeout.
      [perf] Avoid NULL derefs on broken result files.
      [gl] Unthaw font along contended path.
      [gl] Separate out supported operator check.
      [gl] Move check for vertex buffer support to individual operations.
      [gl] Only unlock the glyph cache when full.
      [gl] Fallback for overlapping glyphs.
      [gl] Render glyphs to an intermediate mask as opposed to falling back.
      [gl] Trim glyphs to surface/clip extents.
      [gl] Disable the EXTEND_REFLECT convertor
      [gl] Replace DrawPixels with TexSubImage
      [gl] Cache texture snapshots.
      [gl] Fixup unbounded regions after spans
      [test] Yet another bug in curve-to as line-to.
      [path] Remove the broken rel-curve-to as line-to
      [path] Fix iter to handle circular list of buffers
      [perf] Add another stroking micro-benchmark
      [perf] Remove the warning about failing to open a directory
      [perf] Check output
      [perf] Correct typo in long-lines.c
      [perf] Fix the asymmetry in long lines
      [perf] Add a single shot long-lines
      [perf] Add a more complex fill, a set of rings
      [perf] Change the order of slowdowns.
      [perf] Print min_ticks in report
      [xlib] Disable extended repeat modes if RENDER < 0.10
      [xlib] Use server-side gradients.
      [boilerplate] Update fallbacks after disabling RENDER
      [boilerplate] Conditionally tweak the xlib surface
      [gl] Return status from _render_glyphs()
      [spans] Emit empty rows.
      Revert "[gl] Fixup unbounded regions after spans"
      [test] Add clip-text
      [test] Add clip-fill.
      [gl] Use scissors rather than allocating a temporary depth buffer.
      Merge branch 'gl-glyph-cache'
      [gl] Refresh clip-operator ref.
      [directfb] Conditionally use DSPF_BGR555
      [boilerplate/test] Convert make-*-constructors to shell
      [configure] Also check for libiberty.h
      [surface] Protect against the user setting a fallback resolution of 0.
      [perf] Calibrate tests to run for at least 2 seconds
      [matrix] Use hypot()
      [path] Extend identical lines.
      [build] Configure switch to disable atomics
      [pattern] Invalid access beyond end of freed-pool
      [perf] Compare drawing random curves
      [trace] Only write the 4 byte length to the stream
      [trace] Whitespace
      [gl] Move hidden cairo_gl_surface_create() proto to header
      [trace] Close the dictionary before font
      [script] Extend csi-replay to show how to use a single surface
      [script] Check for failure to store the glyph cache
      [script] Ensure strings are nul terminated
      [quartz] Attempt to fix compile errors
      [script] Handle translation of compressed strings.
      [scaled-font] Update API documentation
      [quartz] Use the implementation font-face not the associated
      [surface] Check for a NULL snapshot
      [xlib] Rewrite UNSUPPORTED() avoiding gcc-ism
      [qt] Fix compilation
      [test] Exit on first failure '-x'
      [test] Attempt to automatically detect running under gdb
      [test] Remove misleading code/comments from a1-image-sample
      [perf] Add clipped modes to dragon
      [perf] Reset the path after each spiral
      [perf] Add spiral strokes
      [perf] Support objdir!=srcdir in cairo-perf-diff
      [perf] Add a box mode to spiral
      [perf] Fix unaligned-clip
      [perf] Add charting utility
      [perf] Remove cpuset warning for cairo-perf-trace
      [perf] Reset global caches after every trace
      [perf] Match directory names
      [test] Minor tweak of ft-text-vertical-layout
      Eliminate self-intersecting strokes.
      [traps] Compute extents on demand.
      [traps] Increase exponential expansion factor.
      [tessellator] Remove the skiplist for the active edges
      [tessellator] Use a priority queue for the events
      [fallback] Avoid going through traps for trivial regions.
      [clip] Use special-purpose fill_to_region()
      [tessellator] Special case rectilinear tessellation
      [fill] Short-circuit extents on an empty path.
      [clip] Use the rectilinear tessellator
      [freelist] Lazy initialisation of pools
      [fallback] Avoid tessellating empty polygons
      [util] Show total edge length in show-edges
      [polygon] Amalgamate collinear edges
      [test] Stress the intersection handling by feeding spans/traps random curves
      [clip] Eliminate redundant clips
      [gstate] Discard trivial all-clipped regions
      [fill] Early check for empty path/polygon
      traps-as-spans
      [clip] Use geometric clipping for unaligned clips
      [clip] Combine directly onto target
      [slope] Inline _cairo_slope_init()
      [polygon] Return status from path ops
      [fill] Use trivial rectilinear_to_traps
      [debug] Path printer
      [path] Discard redundant line-to
      [path] Eliminate redundant line-to before a close
      [script] Fix list handling during font destruction
      [script] Preserve '{}' whilst translating
      [script] Use a compact representation for horizontal offsets between glyphs
      [pattern] Ignore matrix/filter/extend when comparing solids
      [script] Hide the implicit CLEAR for similar surfaces
      [script] Suppress resetting stroke-style elements after matrix switch
      [script] Store the current stroke matrix
      [script] A little utility to convert a trace into a trace
      [script] Off-by-one in allocation of string length.
      [script] Handle zero-length strings
      [gstate] Convert simple mask() into a paint()
      [trace] Emit an 'index' for an undefined surface
      [clip] Cache intermediate clip masks.
      [stroke] Only mark traps as having intersection if non-empty.
      [trace] Fix emission of similar (track operands)
      [script] Introduce cairo_script_context_t
      [script] Read from a FILE stream
      [script] Wrap snapshot.
      [script] Garbage collect contexts on context switch
      [script] Emit surface content
      [script] Track scaled-font
      [tessellate] Rectangular special case
      [clip] Use the rectangular tessellator to extract boxes
      [build] Add options for warning about bad casts
      [script] recursive active (type3 glyphs)
      Fix errors found by clang
      [script] Correct emission of get_target() for a popped context
      Introduce cairo_tee_surface_t
      Add 'flight-data-recorder' utility.
      [matrix] Improve bbox finding for translation matrix
      [wrapper] Always copy clip
      [meta] Missing status check
      [script] Apply device offset when replaying meta surface
      Add cairo-sphinx utility for regression analysis
      Add xml surface
      [fallback] Reduce paint + clipmask to fill
      [build] Remove -Wcast-align
      [test] Update REFERENCE_IMAGES
      [configure] Choose a better name for the 'temporary' egl iterator
      [win32] Trust the clipping code to trim roi to our surface
      [cairoint.h] Add missing cairo_private to debug prototypes.
      [qt] Discard impossible status return from path construction
      [gl] Use common ARRAY_LENGTH macro
      [gl] Simplify acquire_dest_image()
      [gl] Use spans for trapezois.
      [script] Support running on cairo-1.8
      [pattern] Ensure that no repeated pattern is clipped
      [win32] Compiler warnings
      [win32] Initialize clip_region
      [win32] Use the system scaled_font_done
      [scaled-font] Remove assert from cairo_scled_font_create()
      [script] Conditionalise the build
      [boilerplate] Runtime library check
      [test] Implicit close
      [fallback] Include implicit closes in the check for rectilinear paths
      [path] Handle the implicit close for path_fixed_is_box()
      [stroke] Handle degenerate stroke extents
      [scaled-font] Eliminate intermediate path when tracing glyphs
      [path-fixed] Distinguish cw and ccw boxes
      [test] Add clip-stroke
      [clip] Fix refleak of previous clipping surfaces.
      [scaled-font] Refleak on error path.
      [ft] Improve error path handling.
      [scaled-font] Fix implementation-face refleak
      [path] Return the canonical box.
      [script] Fix use of freed list
      Update reference images
      [script] Implement invert
      [test] Add rotated clip.
      [clip] Pass in destination offset for combining with clip-mask
      [clip] Apply surface offset when combining with clip mask
      [clip] Correctly compute a geometric mask for a rectilinear + arbitrary
      Use the more generic is_box when doing simple extent checks
      Merge branch 'stroke-with-spans'
      [bo-rectangular] Fix assertion failure with insertion sort
      [perf] Trim outliers from chart
      [pattern] Remove unused hidden symbol for cairo_pattern_status()
      [tee] Rename 'append' to 'add' and add symmetric 'remove'
      Compiler warnings
      [path] Standalone header-compilation
      [boilerplate] Use xlib as fallback reference for xcb
      [ps/pdf] Trim patterns to operation extents
      [ps] Clip meta-surface to desired extents.
      Revert "[freelist] Make _cairo_freepool_alloc_from_new_pool static inline."
      [xlib] Make xlib_display_t private and rename xlib_screen_info_t
      [test] Add clip-image
      [xlib] Eliminate GC clipping
      [xlib] Remove stray code
      [boilerplate/test] Use numerical equality not string equality
      [script] Attempt to select a font if ! CAIRO_HAS_FT_FONT
      [script] Always create a fallback font
      [test] Add clip-disjoint
      [polygon] Fix discard with non-banded disjoint clip boxes
      [boilerplate] Handle errors whilst creating GL surface
      [polygon] Compute the limit of the limits slightly more efficiently
      [xlib] solid pictures should only be 1x1
      [gl] Remove reference to depth_stencil_tex
      [gl] Assert that the error is impossible.
      [gl] Allocate small number of rectangles on the stack
      [mutex] Hook into pthread last
      [win32] Remove unused clone_similar()
      [perf] Use milliseconds by default in cairo-perf-diff-files
      [fallback] Only eliminate the clip if the operation is bounded
      [test] Add unbounded variants of clip-{fill,stroke}
      [xlib] Enable pad_reflect by default
      [gl] compile fix.
      [perf] Move the calibration to its own function
      [configure] Add option to disable trace.
      [xlib] Protect ourselves from liars that claim to have a 64k window
      [gl] Supply extents for acquire source image
      [build] Improve handling of missing test apparatus
      [spans] Correct offsets for trapezoids
      [configure] Typo in test
      [twin] Initialise all properties
      [test] Check for errors during ft-show-glyphs-positioning
      [test] Add ANTIALIAS_NONE variation of twin
      [test] Variation of twin with ANTIALIAS_GRAY
      [test] SUBPIXEL_ANTIALIAS varation of twin
      [test] Variation of twin that intermixes antialiasing
      [test] An oversized twin test case.
      [test] Typo in ft-show-glyphs-positioning
      [test] Compare a failure against the image output
      [test] Disable the antialias testing for the vector surfaces.
      [util] Inherit the repository from xorg.modules
      [util] And restore the repository tag.
      [util] And back to a unique repo name for cairo.modules
      [util] And reuse the same name repository name.
      [xlib] Fix extraction of GC during XCloseDisplay()
      [clip] Simplify applying a box clip
      [surface] Early return for (region IN white)
      [test] Update big-line and remove XFAIL
      [xlib] Discard clip if larger than glyph extents
      [xlib] Fix big-line.
      [test] Add Debian packages for fonts
      [test] Typos in README from previous commit
      [configure] --enable-symbol-lookup
      [trace] Compile without lookup-symbol
      [trace] Stray trailing ';' in bswap macros
      [image] Add pixel masks for BGRA formats
      [configure] Fallback to detect OpenGL headers
      Add a private copy of GLEW
      [build] Add a default message for when GLEW isn't built
      [configure] Setup GL CFLAGS before checking for GLX
      [perf] Reorganise cairo-perf
      [xlib] Interim CAIRO_DEBUG variable to specify xrender level
      [xlib] Cleanse creation of similar surfaces.
      [xlib] Trim a few redundant steps when uploading glyphs
      [fallback] Special case single composite rectangle
      [xlib] Fix recent bug in unbounded trapezoids
      [gl] Handle an absent visual.
      [test] Exercise push-group-color.
      [test] Revamp surface-source
      [image] Do assumption initial user data is cleared.
      [image] Tweak coding style
      [image] Do not trust user supplied data to be clear
      [perf] Support parsing reports from stdin
      [tessellator] Invalid conversion of list head to edge.
      [xlib] XRequest bread crumbing
      [xlib] Suppress warning that should never have been.
      [boilerplate/xcb] Check for connection errors during test
      [xcb] Deferred error checking.
      [boilerplate/xcb] Fix pixmap depth
      [pattern] Compute extents for gradients
      [atomic] Fallback to libatomic-ops-dev
      [build] Link against pthread-stubs
      [surface] Avoid double application of device offset when calling fill()

Damian Frank (2):
      Rename cairo-script static func to avoid MinGW conflict
      Fix build on systems with older Xrender headers.

Emmanuel Pacaud (1):
      [SVG] Add extended blend modes.

Eric Anholt (38):
      [gl] Add basics for GL surface backend using test-fallback as base.
      [gl] Replace all-software implementation with all-GL-read/drawpixels.
      [gl] Make create_similar actually create similar instead of image.
      [gl] Add a shortcut from image to gl in clone_similar.
      [gl] Hook up fill_rectangles.
      [gl] clear surfaces to transparent on creation
      [gl] Clamp surface size to a minimum of (1,1) in create_similar.
      [gl] Add support for composite and composite_trapezoids.
      [gl] Fix infinite recursion on compositing A1 images.
      [gl] Fix unantialiased-shapes tests.
      [gl] Add interface for creating surfaces from window backbuffers.
      [gl] Avoid re-binding the same draw buffer.
      [gl] Fix some memory leaks on boilerplate-based runs.
      [gl] Add support for constant color directly, not through a texture.
      [gl] Use textures and not fbo-based surfaces for image surface patterns.
      [gl] Use triangle fan instead of GL_QUADS for the single quad we draw.
      [gl] Use GLEW to detect required extension presence.
      [gl] Make sure test visuals for CAIRO_CONTENT_COLOR_ALPHA have alpha bits.
      [gl] Wire blend factors using dst alpha to constants for CAIRO_CONTENT_COLOR.
      [gl] Don't forget that we require ARB_texture_non_power_of_two currently.
      [gl] Handle PIXMAN_b8g8r8a and PIXMAN_b8g8r8x8 in the image tex shortcut.
      [gl] Use filtering of GL_NEAREST to hint to TexImage not to alloc for mipmaps.
      [gl] Use the span renderer with an image surface temporary.
      [gl] Add HW spans implementation using VBOs and GL_LINES.
      [gl] Use Enable/DisableClientState for arrays for consistency.
      [gl] Use spans directly as geometry instead of rasterizing to a temporary.
      [gl] Fix check-def.sh for GL surface.
      [gl] Fix check-doc-syntax.sh for GL surface.
      [gl] Fix check-plt.sh for the GL surface.
      Merge branch 'gl' into gl-span-renderer
      [gl] Initialize has_alpha in the image surface composite fastpath.
      [gl] Drop use of packed datatypes where it's disallowed.
      Merge commit 'origin/master' into gl
      [gl] Add support for more 16-bit image formats.
      [gl] consolidate the pixman format to GL format/type/internalformat code.
      [gl] Start adding glyph cache support.
      [gl] Switch the glyph cache to using VBOs.
      [gl] Fix handling of clip for glyphs (clip-operator test).

Jeff Muizelaar (3):
      Factor out _cairo_image_surface_span_render_row()
      Use the scanline rasterizer in the win32 backend.
      Add a description of how we compute the spline_error_squared.

M Joonas Pihlaja (59):
      [cairo-surface] Handle the all clipped out case for regions.
      [test] Never use gcc __attribute__ magic for constructors.
      [test] Make test constructors without perl.
      [boilerplate] Check for connect() in libsocket.
      [test/any2ppm] Daemonize without BSD's daemon().
      [test] Fallback to HUGE_VAL in place of INFINITY in invalid-matrix.c.
      [test] Fix checking of the fenv.h include.
      [test/build] Don't test Freetype font stuff without Fontconfig.
      [shave] Robuster usage of the test shell built-in.
      [test] Mark scale-offset tests as XFAIL for image, xlib-fallback.
      [test] Add trap rendered ref images for fill-image.
      Revert "[test] Make the xlib-fallback use the image refs."
      [spans] Squash a compiler warning when creating error objects.
      [build] Require fontconfig >= 2.2.95 if we're using it at all.
      [trace] Compile without fontconfig.
      [script] Include unistd.h if we're twiddling file descriptors.
      [build] Remove a level of quoting from CAIRO_PARSE_VERSION.
      [build] Look for libpng.pc as well when configuring.
      [atomic] Use an integer __sync_val_compare_and_swap() for pointer CAS.
      [test] Fix a typo in the _POSIX_SOURCE version number.
      [test] Fix Makefile.am for Solaris make.
      [spans] Round rasterization grid pixel areas instead of truncating.
      [test] Test extremely small dash lengths.
      [build] Remove duplicate invocation of AC_CHECK_HEADERS.
      [trace] Use HAVE_FLOCKFILE/FUNLOCKFILE since configure test for them.
      [test] Use HAVE_FLOCKFILE instead of _POSIX_C_SOURCE.
      [wrapper] Avoid a void return gccism.
      [freelist] Make _cairo_freepool_alloc_from_new_pool static inline.
      [trace] Get the tracee program name from the environment.
      [NEWS] Thank the AuroraUX team for facilitating Solaris testing.
      [trace] Check for object stack underflow.
      [trace] Don't crash on unknown enums values.
      [trace] Replace an open coded test for matrix identity.
      [trace] Check for __builtin_return_address explicitly.
      [constructors] Guard against being called without any input files.
      [build] Refine the -Wno-attribute test to check our use cases.
      [build] Hush the Solaris compiler about enum abuse.
      [build] Fix typos in prototype warnings.
      [test] Allow tests to XFAIL by putting the cairo_t into an error state.
      [image] Check for out of bounds image surface sizes in constructors.
      [test] Fix the order of random points random-intersections-curves*.
      [test] Add large-source-roi.ref.png to test/Makefile.am
      [test] Reorder dash-infinite-loop to not hit a runaway allocation.
      [boilerplate] Support giving content in CAIRO_TEST_TARGET{,_EXCLUDE}.
      [boilerplate] Support wildcard ? in CAIRO_TEST_TARGET{,_EXCLUDE}.
      [perf] Add a fast-and-sloppy mode to cairo-perf.
      [trace] Avoid warnings from assigning a void pointer to a function pointer.
      [trace] Don't try and propagate a void result.
      [trace] Don't rely on the constructor attribute to initialise the tracer.
      [trace] Make cairo-trace and its symbol-lookup automatically configured.
      [build] Enable building cairo-trace on Solaris.
      [trace] Don't trace internal cairo calls on Solaris.
      [win32] Sync Makefile.win32.features.
      [build] Work around autoconf void* -> VOID__ name conversion bug.
      [build] Check for dlsym in both libdl and libc.
      [trace] Don't use pthread_key_delete.
      [trace] Look harder for the cairo-trace.so library.
      [autoconf] Comment on the SIZEOF_VOID__ -> SIZEOF_VOID_P workaround.
      [build] Check compiler flags using AC_TRY_LINK instead of AC_TRY_COMPILE.

Nis Martensen (2):
      [test] Verify current point position after subpath closure
      [path] Fix missing implicit move-to

Pierre Tardy (1):
      Cross-compilation fix for boilerplate/test

Sebastian Dr?ge (1):
      Use __uint128_t and __int128_t if available

S?ren Sandmann Pedersen (2):
      Reinstate cairo_region_create_rectangles()
      [test] Update reference image for the extended-blend-mode test.

Tobias Hunger (6):
      [qt] Reduce padding in cairo_qt_surface_t struct
      [qt] Move _opstr() inside the #if 0 to avoid warnings
      [qt] Add method to flush qpainter
      [qt] Cleanup some whitespace
      [qt] Remove use of unnecessary QPen pointer
      [qt] Remove use of unnecessary QBrush pointer

Vladimir Vukicevic (2):
      Import Qt backend by Mozilla
      Add skia backend
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091015/6815a7b2/attachment-0001.pgp 
-------------- next part --------------
_______________________________________________
cairo-announce mailing list
cairo-announce at lists.cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo-announce

From cworth at cworth.org  Thu Oct 15 17:07:34 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 15 Oct 2009 17:07:34 -0700
Subject: [cairo] [cairo-announce] cairo snapshot 1.9.4 now available
In-Reply-To: <1255649244-sup-6905@yoom.home.cworth.org>
References: <1255649244-sup-6905@yoom.home.cworth.org>
Message-ID: <1255651285-sup-3314@yoom.home.cworth.org>

Excerpts from Carl Worth's message of Thu Oct 15 16:34:18 -0700 2009:
> A new cairo snapshot 1.9.4 is now available.

I was a bit hasty in sending out that email and forgot to include the
following release notes. Please accept my apologies, (we really don't
expect you to read through the several hundred of Chris Wilson's
commit messages to try to figure out what's new).

-Carl

PS. Cairo developers, if your carefully coded work isn't reflected
here, then you forgot to add a mention of it to the NEWS file. If you
correct that soon, we'll be sure to get that description into the
announcement for cairo 1.10.

What's new in cairo 1.9.4 (compared to cairo 1.9.2)
===================================================
API additions:

  cairo_meta_surface_create()
  cairo_meta_surface_ink_extents()

    Finally exporting the internal meta-surface so that applications
    have a method to record and replay a sequence of drawing commands.

  cairo_in_clip()

    Determines whether a given point is inside the current clip.
    ??? Should this be called cairo_in_paint() instead? in-clip is the test
    that is performed, but in-paint would be similar to in-fill and in-stroke.

New utilities:

  cairo-test-trace

    A companion to cairo-perf-trace, this utility replays a trace against
    multiple targets in parallel and looks for differences in the output,
    and then records any drawing commands that cause a failure.
    Future plans:
      Further minimisation of the fail trace using "delta debugging".
      More control over test/reference targets.

Backend improvements:

  xlib

     Server-side gradients. The theory is that we can offload computation
     of gradients to the GPU and avoid pushing large images over the
     connection. Even if the driver has to fallback and use pixman to render
     a temporary source, it should be able to do so in a more efficient manner
     than Cairo itself. However, cairo-perf suggests otherwise:

     On tiny, Celeron/i915:

      before: firefox-20090601 211.585
       after: firefox-20090601 270.939

     and on tiger, CoreDuo/nvidia:

      before: firefox-20090601 70.143
       after: firefox-20090601 87.326

     In particular, looking at tiny:

     xlib-rgba paint-with-alpha_linear-rgba_over-512   47.11 (47.16 0.05%) -> 123.42 (123.72 0.13%):  2.62x slowdown
     ??
     xlib-rgba paint-with-alpha_linear3-rgba_over-512   47.27 (47.32 0.04%) -> 123.78 (124.04 0.13%):  2.62x slowdown
     ??


New experimental backends:

   QT

   OpenVG - The initial work was done by ?yvind Kol?s, and made ready for
            inclusion by Pierre Tardy.

   OpenGL - An advanced OpenGL compositor. The aim is to write a integrate
            directed rendering using OpenGL at a high-level into Cairo. In
	    contrast to the previous attempt using Glitz which tried to
	    implement the RENDER protocol on top of OpenGL, using the
	    high-level interface should permit greater flexibility and
	    more offloading onto the GPU.
	    The initial work on the backend was performed by Eric Anholt.

Long standing bugs fixed:

  Self-intersecting strokes.

    A long standing bug where the coverage from overlapping semi-opaque
    strokes (including neighbouring edges) was simply summed in lieu of
    a costly global calculation has been fixed (by performing the costly
    global calculation!) In order to mitigate the extra cost, the
    tessellator has been overhauled and tune, which handles the fallback
    for when we are unable to use the new span rasteriser on the stroke
    (e.g. when using the current RENDER protocol). The large number of
    pixel artefacts that implementing self-intersection elimination
    removes is ample justification for the potential performance
    regression. If you unfortunately do suffer a substantial performance
    regression in your application, please consider obtaining a
    cairo-trace and submitting it to us for analysis and inclusion into
    our performance suite.

Special thanks:

   To the AuroraUX team for providing access to one of their OpenSolaris
   machines for cairo and pixman development.  http://www.auroraux.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091015/fc3f2e33/attachment.pgp 
-------------- next part --------------
_______________________________________________
cairo-announce mailing list
cairo-announce at lists.cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo-announce

From fret at memecode.com  Thu Oct 15 22:40:50 2009
From: fret at memecode.com (Matthew Allen)
Date: Fri, 16 Oct 2009 16:40:50 +1100
Subject: [cairo] cairo_xcb_surface_create_with_xrender_format
Message-ID: <R7IED.13085MIO@memecode.com>

Hi, I'm trying to use cairo_xcb_surface_create_with_xrender_format to put bitmaps quickly onto the screen while honouring their alpha channel. I hope I'm on the right track. Anyway the format parameter is giving me some trouble, I don't know what to supply for the format. I googled that function and the various apps that use it often get their format from libraries I don't seem to be using or preface their code with "this is a horrible hack....".

So.... whats the "official" way of doing it?

The drawable is a window in my case.
--
Matthew Allen


From chris at chris-wilson.co.uk  Fri Oct 16 00:57:47 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Fri, 16 Oct 2009 08:57:47 +0100
Subject: [cairo] cairo_xcb_surface_create_with_xrender_format
In-Reply-To: <R7IED.13085MIO@memecode.com>
References: <R7IED.13085MIO@memecode.com>
Message-ID: <1255679552-sup-6164@broadwater.alporthouse.com>

Excerpts from Matthew Allen's message of Fri Oct 16 06:40:50 +0100 2009:
> Hi, I'm trying to use cairo_xcb_surface_create_with_xrender_format to put
> bitmaps quickly onto the screen while honouring their alpha channel. I hope I'm
> on the right track. Anyway the format parameter is giving me some trouble, I
> don't know what to supply for the format. I googled that function and the
> various apps that use it often get their format from libraries I don't seem to
> be using or preface their code with "this is a horrible hack....".
> 
> So.... whats the "official" way of doing it?
> 
> The drawable is a window in my case.

It is very simple: pass the same information to cairo as you used to
create your drawable, in this case that will be the Visual. (Cairo will
map the Visual to the correct xrender format if it so needs.)

Hmm, I'm a bit worried about the statement "honouring their alpha
channel" as cairo's image format is premultiplied and this sounds like
your trying to feed incorrect information into the system and expect it
to just work.

Using cairo should be fun... If it's not you're doing it wrong. ;-)
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From T.J.G.Veenker at uu.nl  Fri Oct 16 02:40:09 2009
From: T.J.G.Veenker at uu.nl (Theo Veenker)
Date: Fri, 16 Oct 2009 11:40:09 +0200
Subject: [cairo] searching cairo archives
Message-ID: <4AD83F79.5090306@uu.nl>

Hi,

Would it be possible to make the search button on http://lists.cairographics.org/archives/cairo/
search lists.cairographics.org/archives/cairo/ instead of lists.freedesktop.org/archives/cairo/.
Carl switched it to lists.cairographics.org once before, shorly after that it got reverted back
to lists.freedesktop.org. Don't know why.

Regards,
Theo

From linuxhippy at gmail.com  Fri Oct 16 09:25:54 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 16 Oct 2009 12:25:54 -0400
Subject: [cairo] Howto draw quadratic curves with cairo?
Message-ID: <194f62550910160925i6fb0cf4fx8031ee27b28688a2@mail.gmail.com>

Hi,

I would like to use cairo for drawing quadratic bezier curves, however
as as far as I saw cairo only supports cubic curves.
I guess its not hard, but could anybody help me out howto create cubic
curve parameters out of quadratic ones?

Thank you in advance, Clemens

From sebastien at ximian.com  Fri Oct 16 10:06:15 2009
From: sebastien at ximian.com (Sebastien Pouliot)
Date: Fri, 16 Oct 2009 13:06:15 -0400
Subject: [cairo] Howto draw quadratic curves with cairo?
In-Reply-To: <194f62550910160925i6fb0cf4fx8031ee27b28688a2@mail.gmail.com>
References: <194f62550910160925i6fb0cf4fx8031ee27b28688a2@mail.gmail.com>
Message-ID: <1255712775.29880.15.camel@mizar.home>

Hello Clemens,

We have such code inside Moonlight
http://anonsvn.mono-project.com/viewvc/trunk/moon/src/moon-path.c?revision=127537&view=markup

Sebastien

On Fri, 2009-10-16 at 12:25 -0400, Clemens Eisserer wrote:
> Hi,
> 
> I would like to use cairo for drawing quadratic bezier curves, however
> as as far as I saw cairo only supports cubic curves.
> I guess its not hard, but could anybody help me out howto create cubic
> curve parameters out of quadratic ones?
> 
> Thank you in advance, Clemens
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From spitzak at gmail.com  Fri Oct 16 11:48:08 2009
From: spitzak at gmail.com (Bill Spitzak)
Date: Fri, 16 Oct 2009 11:48:08 -0700
Subject: [cairo] Howto draw quadratic curves with cairo?
In-Reply-To: <1255712775.29880.15.camel@mizar.home>
References: <194f62550910160925i6fb0cf4fx8031ee27b28688a2@mail.gmail.com>
	<1255712775.29880.15.camel@mizar.home>
Message-ID: <4AD8BFE8.3050705@gmail.com>

All variables are vectors with 2 or more points.

To turn quad(p0, p1, p2) into cubic(q0, q1, q2, q3):

	q0 = p0
	q1 = (p0+2*p1)/3
	q2 = (p2+2*p1)/3
	q3 = p2

Ascii diagram, q1 and q2 are 2/3 the distance along the lines:

	p0         p2
	 \         /
	  \       /
	   \     /
	    q1  q2
	     \ /
	      p1

Sebastien Pouliot wrote:
> Hello Clemens,
> 
> We have such code inside Moonlight
> http://anonsvn.mono-project.com/viewvc/trunk/moon/src/moon-path.c?revision=127537&view=markup
> 
> Sebastien
> 
> On Fri, 2009-10-16 at 12:25 -0400, Clemens Eisserer wrote:
>> Hi,
>>
>> I would like to use cairo for drawing quadratic bezier curves, however
>> as as far as I saw cairo only supports cubic curves.
>> I guess its not hard, but could anybody help me out howto create cubic
>> curve parameters out of quadratic ones?
>>
>> Thank you in advance, Clemens

From sgoericke at vandalay.org  Sat Oct 17 12:44:05 2009
From: sgoericke at vandalay.org (Sven Goericke)
Date: Sat, 17 Oct 2009 21:44:05 +0200
Subject: [cairo] Win32 thread-safety
Message-ID: <4ADA1E85.4020700@vandalay.org>

Hello,

i use cairo (or better: cairomm) for a X-Plane aircraft addon, meaning 
it's used in a DLL/.so/.dylib. For text i use(d) the simple "toy-text" 
API because it do a good job for my needs. The plugin run fine on Linux 
(i use mainly Linux for development and daily use) and also runs fine on 
MacOS. Linux-Distribution is Archlinux, OSX Version is still 10.5.8. But 
on Windows i come into trouble: using MinGW/GDB i got error messages 
from the Microsoft MSVC Runtime-Library "this application has called a 
runtime function in a unusual way" or similar. However, GDB keeps the 
app running, couldn't tll me what's going wrong with the app bevor i 
click "Ok" on the error message-box. Thereafter gdb told me there was a 
"std::bad_alloc" exception but couldn't tell me were. So i checked every 
"new" etc. in my code, also add a lot "try-catch" statements around them 
but nothing helps.

To get closer to the problem i decided to compile and debug the stuff 
with MSVC (Visual Studio 2008). I found out the "bad_alloc" exception 
was thrown by the cairomm-library (CAIRO_STATUS_NO_MEMORY). But i still 
didn't have an idea why. Because the errors are "random" ones it was 
hard to find the problem. The first hint i got was that the exception 
always was thrown if i did anything with text (get_text_extents(), 
show_text() mainly).  A hour ago i just found that one of my 
drawing-threads has thrown the exception  and another  called  
"cairo_show_text()" the same time.  So i came to the conclusion  that 
there *must* be a probelm with text-handling on Win32 systems. Btw., at 
the moment i run up to 8 threads that use cairo and growing.

So i tried a "simple" approach and add a global Mutex to my plugin and 
cover every text-related stuff in my code by this Mutex. And surprise 
surprise, this helps. But also reduces Performance a bit in the 
Application, saying X-Plane.

I also don't longer use "normal" Win32-Font objects and 
"set_font_size()" but switched to Win32ScaledFont (which didn't solve 
the problem).

So, my question: is cairomm thread-safe on Win32? I mean the Font/Text 
stuff ? Second: if so, is it only thread-safe with native Win32 Threads? 
I use pthreads2 for Win32 (i'm happy with that).

used cairo-version: 1.8.8
used cairomm-version: 1.8.2
tested OS: Windows Vista 64bit, Windows 7 64bit, Linux 32bit (Kernel 
2.6.30 with PAE and Highmem = 64GB, i have 8GB of RAM, Glibc 2.10), 
MacOSX 10.5.8

Anyway, thanks for that highly protable vector-graphics library :-)

http://www.sgoericke.de/screenshot_1.png
http://www.youtube.com/watch?v=slVWL0tks9o

From cairouser at yahoo.com  Sat Oct 17 16:15:28 2009
From: cairouser at yahoo.com (cu)
Date: Sat, 17 Oct 2009 19:15:28 -0400
Subject: [cairo] Win32 thread-safety
In-Reply-To: <4ADA1E85.4020700@vandalay.org>
References: <4ADA1E85.4020700@vandalay.org>
Message-ID: <4ADA5010.6070802@yahoo.com>

I also found this to be the case, and all our text output code is
currently wrapped in mutexes.

So I'd be very interested in a fix as well. FWIW I recall having
problems with that code on OSX as well as on Windows, though on Windows
they seem to be more widely spread and more obvious. Incidentally, it
has gotten slightly worse in versions after 1.8.6 (occasionally I try to
disable mutexes and see if the issue was somehow resolved).




Sven Goericke wrote:
> So i tried a "simple" approach and add a global Mutex to my plugin and 
> cover every text-related stuff in my code by this Mutex. And surprise 
> surprise, this helps. But also reduces Performance a bit in the 
> Application, saying X-Plane.
>
> I also don't longer use "normal" Win32-Font objects and 
> "set_font_size()" but switched to Win32ScaledFont (which didn't solve 
> the problem).
>   


From T.J.G.Veenker at uu.nl  Mon Oct 19 02:11:50 2009
From: T.J.G.Veenker at uu.nl (Theo Veenker)
Date: Mon, 19 Oct 2009 11:11:50 +0200
Subject: [cairo] some old problems still in latest snapshot
Message-ID: <4ADC2D56.4090901@uu.nl>

Hi,

I just tried cairo 1.9.4 + pixman 0.16.2 to see whether some of the problems
I ran into before had been solved.

Referring to this message:
http://lists.cairographics.org/archives/cairo/2008-August/014922.html

- The svg backend still does CAIRO_EXTEND_REPEAT when CAIRO_EXTEND_NONE or
   CAIRO_EXTEND_PAD selected.

- The problem with xlib backend described in the above message (filling a
   rotated rectangle with an image pattern) is also still present. See
   attached results for different angles.

I used the test programs attached in that message.


Also calculating stroke extents doesn't yet work for rotated paths. The
following gives wrong stroke extents for non-zero angles.

cairo_translate()
cairo_scale()
cairo_rotate()

cairo_move_to()
cairo_line_to()

cairo_set_source()
cairo_set_line_width()

cairo_stroke_extents()

cairo_stroke()

Behdad said in http://lists.cairographics.org/archives/cairo/2008-May/014208.html
in reply to this my earlier report of this problem that he was thinking about a
different implementation to calculate stroke/path extents. Is this still the plan?
I do hope so. I couldn't find this on the buglist.

My workaround is to calculate the extents like below, but this only works
if path scaling is 1. If scaling is != 1 then the extents don't quite match
the ink.

cairo_save()

   cairo_translate()
   cairo_scale()
   cairo_rotate()

   cairo_move_to()
   cairo_line_to()

cairo_restore()

cairo_set_line_width()

cairo_stroke_extents()

Thanks,
Theo


-------------- next part --------------
A non-text attachment was scrubbed...
Name: angle0.png
Type: image/png
Size: 16682 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091019/5292098f/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: angle15.png
Type: image/png
Size: 24829 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091019/5292098f/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: angle36.png
Type: image/png
Size: 24547 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091019/5292098f/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: angle37.png
Type: image/png
Size: 15882 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091019/5292098f/attachment-0007.png 

From chris at chris-wilson.co.uk  Mon Oct 19 02:41:54 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Mon, 19 Oct 2009 10:41:54 +0100
Subject: [cairo] some old problems still in latest snapshot
In-Reply-To: <4ADC2D56.4090901@uu.nl>
References: <4ADC2D56.4090901@uu.nl>
Message-ID: <1255944722-sup-1748@broadwater.alporthouse.com>

Excerpts from Theo Veenker's message of Mon Oct 19 10:11:50 +0100 2009:
> I just tried cairo 1.9.4 + pixman 0.16.2 to see whether some of the problems
> I ran into before had been solved.
> 
> Referring to this message:
> http://lists.cairographics.org/archives/cairo/2008-August/014922.html
> 
> - The svg backend still does CAIRO_EXTEND_REPEAT when CAIRO_EXTEND_NONE or
>    CAIRO_EXTEND_PAD selected.

We're happy to take patches to use the fallback paths for anything that
SVG cannot handle natively. Though to be honest, that's not at the top of
my list of the worst offenders within the SVG backend.

> - The problem with xlib backend described in the above message (filling a
>    rotated rectangle with an image pattern) is also still present. See
>    attached results for different angles.

This is a driver bug.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From T.J.G.Veenker at uu.nl  Mon Oct 19 04:13:00 2009
From: T.J.G.Veenker at uu.nl (Theo Veenker)
Date: Mon, 19 Oct 2009 13:13:00 +0200
Subject: [cairo] some old problems still in latest snapshot
In-Reply-To: <1255944722-sup-1748@broadwater.alporthouse.com>
References: <4ADC2D56.4090901@uu.nl>
	<1255944722-sup-1748@broadwater.alporthouse.com>
Message-ID: <4ADC49BC.2090401@uu.nl>

Chris Wilson wrote:
> Excerpts from Theo Veenker's message of Mon Oct 19 10:11:50 +0100 2009:
>> I just tried cairo 1.9.4 + pixman 0.16.2 to see whether some of the problems
>> I ran into before had been solved.
>>
>> Referring to this message:
>> http://lists.cairographics.org/archives/cairo/2008-August/014922.html
>>
>> - The svg backend still does CAIRO_EXTEND_REPEAT when CAIRO_EXTEND_NONE or
>>    CAIRO_EXTEND_PAD selected.
> 
> We're happy to take patches to use the fallback paths for anything that
> SVG cannot handle natively. Though to be honest, that's not at the top of
> my list of the worst offenders within the SVG backend.

It's not a big deal for me either. I didn't know SVG doesn't handle extend_none.

> 
>> - The problem with xlib backend described in the above message (filling a
>>    rotated rectangle with an image pattern) is also still present. See
>>    attached results for different angles.
> 
> This is a driver bug.

Aha. I can get around it by using an image surface based backbuffer.
I suppose this bug would also show up when drawing into an xlib pixmap?

Theo

From jonathon at quotidian.org  Mon Oct 19 07:11:37 2009
From: jonathon at quotidian.org (Jonathon Jongsma)
Date: Mon, 19 Oct 2009 09:11:37 -0500
Subject: [cairo] [cairo-announce] cairomm release 1.8.4 now available
Message-ID: <4ADC7399.3090204@quotidian.org>

cairomm is a C++ API for the cairo graphics library.  For more 
information, see http://cairographics.org/cairomm

A new cairomm release 1.8.4 is now available from:

	http://cairographics.org/releases/cairomm-1.8.4.tar.gz

    which can be verified with:

	http://cairographics.org/releases/cairomm-1.8.4.tar.gz.sha1
	fdea579f406261881a0f4f6242a3980aecef382d  cairomm-1.8.4.tar.gz

	http://cairographics.org/releases/cairomm-1.8.4.tar.gz.sha1.asc
	(signed by Jonathon Jongsma)

WHAT'S NEW
==========
1.8.4:

* move to new mm-common build infrastructure
* Contributors for this release:
     1  Christopher Harvey
     4  Daniel Elstner
     4  David King
     1  Jonathon Jongsma

-- 
jonner
_______________________________________________
cairo-announce mailing list
cairo-announce at lists.cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo-announce

From ranma42 at gmail.com  Mon Oct 19 09:43:19 2009
From: ranma42 at gmail.com (Andrea Canciani)
Date: Mon, 19 Oct 2009 18:43:19 +0200
Subject: [cairo] [PATCH] quartz mask (alpha-only) surfaces
Message-ID: <e93d14620910190943u261f85cdie9e4be6ea96757c1@mail.gmail.com>

I'm trying to fix some major failures in the quartz backend (in
particular master has some serious problems when rendering glyphs
through the fallback code).
While investigating these problems, I learnt that they probably depend
(at least partly) on an incorrect handling of alpha-only surfaces.
Attached are two patches that fix the previous problem in a couple of
places, even if they don't fix it everywhere (look for "XXX -- should
use CGImageMaskCreate" in cairo-quartz-surface.c).
The first patch fixes the creation of alpha-only quartz bitmap
contexts and makes "alpha-similar" and "smask-image-mask" pass.
The second one improves mask creation for the fixup of unbounded operators.
I'm still having some troubles with surface patterns, in particular it
looks like the pattern transform is applied twice (an ugly hack to
make my test pass is skipping the application of the pattern transform
in _cairo_quartz_surface_paint, but it seems wrong to me, as other
patterns need that transform to be applied). I'd like anybody
knowledgeable about the internals of the backend to explain me what's
really happening.
These changes should be quite safe, but please review and test, if possible.
Thank you
Andrea Canciani
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-quartz-Improve-A8-image-handling.patch
Type: application/octet-stream
Size: 2054 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091019/db7500e6/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-quartz-Improve-unbounded-operators-fixup.patch
Type: application/octet-stream
Size: 2213 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091019/db7500e6/attachment-0001.obj 

From siarhei.siamashka at gmail.com  Mon Oct 19 14:13:15 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 20 Oct 2009 00:13:15 +0300
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <ye8tz2w4z3k.fsf@camel18.daimi.au.dk>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<ye8tz2w4z3k.fsf@camel18.daimi.au.dk>
Message-ID: <200910200013.15632.siarhei.siamashka@gmail.com>

On Thursday 04 June 2009, Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > What kind of guarantees (or the lack of) pixman and XRender are supposed
> > to provide when dealing with overlapping parts of images?
>
> (Adding xorg-devel). See this thread:
>
>     http://lists.freedesktop.org/archives/xorg/2008-October/039346.html
>
> The guarantee that I would suggest for Render and pixman is that if
> any pixel is both read and written in the same request, then the
> result of the whole request is undefined, except that it obeys the
> clipping rules.
>
> > The practical use case could be scrolling of data inside of a single big
> > image. If rendering with overlapped source and destination areas is not
> > supported, a temporary image has to be created to achieve expected result
> > and this is an additional performance hit.
>
> Yes, scrolling is one thing that the current pixman API doesn't really
> provide. 'pixman_blt()' only deals with cases where the source and
> destination don't overlap.
>
> I think the best solution is to move all of the X primitives
> (CopyArea, DrawLine, DrawArc, etc.) into pixman. For CopyArea it would
> probably look something like this:
>
>         void
>         pixman_copy_area (pixman_image_t *src,
>                           pixman_image_t *dest,
>                           pixman_gc_t *gc,
>                           int src_x,
>                           int src_y,
>                           int width,
>                           int height,
>                           int dest_x,
>                           int dest_y);
>
> and that would be guaranteed to handle overlapping src and dest. A
> pixman_gc_t would be a new type of object, corresponding to an X GC.
>
> pixman_blt() would then become a deprecated wrapper that would just
> call pixman_copy_area(). Same for pixman_fill() and a new
> pixman_fill_rectangles().

I'm not sure about pixman_gc_t since most of the needed operations are just
simple copies. What about starting with just introducing a variant
of 'pixman_blt' which is overlapping aware?

I created a work-in-progress branch with 'pixman_blt' function (generic C
implementation for now) extended to support overlapped source/destination
case. A simple test program is also included:
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt

Making use of the already existing SIMD optimized pixel copy functions should
provide fast scrolling in all the directions except for from left to right.
This special case will require a SIMD optimized backwards copy.

I wonder if it makes sense to drop delegates support for pixman_blt and make
call chain shorter when introducing SIMD optimized copies? It seems to be a
little bit overdesigned here.

Running test program for the current pixman master (SSE2 optimized):

$ test/overlapped-blt-test
bpp=8, supported=0, normal_ok=0, overlapped_ok=0
bpp=16, supported=1, normal_ok=1, overlapped_ok=0
bpp=32, supported=1, normal_ok=1, overlapped_ok=0

Running test program for the pixman from this branch with generic
C version of pixman_blt (8bpp now uses a fallback to generic C
implementation):

$ test/overlapped-blt-test
bpp=8, supported=1, normal_ok=1, overlapped_ok=1
bpp=16, supported=1, normal_ok=1, overlapped_ok=0
bpp=32, supported=1, normal_ok=1, overlapped_ok=0


-- 
Best regards,
Siarhei Siamashka

From siarhei.siamashka at gmail.com  Mon Oct 19 14:35:22 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 20 Oct 2009 00:35:22 +0300
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <200910140113.17147.siarhei.siamashka@gmail.com>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
Message-ID: <200910200035.22394.siarhei.siamashka@gmail.com>

On Wednesday 14 October 2009, Siarhei Siamashka wrote:
> Hello,
>
> This branch has new ARM NEON optimizations:
> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=arm-neon-update

[...]

Pushed the first commit to master. It only contains removal of unused and
commented out code. It was safe to apply, and this kind of housekeeping is
needed anyway before introducing something new here.

Regarding the other changes. I'm somewhat tempted to push them too :) After
all, this code provides up to 2x performance improvement over the existing
NEON optimizations. And it is also needed for introducing ARM NEON
optimizations to overlapping-aware pixman_blt function.

There is also pixman fast path microbenchmark program in this branch:
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=test-n-bench

It can be used by running:
$ test/lowlevel-blt-bench _

-- 
Best regards,
Siarhei Siamashka

From sandmann at daimi.au.dk  Mon Oct 19 15:29:09 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 20 Oct 2009 00:29:09 +0200
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <200910200013.15632.siarhei.siamashka@gmail.com>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<ye8tz2w4z3k.fsf@camel18.daimi.au.dk>
	<200910200013.15632.siarhei.siamashka@gmail.com>
Message-ID: <ye8vdibf26i.fsf@camel22.daimi.au.dk>

Hi,

> On Thursday 04 June 2009, Soeren Sandmann wrote:
> > Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > > What kind of guarantees (or the lack of) pixman and XRender are supposed
> > > to provide when dealing with overlapping parts of images?
> >
> > (Adding xorg-devel). See this thread:
> >
> >     http://lists.freedesktop.org/archives/xorg/2008-October/039346.html
> >
> > The guarantee that I would suggest for Render and pixman is that if
> > any pixel is both read and written in the same request, then the
> > result of the whole request is undefined, except that it obeys the
> > clipping rules.
> >
> > > The practical use case could be scrolling of data inside of a single big
> > > image. If rendering with overlapped source and destination areas is not
> > > supported, a temporary image has to be created to achieve expected result
> > > and this is an additional performance hit.
> >
> > Yes, scrolling is one thing that the current pixman API doesn't really
> > provide. 'pixman_blt()' only deals with cases where the source and
> > destination don't overlap.
> >
> > I think the best solution is to move all of the X primitives
> > (CopyArea, DrawLine, DrawArc, etc.) into pixman. For CopyArea it would
> > probably look something like this:
> >
> >         void
> >         pixman_copy_area (pixman_image_t *src,
> >                           pixman_image_t *dest,
> >                           pixman_gc_t *gc,
> >                           int src_x,
> >                           int src_y,
> >                           int width,
> >                           int height,
> >                           int dest_x,
> >                           int dest_y);
> >
> > and that would be guaranteed to handle overlapping src and dest. A
> > pixman_gc_t would be a new type of object, corresponding to an X GC.
> >
> > pixman_blt() would then become a deprecated wrapper that would just
> > call pixman_copy_area(). Same for pixman_fill() and a new
> > pixman_fill_rectangles().
> 
> I'm not sure about pixman_gc_t since most of the needed operations are just
> simple copies. What about starting with just introducing a variant
> of 'pixman_blt' which is overlapping aware?

The pixman_blt() interface is misdesigned for two reasons: (1) the
strides are given in number-of-uint32_ts, which gratuitously limits
the types of images that can be processed, and (2) it can fail if it
doesn't like the input for some reason. 

At the same time, having the core primitives available on the client
side is useful in some cases, and the software implementation of them
can more easily be optimized with SIMD instructions in pixman.

Moving core rendering into pixman solves both issues at the same time.

But that said, I am not opposed to extending pixman_blt() to support
overlapping copies. That is certainly a simpler first step.

> I created a work-in-progress branch with 'pixman_blt' function (generic C
> implementation for now) extended to support overlapped source/destination
> case. A simple test program is also included:
> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt
> 
> Making use of the already existing SIMD optimized pixel copy functions should
> provide fast scrolling in all the directions except for from left to right.
> This special case will require a SIMD optimized backwards copy.
> 
> I wonder if it makes sense to drop delegates support for pixman_blt and make
> call chain shorter when introducing SIMD optimized copies? It seems to be a
> little bit overdesigned here.

How would you support SSE2 and MMX in the same binary then?

Also, I really don't see much potential for saving here. For a NEON
implementation of blt, the callchain would be:

   pixman_blt() ->  _pixman_implementation_blt() -> neon_blt()

and getting rid of delegates wouldn't really affect that at all. You
could get rid of the _pixman_implementation_blt() call by making it a
macro, but as I mentioned before, gcc turns it into a tail call that
reused the arguments on the stack, so the overhead really is minimal.


Soren

From siarhei.siamashka at gmail.com  Mon Oct 19 16:33:44 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 20 Oct 2009 02:33:44 +0300
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <ye8vdibf26i.fsf@camel22.daimi.au.dk>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<200910200013.15632.siarhei.siamashka@gmail.com>
	<ye8vdibf26i.fsf@camel22.daimi.au.dk>
Message-ID: <200910200233.44965.siarhei.siamashka@gmail.com>

On Tuesday 20 October 2009, Soeren Sandmann wrote:
[...]
> > I'm not sure about pixman_gc_t since most of the needed operations are
> > just simple copies. What about starting with just introducing a variant
> > of 'pixman_blt' which is overlapping aware?
>
> The pixman_blt() interface is misdesigned for two reasons: (1) the
> strides are given in number-of-uint32_ts, which gratuitously limits
> the types of images that can be processed, and (2) it can fail if it
> doesn't like the input for some reason.
>
> At the same time, having the core primitives available on the client
> side is useful in some cases, and the software implementation of them
> can more easily be optimized with SIMD instructions in pixman.
>
> Moving core rendering into pixman solves both issues at the same time.

I don't have any strong opinion about API updates. In any case, smooth
upgrade path needs to be taken care of and the users should be prevented
from using incompatible versions of client applications/libraries and
pixmap. An introduction of a new function may be the best way, it can also
solve some of the design issues.

> But that said, I am not opposed to extending pixman_blt() to support
> overlapping copies. That is certainly a simpler first step.

Yes, the functionality itself can be introduced first (without breaking
anything). Wrapping it into a better API can be done as the natural next
step.

> > I created a work-in-progress branch with 'pixman_blt' function (generic C
> > implementation for now) extended to support overlapped source/destination
> > case. A simple test program is also included:
> > http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt
> >
> > Making use of the already existing SIMD optimized pixel copy functions
> > should provide fast scrolling in all the directions except for from left
> > to right. This special case will require a SIMD optimized backwards copy.
> >
> > I wonder if it makes sense to drop delegates support for pixman_blt and
> > make call chain shorter when introducing SIMD optimized copies? It seems
> > to be a little bit overdesigned here.
>
> How would you support SSE2 and MMX in the same binary then?

The most simple way is to do it in my opinion is the following.

First introduce something like 'pixman_init' function. Right now CPU type
detection is done on the first call to the function. It introduces some
minor overhead by having an extra pointer check on each function call.
Another problem is that we can't be completely sure that CPU capabilities
detection check is always fully reentrant. For example, some platforms may
try to set a signal handler and expect to catch SIGILL or something like
this.

This initialization function would just detect CPU capabilities and set some
function pointers. The whole CPU-specific implementation of 'pixman_blt'
may be just called via this pointer directly by a client. Or 'pixman_blt' can
be just a small thunk which does a call via function pointer, passes exactly
the same arguments to it and does nothing more. In this case there will be
really no excuse for the compiler for not using tail call, see below.

> Also, I really don't see much potential for saving here. For a NEON
> implementation of blt, the callchain would be:
>
>    pixman_blt() ->  _pixman_implementation_blt() -> neon_blt()
>
> and getting rid of delegates wouldn't really affect that at all. You
> could get rid of the _pixman_implementation_blt() call by making it a
> macro, but as I mentioned before, gcc turns it into a tail call that
> reused the arguments on the stack, so the overhead really is minimal.

On what kind of platform and with which version of gcc are you getting
proper tail call here? I don't see it being used and the overhead is
rather hefty, which is also confirmed by benchmarking and profiling.

Even if gcc can reuse some part of the arguments which are already on
stack in some cases, different platforms may have different ABI and calling
conventions. For example, for ARM and x86-64, the first few arguments
are passed in registers, the rest is on stack. Relying on the compiler to
always do the job properly identifying tail call possibilities in all cases
may be not the very best idea.

C:

PIXMAN_EXPORT pixman_bool_t
pixman_blt (uint32_t *src_bits,
            uint32_t *dst_bits,
            int       src_stride,
            int       dst_stride,
            int       src_bpp,
            int       dst_bpp,
            int       src_x,
            int       src_y,
            int       dst_x,
            int       dst_y,
            int       width,
            int       height)
{
    if (!imp)
        imp = _pixman_choose_implementation ();

    return _pixman_implementation_blt (imp, src_bits, dst_bits, src_stride,
                                       dst_stride,
                                       src_bpp, dst_bpp,
                                       src_x, src_y,
                                       dst_x, dst_y,
                                       width, height);
}

x86, gcc 4.3.2:

00000420 <pixman_blt>:
 420:   55                      push   %ebp
 421:   89 e5                   mov    %esp,%ebp
 423:   83 ec 38                sub    $0x38,%esp
 426:   8b 15 00 00 00 00       mov    0x0,%edx
 42c:   85 d2                   test   %edx,%edx
 42e:   74 68                   je     498 <pixman_blt+0x78>
 430:   8b 45 34                mov    0x34(%ebp),%eax
 433:   89 44 24 30             mov    %eax,0x30(%esp)
 437:   8b 45 30                mov    0x30(%ebp),%eax
 43a:   89 44 24 2c             mov    %eax,0x2c(%esp)
 43e:   8b 45 2c                mov    0x2c(%ebp),%eax
 441:   89 44 24 28             mov    %eax,0x28(%esp)
 445:   8b 45 28                mov    0x28(%ebp),%eax
 448:   89 44 24 24             mov    %eax,0x24(%esp)
 44c:   8b 45 24                mov    0x24(%ebp),%eax
 44f:   89 44 24 20             mov    %eax,0x20(%esp)
 453:   8b 45 20                mov    0x20(%ebp),%eax
 456:   89 44 24 1c             mov    %eax,0x1c(%esp)
 45a:   8b 45 1c                mov    0x1c(%ebp),%eax
 45d:   89 44 24 18             mov    %eax,0x18(%esp)
 461:   8b 45 18                mov    0x18(%ebp),%eax
 464:   89 44 24 14             mov    %eax,0x14(%esp)
 468:   8b 45 14                mov    0x14(%ebp),%eax
 46b:   89 44 24 10             mov    %eax,0x10(%esp)
 46f:   8b 45 10                mov    0x10(%ebp),%eax
 472:   89 44 24 0c             mov    %eax,0xc(%esp)
 476:   8b 45 0c                mov    0xc(%ebp),%eax
 479:   89 44 24 08             mov    %eax,0x8(%esp)
 47d:   8b 45 08                mov    0x8(%ebp),%eax
 480:   89 44 24 04             mov    %eax,0x4(%esp)
 484:   a1 00 00 00 00          mov    0x0,%eax
 489:   89 04 24                mov    %eax,(%esp)
 48c:   e8 fc ff ff ff          call   48d <pixman_blt+0x6d>
 491:   c9                      leave
 492:   c3                      ret
 493:   90                      nop
 494:   8d 74 26 00             lea    0x0(%esi),%esi
 498:   e8 fc ff ff ff          call   499 <pixman_blt+0x79>
 49d:   a3 00 00 00 00          mov    %eax,0x0
 4a2:   8d b6 00 00 00 00       lea    0x0(%esi),%esi
 4a8:   eb 86                   jmp    430 <pixman_blt+0x10>
 4aa:   8d b6 00 00 00 00       lea    0x0(%esi),%esi


ARM, gcc 4.3.4:

000003a4 <pixman_blt>:
 3a4:   e92d41f0        push    {r4, r5, r6, r7, r8, lr}
 3a8:   e59f4088        ldr     r4, [pc, #136]  ; 438 <pixman_blt+0x94>
 3ac:   e1a08001        mov     r8, r1
 3b0:   e24dd028        sub     sp, sp, #40     ; 0x28
 3b4:   e5941000        ldr     r1, [r4]
 3b8:   e1a06000        mov     r6, r0
 3bc:   e3510000        cmp     r1, #0  ; 0x0
 3c0:   e1a07002        mov     r7, r2
 3c4:   e1a05003        mov     r5, r3
 3c8:   0a000017        beq     42c <pixman_blt+0x88>
 3cc:   e59dc040        ldr     ip, [sp, #64]
 3d0:   e5940000        ldr     r0, [r4]
 3d4:   e59de044        ldr     lr, [sp, #68]
 3d8:   e58dc004        str     ip, [sp, #4]
 3dc:   e59dc048        ldr     ip, [sp, #72]
 3e0:   e58de008        str     lr, [sp, #8]
 3e4:   e59de04c        ldr     lr, [sp, #76]
 3e8:   e58dc00c        str     ip, [sp, #12]
 3ec:   e59dc050        ldr     ip, [sp, #80]
 3f0:   e58de010        str     lr, [sp, #16]
 3f4:   e59d405c        ldr     r4, [sp, #92]
 3f8:   e58dc014        str     ip, [sp, #20]
 3fc:   e59de054        ldr     lr, [sp, #84]
 400:   e59dc058        ldr     ip, [sp, #88]
 404:   e1a01006        mov     r1, r6
 408:   e1a02008        mov     r2, r8
 40c:   e1a03007        mov     r3, r7
 410:   e58d5000        str     r5, [sp]
 414:   e58de018        str     lr, [sp, #24]
 418:   e58dc01c        str     ip, [sp, #28]
 41c:   e58d4020        str     r4, [sp, #32]
 420:   ebfffffe        bl      0 <_pixman_implementation_blt>
 424:   e28dd028        add     sp, sp, #40     ; 0x28
 428:   e8bd81f0        pop     {r4, r5, r6, r7, r8, pc}
 42c:   ebfffffe        bl      0 <_pixman_choose_implementation>
 430:   e5840000        str     r0, [r4]
 434:   eaffffe4        b       3cc <pixman_blt+0x28>
 438:   00000000        .word   0x00000000

-- 
Best regards,
Siarhei Siamashka

From tgriggs at cincom.com  Mon Oct 19 19:38:07 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Mon, 19 Oct 2009 19:38:07 -0700
Subject: [cairo] Another set of OSX Build Instructions
Message-ID: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>

I've been playing with refactoring build instructions found on the  
wiki out of the downloads page, and on to a separate Building page,  
with recipes for doing different builds.

I've just finished http://cairographics.org/end_to_end_build_for_mac_os_x/ 
  and would love to hear any feedback before writing up the end-to-end  
version I have for win32. It would be nice to kind of templatize  
these. I've begun a rudimentary page to act as a list of these (http://cairographics.org/building/ 
).

--
Travis Griggs
Objologist
My Other Machine runs OSX. But then... so does this one.




From mpsuzuki at hiroshima-u.ac.jp  Mon Oct 19 20:12:02 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Tue, 20 Oct 2009 12:12:02 +0900
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
Message-ID: <20091020121202.2c45a1ae.mpsuzuki@hiroshima-u.ac.jp>

Hi,

On Mon, 19 Oct 2009 19:38:07 -0700
Travis Griggs <tgriggs at cincom.com> wrote:
>I've been playing with refactoring build instructions found on the  
>wiki out of the downloads page, and on to a separate Building page,  
>with recipes for doing different builds.

Good work today.

>I've just finished http://cairographics.org/end_to_end_build_for_mac_os_x/ 
>  and would love to hear any feedback before writing up the end-to-end  
>version I have for win32.

Unintentionally, when I installed Mono SDK on Mac OS X 10.4,
it replaced pkg-config by new one. I thank you for writing
that "Apple-genuine" pkg-config bundled to Xcode was legacy :-).
Also your note that "png" issue would be useful.

About the syntax of "export" command, I think,

 export LDFLAGS=-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

is not safe, quoting might be recommended, like this.

 export LDFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"

There is a typo "x85_64" which should be "x86_64".

And, giving the list of backends detected/enabled by
default would be helpful.

Regards,
mpsuzuki

From ben at happyspork.com  Mon Oct 19 20:35:56 2009
From: ben at happyspork.com (Ben Anderman)
Date: Mon, 19 Oct 2009 23:35:56 -0400
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
Message-ID: <306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>

I haven't finished yet, but I'm going to bed now. Here's a couple  
problems:
mkdir ${BuildDir) has a closing bracket instead of brace.
Typo in tar -xzf pkconfig.tgz (missing the g in pkg).
The mv lines (like "mv pkg* pkgconfig") won't work properly because  
the .tgz files are still there, and are matched by the glob.

I also think it'd be good to make it clear that these are dylibs, not  
frameworks, and that they're made to be packaged inside a .app. It  
doesn't specifically claim that they are frameworks, but it makes it  
sound like they are (in my opinion).

Other than that it looks pretty good, and it's definitely a nice thing  
to have!

Ben
(Mac Packager for Wesnoth)

On Oct 19, 2009, at 10:38 PM, Travis Griggs wrote:

> I've been playing with refactoring build instructions found on the
> wiki out of the downloads page, and on to a separate Building page,
> with recipes for doing different builds.
>
> I've just finished http://cairographics.org/end_to_end_build_for_mac_os_x/
>  and would love to hear any feedback before writing up the end-to-end
> version I have for win32. It would be nice to kind of templatize
> these. I've begun a rudimentary page to act as a list of these (http://cairographics.org/building/
> ).
>
> --
> Travis Griggs
> Objologist
> My Other Machine runs OSX. But then... so does this one.
>
>
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From tgriggs at cincom.com  Mon Oct 19 21:29:49 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Mon, 19 Oct 2009 21:29:49 -0700
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <20091020121202.2c45a1ae.mpsuzuki@hiroshima-u.ac.jp>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<20091020121202.2c45a1ae.mpsuzuki@hiroshima-u.ac.jp>
Message-ID: <09AEFDF6-0D17-49A3-9ADC-FBC0F3EE8EFB@cincom.com>


On Oct 19, 2009, at 8:12 PM, mpsuzuki at hiroshima-u.ac.jp wrote:

> Hi,
>
> On Mon, 19 Oct 2009 19:38:07 -0700
> Travis Griggs <tgriggs at cincom.com> wrote:
>> I've been playing with refactoring build instructions found on the
>> wiki out of the downloads page, and on to a separate Building page,
>> with recipes for doing different builds.
>
> Good work today.
>
>> I've just finished http://cairographics.org/end_to_end_build_for_mac_os_x/
>> and would love to hear any feedback before writing up the end-to-end
>> version I have for win32.
>
> Unintentionally, when I installed Mono SDK on Mac OS X 10.4,
> it replaced pkg-config by new one. I thank you for writing
> that "Apple-genuine" pkg-config bundled to Xcode was legacy :-).
> Also your note that "png" issue would be useful.
>
> About the syntax of "export" command, I think,
>
> export LDFLAGS=-arch ppc -arch i386 -isysroot /Developer/SDKs/ 
> MacOSX10.4u.sdk
>
> is not safe, quoting might be recommended, like this.
>
> export LDFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/ 
> MacOSX10.4u.sdk"

Yes, indeed. I copied these lines from a Herl script where the syntax  
is a little different. Thank you.
>
> There is a typo "x85_64" which should be "x86_64".

Fixed too.
>
> And, giving the list of backends detected/enabled by
> default would be helpful.


Noted at the top, as well in an explanation farther down about why -- 
disable-xlib is turned on.

Thanks!

--
Travis Griggs
Objologist
"Some people are like slinkies, not really good for much, but they can  
bring a smile to your face when you push them down the stairs."


From stephen at stephengentle.com  Mon Oct 19 21:39:30 2009
From: stephen at stephengentle.com (Stephen Gentle)
Date: Tue, 20 Oct 2009 14:39:30 +1000
Subject: [cairo] Memory usage in OpenGL Cairo UI
Message-ID: <784de37a0910192139h73b78b14iae8165aba72a8e3c@mail.gmail.com>

Hi,

I'm trying to make an application which uses Cairomm with OpenGL to
render its interface. Currently, all the controls have Image Surfaces
which are then painted onto a master image surface which is used for
the texture of the interface. The background of the surface is
transparent and I have other things under this surface so it's all
blended nicely. The problem with this approach though is that I'm
using a lot of memory to just draw the UI. So I was wondering what is
the better option:

1. I create surfaces when the screen needs to be redrawn, and then
delete them afterwards
or,
2. I use only one surface and have all the controls draw directly onto that

Now, option 1 doesn't seem that bad now but I'm concerned that there
could be performance problems in the future as I have more and more
controls on the screen at once. So option 2 sounds better, but I'm not
sure if its possible. I would want the cairo context to act as if the
coordinates 0,0 were the top left hand corner of the widget that I'm
drawing, and not the top corner of the window. I can create a clip
region around the control to stop it drawing to other areas of the
screen, but it draws in the wrong place. Is there a way to change the
coordinate system to fix this?

Of course, one other option is to have an OpenGL quad for every
control, but that would be quite a bit more complex, and would only
let me get rid of the master surface, which is only about six to eight
MB. Is this the way to go?

Thanks,

Stephen

From tgriggs at cincom.com  Mon Oct 19 22:20:02 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Mon, 19 Oct 2009 22:20:02 -0700
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
Message-ID: <E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>


On Oct 19, 2009, at 8:35 PM, Ben Anderman wrote:

> I haven't finished yet, but I'm going to bed now. Here's a couple  
> problems:
> mkdir ${BuildDir) has a closing bracket instead of brace.
> Typo in tar -xzf pkconfig.tgz (missing the g in pkg).
> The mv lines (like "mv pkg* pkgconfig") won't work properly because  
> the .tgz files are still there, and are matched by the glob.
>
> I also think it'd be good to make it clear that these are dylibs,  
> not frameworks, and that they're made to be packaged inside a .app.  
> It doesn't specifically claim that they are frameworks, but it makes  
> it sound like they are (in my opinion).
>
> Other than that it looks pretty good, and it's definitely a nice  
> thing to have!

Suppose I should actually test my own page, huh? :)

I've done so now, making sure one can simply copy-paste between  
browser and command line.

Thanks for the feedback.

I'm assuming that the actual "style" is OK with people then? Getting a  
lot of good technical feedback, the actual layout doesn't seem to be  
raising too many concerns. I'll write up the Windows one along the  
same lines tomorrow.

--
Travis Griggs
Objologist
"The project was so plagued by politics and ego that when the  
engineers requested technical oversight, our manager hired a  
psychologist instead." -- Ron Avitzur


From mpsuzuki at hiroshima-u.ac.jp  Mon Oct 19 22:20:04 2009
From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki at hiroshima-u.ac.jp)
Date: Tue, 20 Oct 2009 14:20:04 +0900
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <09AEFDF6-0D17-49A3-9ADC-FBC0F3EE8EFB@cincom.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>	<20091020121202.2c45a1ae.mpsuzuki@hiroshima-u.ac.jp>
	<09AEFDF6-0D17-49A3-9ADC-FBC0F3EE8EFB@cincom.com>
Message-ID: <4ADD4884.90700@hiroshima-u.ac.jp>

>> And, giving the list of backends detected/enabled by
>> default would be helpful.
> 
> Noted at the top, as well in an explanation farther down about why -- 
> disable-xlib is turned on.

I'm sorry, I didn't clarify what I wished...
I wish if you could copy the end of the output
by ./configure, something like:

The following surface backends:
...
   Quartz: ...
   Quartz-image: ...
...

It is helpful for users to check their configuration
was correctly finished, or there is anything wrong.

Regards,
mpsuzuki


From ratmice at gmail.com  Tue Oct 20 00:46:39 2009
From: ratmice at gmail.com (Matt Rice)
Date: Tue, 20 Oct 2009 00:46:39 -0700
Subject: [cairo] Memory usage in OpenGL Cairo UI
In-Reply-To: <784de37a0910192139h73b78b14iae8165aba72a8e3c@mail.gmail.com>
References: <784de37a0910192139h73b78b14iae8165aba72a8e3c@mail.gmail.com>
Message-ID: <8ba6bed40910200046g6b6dcca3hc1f28b1dacc0c24d@mail.gmail.com>

On Mon, Oct 19, 2009 at 9:39 PM, Stephen Gentle
<stephen at stephengentle.com> wrote:
>
> 2. I use only one surface and have all the controls draw directly onto that
>
> So option 2 sounds better, but I'm not
> sure if its possible. I would want the cairo context to act as if the
> coordinates 0,0 were the top left hand corner of the widget that I'm
> drawing, and not the top corner of the window. I can create a clip
> region around the control to stop it drawing to other areas of the
> screen, but it draws in the wrong place. Is there a way to change the
> coordinate system to fix this?

it sounds like you want cairo_translate()

http://cairographics.org/manual/cairo-transformations.html#cairo-translate

From stephen at stephengentle.com  Tue Oct 20 01:18:18 2009
From: stephen at stephengentle.com (Stephen Gentle)
Date: Tue, 20 Oct 2009 18:18:18 +1000
Subject: [cairo] Memory usage in OpenGL Cairo UI
In-Reply-To: <784de37a0910200116p422423eeo7bfad495a4d97b0c@mail.gmail.com>
References: <784de37a0910192139h73b78b14iae8165aba72a8e3c@mail.gmail.com>
	<8ba6bed40910200046g6b6dcca3hc1f28b1dacc0c24d@mail.gmail.com>
	<784de37a0910200116p422423eeo7bfad495a4d97b0c@mail.gmail.com>
Message-ID: <784de37a0910200118u7ee21ac1h37dd4665e44d0756@mail.gmail.com>

On Tue, Oct 20, 2009 at 5:46 PM, Matt Rice <ratmice at gmail.com> wrote:
> On Mon, Oct 19, 2009 at 9:39 PM, Stephen Gentle
> <stephen at stephengentle.com> wrote:
>>
>> 2. I use only one surface and have all the controls draw directly onto that
>>
>> So option 2 sounds better, but I'm not
>> sure if its possible. I would want the cairo context to act as if the
>> coordinates 0,0 were the top left hand corner of the widget that I'm
>> drawing, and not the top corner of the window. I can create a clip
>> region around the control to stop it drawing to other areas of the
>> screen, but it draws in the wrong place. Is there a way to change the
>> coordinate system to fix this?
>
> it sounds like you want cairo_translate()
>
> http://cairographics.org/manual/cairo-transformations.html#cairo-translate
>

That works perfectly, thanks! I thought there must be a way but I
couldn't find it.

Do you think this is the best way to go then?

From francois at bobot.eu  Tue Oct 20 01:04:46 2009
From: francois at bobot.eu (=?ISO-8859-1?Q?Fran=E7ois_Bobot?=)
Date: Tue, 20 Oct 2009 10:04:46 +0200
Subject: [cairo] Mlpost is pleased to use Cairo
Message-ID: <4ADD6F1E.6080008@bobot.eu>

Hi,

  Mlpost is an Objective Caml interface to Metapost. So it allows to
create pictures with LaTeX snippets in it. Since version 0.7 Mlpost has
a new backend which use Cairo for the drawing. We use the binding
cairo-ocaml. Thanks to Cairo, Mlpost can produce ps,pdf,png,svg...
directly now, and Mlpost pictures can be used in gtk+ window.

Thank you for this great library and that great number of backends.


http://mlpost.lri.fr/

Examples can be found at http://mlpost.lri.fr/examples/. They are
produced by the Metapost backend but they can be produced with the same
result with the Cairo backend.

-- 
Mlpost authors

From chris at chris-wilson.co.uk  Tue Oct 20 01:39:20 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 20 Oct 2009 09:39:20 +0100
Subject: [cairo] Memory usage in OpenGL Cairo UI
In-Reply-To: <784de37a0910200118u7ee21ac1h37dd4665e44d0756@mail.gmail.com>
References: <784de37a0910192139h73b78b14iae8165aba72a8e3c@mail.gmail.com>
	<8ba6bed40910200046g6b6dcca3hc1f28b1dacc0c24d@mail.gmail.com>
	<784de37a0910200116p422423eeo7bfad495a4d97b0c@mail.gmail.com>
	<784de37a0910200118u7ee21ac1h37dd4665e44d0756@mail.gmail.com>
Message-ID: <1256027366-sup-8321@broadwater.alporthouse.com>

Excerpts from Stephen Gentle's message of Tue Oct 20 09:18:18 +0100 2009:
> > On Mon, Oct 19, 2009 at 9:39 PM, Stephen Gentle
> > <stephen at stephengentle.com> wrote:
> >>
> >> 2. I use only one surface and have all the controls draw directly onto that
> 
> Do you think this is the best way to go then?

Yes. Track the damage extents (probably best as a region, or a set of
non-overlapping rectangles) and use TexSubImage to download the dirty
pixels to your texture. (Alas, damage tracking is not part of the cairo
API, yet.)

In the near future, the cairo-gl backend will have matured sufficiently
that you will be able to use cairo to render into the texture or
framebuffer directly (with the premise of full GPU acceleration) which
will eliminate the need for the additional temporary storage and
management on your part. With rendering via the GPU (be it direct or via
XRender, though here you depend upon mature drivers and lack of
pre-emption from other clients) there is a significant advantage to
maintaining a single target buffer, again favouring the second option.

Hope this helps, and you are having fun using Cairo!
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From k.kooi at student.utwente.nl  Tue Oct 20 04:11:05 2009
From: k.kooi at student.utwente.nl (Koen Kooi)
Date: Tue, 20 Oct 2009 13:11:05 +0200
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <200910200035.22394.siarhei.siamashka@gmail.com>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
	<200910200035.22394.siarhei.siamashka@gmail.com>
Message-ID: <hbk5sa$m83$1@ger.gmane.org>

On 19-10-09 23:35, Siarhei Siamashka wrote:
> On Wednesday 14 October 2009, Siarhei Siamashka wrote:
>> Hello,
>>
>> This branch has new ARM NEON optimizations:
>> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=arm-neon-update
>
> [...]
>
> Pushed the first commit to master. It only contains removal of unused and
> commented out code. It was safe to apply, and this kind of housekeeping is
> needed anyway before introducing something new here.
>
> Regarding the other changes. I'm somewhat tempted to push them too :)

I'm running master + your remaining patches and I can't spot any bugs on 
omap3. I haven't tried any benchmarking whatsoever.

regards,

Koen


From ashley at ashleymills.com  Tue Oct 20 05:31:55 2009
From: ashley at ashleymills.com (ashley at ashleymills.com)
Date: Tue, 20 Oct 2009 21:31:55 +0900
Subject: [cairo] Cannot get transformations to work
Message-ID: <220b1a489448154606a7730aa9505580.squirrel@webmail.ashleymills.com>

Hi, I'm using cairo, compiled on Windows under Visual Studio Express 2008.
Pretty much everything works, and its possible this could be a bug due to
my compilation. I think its more likely I'm just doing something dumb.

I can't seem to get any transformations to work, here is my code:

	// create 24bit RGB drawing surface of the appropriate size
	cairo_surface_t *cairoSurface =
		cairo_image_surface_create(CAIRO_FORMAT_RGB24, 500, 500);
	cairo_t *cairoState = cairo_create(cairoSurface);

	// set its background to white
	cairo_set_source_rgb(cairoState,1, 1, 1);
	cairo_rectangle(cairoState,0,0,500,500);
	cairo_fill(cairoState);

	// define arrow object
	double arrowHeadAngle = 2*M_PI/360*45;
	double arrowLength = 50;
	cairo_t *arrowState = cairo_create(cairoSurface);
	cairo_set_line_width (arrowState, 1);
	// define arrow body
	cairo_new_path(arrowState);
	double arrowStartX = 0;
	double arrowStartY = 0;
	cairo_move_to(arrowState,arrowStartX,arrowStartY);
	double arrowEndX = arrowStartX + arrowLength;
	double arrowEndY = arrowStartY;
	cairo_line_to(arrowState,arrowEndX,arrowEndY);
	// define arrow head left
	cairo_arc(arrowState,arrowEndX,arrowEndY,arrowLength*0.2,M_PI-arrowHeadAngle,M_PI);
	cairo_line_to(arrowState,arrowEndX,arrowEndY);
	// define arrow head right
	cairo_arc(arrowState,arrowEndX,arrowEndY,arrowLength*0.2,M_PI,M_PI+arrowHeadAngle);
	cairo_line_to(arrowState,arrowEndX,arrowEndY);

	// draw arrow
	cairo_matrix_t* cairoMatrix = new cairo_matrix_t;
	cairo_matrix_init_identity(cairoMatrix);
	cairo_set_matrix(arrowState,cairoMatrix);
	cairo_set_source_rgb(arrowState,0,1,0);
	cairo_stroke_preserve(arrowState);

	// draw rotated and translated version of arrow
	cairo_translate(arrowState,100,100);
	cairo_rotate(arrowState,M_PI/2);
	cairo_set_source_rgb(arrowState,1,0,0);
	cairo_stroke_preserve(arrowState);

	// cleanup the cairo stuff
	cairo_surface_write_to_png (cairoSurface, "test.png");
    	cairo_surface_destroy(cairoSurface);
	cairo_destroy(cairoState);
	cairo_destroy(arrowState);

No matter what I do, I cannot seem to get the arrow to be drawn anywhere
else but the origin without rotation. The calls to translate and rotate
appear to do nothing. I checked its error status and all calls return
success. The arrow is red, so the second call to cairo_stroke_preserve is
definitely writing to the surface.

Am I doing something obviously incorrect here in my usage?

Thanks

Ashley Mills

P.S. Great library :)




From kalle.vahlman at gmail.com  Tue Oct 20 06:40:40 2009
From: kalle.vahlman at gmail.com (Kalle Vahlman)
Date: Tue, 20 Oct 2009 16:40:40 +0300
Subject: [cairo] Cannot get transformations to work
In-Reply-To: <220b1a489448154606a7730aa9505580.squirrel@webmail.ashleymills.com>
References: <220b1a489448154606a7730aa9505580.squirrel@webmail.ashleymills.com>
Message-ID: <177e83dd0910200640i4b443eedldbd61f0aa4b5d0f9@mail.gmail.com>

2009/10/20  <ashley at ashleymills.com>:
[snip]
> Am I doing something obviously incorrect here in my usage?

Yes, as the transformations only apply to paths drawn *after* the
calls to _translate() and _rotate().

So you can't "move" the path after defining it. To do that there's
three options (of which I'm aware):

 * copy the path with cairo_copy_path() and add it back after
translating using cairo_append_path()
 * separate the arrow drawing to a function and call it twice
 * render the arrow to a temporary surface and translating that

The last option is probably going to be the fastest, but is also
subject to rasterization so the quality might not be satisfactory. The
second is what people usually do I think.

Cairo gurus please correct me if I'm talking silly talk :)

-- 
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
See also http://syslog.movial.fi

From sandmann at daimi.au.dk  Tue Oct 20 06:46:51 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 20 Oct 2009 15:46:51 +0200
Subject: [cairo] [PATCH] [API] Support component-alpha.
In-Reply-To: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>
References: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>
Message-ID: <ye8ljj6npo4.fsf@camel26.daimi.au.dk>

Chris Wilson <chris at chris-wilson.co.uk> writes:

> So we need component-alpha support on patterns internally, so present
> the same power to the users as well. For indeed, they may well be
> dreaming of demonstrating sub-pixel geometry masks...

Would this be expected to be useful for gradients, or would it be
considered some crazy thing you could set if you knew what you were
doing?

I could sort of see a gradient from say 

        (ffff, ffee, ffdd) 

to 

        (0022, 0011, 0000) 

being interesting as a component alpha mask, but the documentation for
the proposed API implies that no filtering or gamma correction would
takes place, which would result in color errors. And expecting users
to compute pixel values from a gradient is not really in the spirit of
cairo.


Soren

From chris at chris-wilson.co.uk  Tue Oct 20 07:21:22 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 20 Oct 2009 15:21:22 +0100
Subject: [cairo] [PATCH] [API] Support component-alpha.
In-Reply-To: <ye8ljj6npo4.fsf@camel26.daimi.au.dk>
References: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>
	<ye8ljj6npo4.fsf@camel26.daimi.au.dk>
Message-ID: <1256047492-sup-5288@broadwater.alporthouse.com>

Excerpts from Soeren Sandmann's message of Tue Oct 20 14:46:51 +0100 2009:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > So we need component-alpha support on patterns internally, so present
> > the same power to the users as well. For indeed, they may well be
> > dreaming of demonstrating sub-pixel geometry masks...
> 
> Would this be expected to be useful for gradients, or would it be
> considered some crazy thing you could set if you knew what you were
> doing?

Your right in that the principal use case is to allow sub-pixel surface
masks to be supplied. I can see gradients being interesting as well, but
the scenarios I can envisage for using gradients all seem to imply that
the user needs to supply the complete sub-pixel mask anyway. I'm probably
just not being imaginative enough.
 
> I could sort of see a gradient from say 
> 
>         (ffff, ffee, ffdd) 
> 
> to 
> 
>         (0022, 0011, 0000) 
> 
> being interesting as a component alpha mask, but the documentation for
> the proposed API implies that no filtering or gamma correction would
> takes place, which would result in color errors. And expecting users
> to compute pixel values from a gradient is not really in the spirit of
> cairo.

Hmm, I can appreciate that using a per-component mask complicates
everything, but how does this actually differ from cairo/pixman
currently for normal gradients?

At the moment there are a few bugs in Cairo where a per-component glyph
mask is being generated, but that information is not being passed along
to the rasteriser (the most obvious example is fallback glyph rendering
for xlib). The question simply becomes: can we define how per-component
alpha masks are supposed to operate and so be exported to users?
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From ashley at ashleymills.com  Tue Oct 20 07:52:23 2009
From: ashley at ashleymills.com (ashley at ashleymills.com)
Date: Tue, 20 Oct 2009 23:52:23 +0900
Subject: [cairo] Cannot get transformations to work
In-Reply-To: <177e83dd0910200640i4b443eedldbd61f0aa4b5d0f9@mail.gmail.com>
References: <220b1a489448154606a7730aa9505580.squirrel@webmail.ashleymills.com>
	<177e83dd0910200640i4b443eedldbd61f0aa4b5d0f9@mail.gmail.com>
Message-ID: <0be656c20119451c684df42dea5b4899.squirrel@webmail.ashleymills.com>

> 2009/10/20  <ashley at ashleymills.com>:
> [snip]
>> Am I doing something obviously incorrect here in my usage?
>
> Yes, as the transformations only apply to paths drawn *after* the
> calls to _translate() and _rotate().

I see. I suppose you already guessed this: I was imagining that the path
vertices themselves were being transformed.

> So you can't "move" the path after defining it. To do that there's
> three options (of which I'm aware):
>
>  * copy the path with cairo_copy_path() and add it back after
> translating using cairo_append_path()
>  * separate the arrow drawing to a function and call it twice
>  * render the arrow to a temporary surface and translating that

OK I'll just write it as a function instead for now. Thanks.

I assume then that 3rd option would be the standard way to transform a
bunch of points?

How would one go about copying the temporary surface back onto the
original surface?

> The last option is probably going to be the fastest, but is also
> subject to rasterization so the quality might not be satisfactory. The
> second is what people usually do I think.

What would be subject to rasterization? The printing onto the temporary
surface? Oh I see, so then the surfaces would be combined by simply adding
them together according to opacity?

Thanks

Ashley



From sandmann at daimi.au.dk  Tue Oct 20 08:29:05 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 20 Oct 2009 17:29:05 +0200
Subject: [cairo] [PATCH] [API] Support component-alpha.
In-Reply-To: <1256047492-sup-5288@broadwater.alporthouse.com>
References: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>
	<ye8ljj6npo4.fsf@camel26.daimi.au.dk>
	<1256047492-sup-5288@broadwater.alporthouse.com>
Message-ID: <ye8hbtunkxq.fsf@camel26.daimi.au.dk>

Chris Wilson <chris at chris-wilson.co.uk> writes:

> Hmm, I can appreciate that using a per-component mask complicates
> everything, but how does this actually differ from cairo/pixman
> currently for normal gradients?
> 
> At the moment there are a few bugs in Cairo where a per-component glyph
> mask is being generated, but that information is not being passed along
> to the rasteriser (the most obvious example is fallback glyph rendering
> for xlib). The question simply becomes: can we define how per-component
> alpha masks are supposed to operate and so be exported to users?

Well, there are two subtly different concepts in play here:

1. The concept of a 'three times horizontally supersampled image'

2. The concept of 'values to be presented to an output device'

It seems to me that (1) is the only thing a user can really be
expected to provide, because while (2) can be computed from (1), to do
a good job of it, you have to know about device characteristics and
human vision, then apply appropriate filtering and correction. You
also need to control which color space compositing takes place in.

If the component_alpha pattern property uses interpretation (2), then
we are effectively asking users to use their understanding of cairo
internals to compute something quite non-trivial.

In principle, component alpha could be supported as a property on
surfaces that says "when rendering to this surface, assume that it
will eventually be displayed on a subpixel-capable
monitor". Gradients, fonts and geometry rendered to such a surface
would then be supersampled and filtered appropriately by cairo.

A "supersampled" property on image patterns would then indicate that
the image was horizontally supersampled three times. Rendering could
make use of this information any way it wanted to. The property would
be ignored for gradients, just as filters are currently ignored.

I'm not really arguing for or against the proposed API, just trying to
make sure it has well-defined semantics.


Soren

From tgriggs at cincom.com  Tue Oct 20 09:02:12 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Tue, 20 Oct 2009 09:02:12 -0700
Subject: [cairo] OSX build regression in 1.9.4
Message-ID: <297B5BDD-D5FF-4FEE-98C2-C9F1A7E18B93@cincom.com>

Exact same CPU/OS configuration. With 1.8.8, ./configure --disable- 
xlib was enough (either directly, or just by chance) to NOT have the  
FreeType backend built. The same in 1.9.4 now turns on the FreeType  
back end. And then it won't link. All kinds of unresolved _FT_blah  
symbols. Adding --disable-ft fixes the problem. Was this an intended  
change in the build scripts?

--
Travis Griggs
Objologist
I patented thinking... and I still can't find anyone infringing.


From chris at chris-wilson.co.uk  Tue Oct 20 09:07:20 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 20 Oct 2009 17:07:20 +0100
Subject: [cairo] [PATCH] [API] Support component-alpha.
In-Reply-To: <ye8hbtunkxq.fsf@camel26.daimi.au.dk>
References: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>
	<ye8ljj6npo4.fsf@camel26.daimi.au.dk>
	<1256047492-sup-5288@broadwater.alporthouse.com>
	<ye8hbtunkxq.fsf@camel26.daimi.au.dk>
Message-ID: <1256054177-sup-4781@broadwater.alporthouse.com>

Excerpts from Soeren Sandmann's message of Tue Oct 20 16:29:05 +0100 2009:
> Well, there are two subtly different concepts in play here:
> 
> 1. The concept of a 'three times horizontally supersampled image'
> 
> 2. The concept of 'values to be presented to an output device'
> 
> It seems to me that (1) is the only thing a user can really be
> expected to provide, because while (2) can be computed from (1), to do
> a good job of it, you have to know about device characteristics and
> human vision, then apply appropriate filtering and correction. You
> also need to control which color space compositing takes place in.
> 
> If the component_alpha pattern property uses interpretation (2), then
> we are effectively asking users to use their understanding of cairo
> internals to compute something quite non-trivial.

Hmm, I was approaching this from the "how can I generate sub-pixel
geometry masks to perform CAIRO_ANTIALIAS_SUBPIXEL with Render". Which
as you point out requires the knowledge (as provided by Render) of the
sub-pixel layout. That knowledge can only be sanely handled internally,
as it is meaningless for the rest of cairo and indeed is out of scope.

Ok, I'm convinced that the antialias property that we currently expose
on the context (hence target surface) is the way to go here and that
exposing per-component alpha is insane.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From mkbosmans at gmail.com  Tue Oct 20 13:58:27 2009
From: mkbosmans at gmail.com (Maarten Bosmans)
Date: Tue, 20 Oct 2009 22:58:27 +0200
Subject: [cairo] Cannot get transformations to work
In-Reply-To: <0be656c20119451c684df42dea5b4899.squirrel@webmail.ashleymills.com>
References: <220b1a489448154606a7730aa9505580.squirrel@webmail.ashleymills.com>
	<177e83dd0910200640i4b443eedldbd61f0aa4b5d0f9@mail.gmail.com>
	<0be656c20119451c684df42dea5b4899.squirrel@webmail.ashleymills.com>
Message-ID: <3cb866720910201358r4b0cbf7dl84769651ef7b39a5@mail.gmail.com>

2009/10/20  <ashley at ashleymills.com>:
> I see. I suppose you already guessed this: I was imagining that the path
> vertices themselves were being transformed.

May be the text on this page can help you understand the transformations better.
http://cairographics.org/tutorial/#L2linewidth
Note that how the path of both circles is transformed by the
cairo_scale call, but only the line width of the left one distorded.

> OK I'll just write it as a function instead for now. Thanks.

Tip: It is generally a good idea to start and end drawing functions
with a cairo_save and cairo_restore call, like in the example linked
above. This way you can apply the transformations you need to get the
arrow in the right place, without affecting other drawing routines
outside your arrow-function.

> I assume then that 3rd option would be the standard way to transform a
> bunch of points?

I would only choose this option if you need it for performance reasons.

> How would one go about copying the temporary surface back onto the
> original surface?

cairo_set_source_surface followed by a cairo_paint or a path fill.

>> The last option is probably going to be the fastest, but is also
>> subject to rasterization so the quality might not be satisfactory. The
>> second is what people usually do I think.
>
> What would be subject to rasterization? The printing onto the temporary
> surface? Oh I see, so then the surfaces would be combined by simply adding
> them together according to opacity?

Yep, or according to any other blend mode operator you choose.
Remember that you probably want whole pixel offsets when compositing
the temporary surface back on your drawing surface.

> Thanks
>
> Ashley

Maarten

From sandmann at daimi.au.dk  Tue Oct 20 15:34:30 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 21 Oct 2009 00:34:30 +0200
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <200910200233.44965.siarhei.siamashka@gmail.com>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<200910200013.15632.siarhei.siamashka@gmail.com>
	<ye8vdibf26i.fsf@camel22.daimi.au.dk>
	<200910200233.44965.siarhei.siamashka@gmail.com>
Message-ID: <ye8pr8hheyx.fsf@camel27.daimi.au.dk>

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> First introduce something like 'pixman_init' function. Right now CPU type
> detection is done on the first call to the function. It introduces some
> minor overhead by having an extra pointer check on each function call.
> Another problem is that we can't be completely sure that CPU capabilities
> detection check is always fully reentrant. For example, some platforms may
> try to set a signal handler and expect to catch SIGILL or something like
> this.
> 
> This initialization function would just detect CPU capabilities and set some
> function pointers. The whole CPU-specific implementation of 'pixman_blt'
> may be just called via this pointer directly by a client. Or 'pixman_blt' can
> be just a small thunk which does a call via function pointer, passes exactly
> the same arguments to it and does nothing more. In this case there will be
> really no excuse for the compiler for not using tail call, see
> below.

Adding a pixman_init() that applications would be required to call
first, would not be a compatible change. If we are designing new API,
then I really think it should be done in such a way that it can be
extended to handle the core rendering primitives.

It does likely make sense to make the pixman_implementation_t type
public at some point (renamed to pixman_t probably) and then pass it
directly to the various entry points. This would be necessary if we
add hardware acceleration to pixman.

> > Also, I really don't see much potential for saving here. For a NEON
> > implementation of blt, the callchain would be:
> >
> >    pixman_blt() ->  _pixman_implementation_blt() -> neon_blt()
> >
> > and getting rid of delegates wouldn't really affect that at all. You
> > could get rid of the _pixman_implementation_blt() call by making it a
> > macro, but as I mentioned before, gcc turns it into a tail call that
> > reused the arguments on the stack, so the overhead really is minimal.
> 
> On what kind of platform and with which version of gcc are you getting
> proper tail call here? 

I meant that the 

        _pixman_implemenation_blt() -> neon_blt()

would be a tail call. GCC v 4.3.2 on x86-32 produces:

        _pixman_implementation_blt:
                pushl   %ebp
                movl    %esp, %ebp
                movl    8(%ebp), %edx
                popl    %ebp
                movl    12(%edx), %ecx
                jmp     *%ecx
                .size   _pixman_implementation_blt,
                .-_pixman_implementation_blt
                .p2align 4,,15

> I don't see it being used and the overhead is rather hefty, which is
> also confirmed by benchmarking and profiling.

Well, with a microbenchmark you can make anything stand out.
Ultimately, this function is called from XCopyArea(), and compared to
the marshalling of the client call and the long call chain inside the
X server, these 35 instructions or so, really are not very
significant.

I think Jonathan said that pixman_blt() was getting called once per
scanline, but I'm pretty sure that's not the case. (Or if it is, that
would be the first thing to fix before worrying about eliminating this
call).


Soren

From eric at anholt.net  Tue Oct 20 15:56:34 2009
From: eric at anholt.net (Eric Anholt)
Date: Tue, 20 Oct 2009 15:56:34 -0700
Subject: [cairo] update on cairo-gl performance
Message-ID: <1256079394.4771.21.camel@gaiman.anholt.net>

Just thought I'd throw out some new numbers here in case people were
curious.  This is 2.6.32-rc4, cairo master, libdrm master, mesa master,
2d master, pixman from august 12th.  Hardware is Lenovo T61, GM965, 2G
ram, 2Ghz Core 2 Duo.

Note that this isn't apples-to-apples yet.  cairo-gl doesn't do
component alpha, so any subpixel text in these tests won't be rendered
correctly.  I'm not sure how the setup is supposed to work in a cairo
backend, so I haven't fixed it yet.  Anyone understand that?

I've done most of my profiling on firefox-talos-gfx, and through fixes
mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
on this hardware to 56 seconds.  At this point, the test consumes around
90% of the CPU still, while around 10% of the time it's idle blocked on
the hardware due to the useless clears of temporary buffers.

What's coming up in cairo-gl:
      * cworth is working on GLSL.  This will reduce the CPU usage for
        state updates, and give us the framework for supporting
        gradients and possibly even better shaders for other compositing
        than we're doing today with the old nasty fixed function
        pipeline.
      * ickle is going to be avoiding the extra clears of buffers that
        are used internally in cairo.  This should be a good win for
        both xlib and gl.
      * I'm going to keep working on performance outside of cairo.  My
        next stop will be the gvim trace, I think.  Something's going
        terribly wrong with memory consumption in this one.
      * Once I've got some piglit testcases (should be soon), I'll add
        support for GL_ALPHA fbos to the intel GL drivers, which should
        cut memory bandwidth consumption for our masks.

Finally, the numbers:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image            firefox-talos-gfx   44.507   44.591   0.13%    3/3
[  0]       gl            firefox-talos-gfx   56.005   56.231   0.37%    3/3
[  0]     xlib            firefox-talos-gfx   92.570   92.631   0.15%    3/3
[  1]    image                         gvim    7.421    7.438   0.19%    3/3
[  1]       gl                         gvim   91.088   91.207   0.38%    3/3
[  1]     xlib                         gvim   49.632   49.638   0.29%    3/3
[  2]    image         firefox-planet-gnome   37.715   37.952   0.53%    3/3
[  2]       gl         firefox-planet-gnome   91.796   92.135   0.29%    3/3
[  2]     xlib         firefox-planet-gnome   48.483   48.596   0.19%    3/3
[  3]    image                    evolution    6.148    6.156   0.28%    3/3
[  3]       gl                    evolution   66.187   66.418   1.43%    3/3
[  3]     xlib                    evolution   41.207   41.226   0.98%    3/3
[  4]    image                      poppler    5.968    5.978   1.09%    3/3
[  4]       gl                      poppler   16.815   16.843   3.98%    3/3
[  4]     xlib                      poppler   35.851   35.888   0.16%    3/3
[  5]    image            firefox-talos-svg   74.505   76.889   1.48%    3/3
[  5]       gl            firefox-talos-svg  111.540  111.883   1.00%    3/3
[  5]     xlib            firefox-talos-svg   96.115   96.513   0.24%    3/3
[  6]    image         gnome-system-monitor    8.001    8.057   0.35%    3/3
[  6]       gl         gnome-system-monitor    7.865    7.891   0.55%    3/3
[  6]     xlib         gnome-system-monitor    9.322    9.547   2.79%    3/3
[  7]    image           gnome-terminal-vim    8.504    8.520   0.20%    3/3
[  7]       gl           gnome-terminal-vim   14.916   14.956   1.03%    3/3
[  7]     xlib           gnome-terminal-vim   44.785   44.864   0.95%    3/3
[  8]    image           swfdec-giant-steps    3.039    3.047   0.21%    3/3
[  8]       gl           swfdec-giant-steps   10.318   10.391   0.34%    3/3
[  8]     xlib           swfdec-giant-steps    6.883    6.929   0.57%    3/3
[  9]    image               swfdec-youtube    7.953    8.015   0.42%    3/3
[  9]       gl               swfdec-youtube    9.134    9.215   1.52%    3/3
[  9]     xlib               swfdec-youtube    5.417    5.473   0.52%    3/3


-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20091020/63c5d2af/attachment.pgp 

From spitzak at gmail.com  Tue Oct 20 16:17:28 2009
From: spitzak at gmail.com (Bill Spitzak)
Date: Tue, 20 Oct 2009 16:17:28 -0700
Subject: [cairo] Self-contained X11 source code to draw with Cairo
In-Reply-To: <4AD3965B.1060600@gmail.com>
References: <A4E2F14C-6B28-4D63-8C5E-202EFD2EE6FF@wanadoo.fr>
	<4AD35F00.3030100@gmail.com> <4AD3965B.1060600@gmail.com>
Message-ID: <4ADE4508.8060304@gmail.com>

This is a cleaned up version of my code to use Cairo without using gtk 
or another toolkit.

In this version the code you may actually want to alter to change what 
the program does has been extracted into functions at the bottom, making 
it a lot easier to adapt. This has also been tested and works with pango 
drawing (requires pkg-config to compile, however).

Hope some Cairo users enjoy this. Please send any feedback!

Bill Spitzak

-------------- next part --------------
A non-text attachment was scrubbed...
Name: x11cairo.c
Type: text/x-csrc
Size: 14203 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091020/4eb243d0/attachment-0001.c 

From robert at ocallahan.org  Tue Oct 20 16:29:42 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 21 Oct 2009 12:29:42 +1300
Subject: [cairo] update on cairo-gl performance
In-Reply-To: <1256079394.4771.21.camel@gaiman.anholt.net>
References: <1256079394.4771.21.camel@gaiman.anholt.net>
Message-ID: <11e306600910201629u71fe261dpd77f1fa4df85b45a@mail.gmail.com>

This sounds good!

One other issue that's not being measured in your traces, which I mentioned
on IRC but I should note for the record, is GTK theme drawing. The GTK theme
API requires you to pass in an X drawable, so currently Gecko detects when
the cairo context is a wrapper around an X drawable and the graphics state
is "simple enough" (CTM is a pixel-aligned translation, operator is OVER,
etc) and if so unwraps the X drawable and passes it directly to GTK.

Ideally, the GTK theme API would change so we can tell a theme to draw
directly into a cairo_t (since most themes are using cairo to draw already!)
Until then, though, getting theme drawing to work performantly with cairo-gl
would probably require GLX_EXT_texture_from_pixmap, and of course there
would still be performance impact.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091021/1c73f491/attachment.htm 

From tiagofalcao at gmail.com  Tue Oct 20 21:23:51 2009
From: tiagofalcao at gmail.com (Tiago Rezende Campos Falcao)
Date: Wed, 21 Oct 2009 02:23:51 -0200
Subject: [cairo] Color Filter for ColorBlind
In-Reply-To: <59c687850910202119o715ec601u621bc6fef3cec715@mail.gmail.com>
References: <59c687850910202119o715ec601u621bc6fef3cec715@mail.gmail.com>
Message-ID: <59c687850910202123g42a4ee0dn369102ac1ae5519b@mail.gmail.com>

Hi,
First, I would like to introduce myself.  I am a student at a Brazilian
University (Unicamp), attending a graduation course entitled "Communitary
Informatics".  Me and other 2 fellows are interested in contributing with
GCompris, but we can apply the fix filter in lower layer like Cairo to give
this option to all cairo based programs.

We would like to know from you if we can try do this and if it is
interesting for Cairo Community.

Thanks

-- 
Tiago Rezende Campos Falc?o
http://www.tiagofalcao.com
--
ProFUSION | embedded systems
Computer Systems Laboratory - IC - Unicamp
Grupo Pr? Software Livre - Unicamp
Laboratory of Information Systems - IC - Unicamp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091021/30308fa1/attachment.html 

From kalle.vahlman at gmail.com  Tue Oct 20 22:54:07 2009
From: kalle.vahlman at gmail.com (Kalle Vahlman)
Date: Wed, 21 Oct 2009 08:54:07 +0300
Subject: [cairo] update on cairo-gl performance
In-Reply-To: <1256079394.4771.21.camel@gaiman.anholt.net>
References: <1256079394.4771.21.camel@gaiman.anholt.net>
Message-ID: <177e83dd0910202254g74b6ded5h13b3133342eebb5f@mail.gmail.com>

2009/10/21 Eric Anholt <eric at anholt.net>:
> Just thought I'd throw out some new numbers here in case people were
> curious.

Nice to see the fabeled OpenGL backend cairo finally materialize ;)

That said, I'm wondering about the requirements (or rather the target
OpenGL environment) of the backend. There is no mention of it in the
README[1] and the configure.ac check just looks for gl.pc.

I'm not too familiar with all the OpenGL flavours and drivers, but
mainly I'm wondering if

 * it's strictly directed at "desktop" OpenGL (and which version?)
 * the (to my understanding rather varying) feature/extension support
in the driver landscape is taken into account
 * and does the design allow for OpenGL ES support (though maybe that
already calls for a dedicated surface)?

Oh, and finally, if there is any demo programs using it available?
While running the test and perf suites confirm it's working at least
in some level, I'd like to see something more visual to be able to go
"look, cairo-gl!" ;)

Cheers,
  Kalle

[1] In fact,  not many of the current experimental backends are
mentioned there. Probably something that would be nice to require when
committing a new backend in the future?


-- 
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
See also http://syslog.movial.fi

From sandmann at daimi.au.dk  Wed Oct 21 09:22:16 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 21 Oct 2009 18:22:16 +0200
Subject: [cairo] [PATCH] [API] Support component-alpha.
In-Reply-To: <1256054177-sup-4781@broadwater.alporthouse.com>
References: <1255564029-17826-1-git-send-email-chris@chris-wilson.co.uk>
	<ye8ljj6npo4.fsf@camel26.daimi.au.dk>
	<1256047492-sup-5288@broadwater.alporthouse.com>
	<ye8hbtunkxq.fsf@camel26.daimi.au.dk>
	<1256054177-sup-4781@broadwater.alporthouse.com>
Message-ID: <ye8my3k1zuv.fsf@camel18.daimi.au.dk>

Chris Wilson <chris at chris-wilson.co.uk> writes:

> Excerpts from Soeren Sandmann's message of Tue Oct 20 16:29:05 +0100 2009:
> > Well, there are two subtly different concepts in play here:
> > 
> > 1. The concept of a 'three times horizontally supersampled image'
> > 
> > 2. The concept of 'values to be presented to an output device'
> > 
> > It seems to me that (1) is the only thing a user can really be
> > expected to provide, because while (2) can be computed from (1), to do
> > a good job of it, you have to know about device characteristics and
> > human vision, then apply appropriate filtering and correction. You
> > also need to control which color space compositing takes place in.
> > 
> > If the component_alpha pattern property uses interpretation (2), then
> > we are effectively asking users to use their understanding of cairo
> > internals to compute something quite non-trivial.
> 
> Hmm, I was approaching this from the "how can I generate sub-pixel
> geometry masks to perform CAIRO_ANTIALIAS_SUBPIXEL with Render". Which
> as you point out requires the knowledge (as provided by Render) of the
> sub-pixel layout. That knowledge can only be sanely handled internally,
> as it is meaningless for the rest of cairo and indeed is out of scope.
> 
> Ok, I'm convinced that the antialias property that we currently expose
> on the context (hence target surface) is the way to go here and that
> exposing per-component alpha is insane.

If some day cairo starts making more use of subpixels, it might make
sense to allow the user to provide oversampled images in the sense of
(1) above. That is, images with three times the normal horizontal
resolution. Internally, cairo could then use this extra resolution to
generate subpixels with the appropriate filtering etc.


Soren

From freddie at witherden.org  Wed Oct 21 09:56:27 2009
From: freddie at witherden.org (Freddie Witherden)
Date: Wed, 21 Oct 2009 17:56:27 +0100
Subject: [cairo] update on cairo-gl performance
In-Reply-To: <bf233a9150b7889c25f4fcdc821851af@mail.witherden.org>
References: <1256079394.4771.21.camel@gaiman.anholt.net>
	<bf233a9150b7889c25f4fcdc821851af@mail.witherden.org>
Message-ID: <C1E43652-44B6-43F0-922C-C78CABC96146@witherden.org>

[Posting explicitly to list; Mail for some reason replies directly  
rather than to the list by default, apologies.]

On Tue, 20 Oct 2009 15:56:34 -0700, Eric Anholt <eric at anholt.net> wrote:
> I've done most of my profiling on firefox-talos-gfx, and through fixes
> mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
> on this hardware to 56 seconds.  At this point, the test consumes  
> around
> 90% of the CPU still, while around 10% of the time it's idle blocked  
> on
> the hardware due to the useless clears of temporary buffers.

Have you tried the benchmark on nVidia or ATI hardware with the binary- 
blob
drivers? In my experience from the Warzone 2100 project these have
significantly better support for OpenGL and should be a much more  
realistic
benchmark. (As they are much less prone to falling back to software.)

This should give a better idea of how much work is being offloaded by  
the
backend.

Regards, Freddie.


From ben at happyspork.com  Wed Oct 21 10:46:44 2009
From: ben at happyspork.com (Ben Anderman)
Date: Wed, 21 Oct 2009 13:46:44 -0400
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
	<E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>
Message-ID: <AC61CD6B-024B-48BD-BB3B-C40A9B4541E3@happyspork.com>

I think the style is good; it's great to keep things self-contained. I  
just to finish though, and got errors on the first file in the make  
step of Cairo. Here's the output:
make  all-recursive
Making all in src
make  all-am
../doltcompile gcc -DHAVE_CONFIG_H -I. -I..  -I. -I/Users/ben/ 
Documents/programming_stuff/BuildCairo/include/pixman-1      -I/Users/ 
ben/Documents/programming_stuff/BuildCairo/include/libpng12       - 
Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration - 
Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing- 
prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch- 
enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self - 
Wunsafe-loop-optimizations -Wdeclaration-after-statement -Wold-style- 
definition -Wno-missing-field-initializers -Wno-unused-parameter -Wno- 
attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common - 
Wp,-D_FORTIFY_SOURCE=2          -I/sw/include  -Os -arch ppc -arch  
i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c -o cairo-analysis- 
surface.lo cairo-analysis-surface.c
In file included from cairoint.h:60,
                  from cairo-analysis-surface.c:37:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:  
stdarg.h: No such file or directory
In file included from cairoint.h:60,
                  from cairo-analysis-surface.c:37:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:  
stdarg.h: No such file or directory
lipo: can't figure out the architecture type of: /var/folders/mf/ 
mf3Jw2Pc2RWV-k+1YxDPA++++TI/-Tmp-//ccf5YsnW.out
make[3]: *** [cairo-analysis-surface.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Seems like Cairo uses something that's not available in 10.4?

Ben
(Mac packager for Wesnoth / crimson_penguin on IRC)

On Oct 20, 2009, at 1:20 AM, Travis Griggs wrote:

>
> On Oct 19, 2009, at 8:35 PM, Ben Anderman wrote:
>
>> I haven't finished yet, but I'm going to bed now. Here's a couple
>> problems:
>> mkdir ${BuildDir) has a closing bracket instead of brace.
>> Typo in tar -xzf pkconfig.tgz (missing the g in pkg).
>> The mv lines (like "mv pkg* pkgconfig") won't work properly because
>> the .tgz files are still there, and are matched by the glob.
>>
>> I also think it'd be good to make it clear that these are dylibs,
>> not frameworks, and that they're made to be packaged inside a .app.
>> It doesn't specifically claim that they are frameworks, but it makes
>> it sound like they are (in my opinion).
>>
>> Other than that it looks pretty good, and it's definitely a nice
>> thing to have!
>
> Suppose I should actually test my own page, huh? :)
>
> I've done so now, making sure one can simply copy-paste between
> browser and command line.
>
> Thanks for the feedback.
>
> I'm assuming that the actual "style" is OK with people then? Getting a
> lot of good technical feedback, the actual layout doesn't seem to be
> raising too many concerns. I'll write up the Windows one along the
> same lines tomorrow.
>
> --
> Travis Griggs
> Objologist
> "The project was so plagued by politics and ego that when the
> engineers requested technical oversight, our manager hired a
> psychologist instead." -- Ron Avitzur
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From ben at happyspork.com  Wed Oct 21 11:22:15 2009
From: ben at happyspork.com (Ben Anderman)
Date: Wed, 21 Oct 2009 14:22:15 -0400
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <AC61CD6B-024B-48BD-BB3B-C40A9B4541E3@happyspork.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
	<E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>
	<AC61CD6B-024B-48BD-BB3B-C40A9B4541E3@happyspork.com>
Message-ID: <78DC0942-37C8-49F3-802B-6B35CF94A66F@happyspork.com>

Figured out the problem: I'm using 10.6, which uses gcc 4.2 by  
default, but when compiling with the 10.4 SDK, you have to use gcc  
4.0. The solution: set the CC environment variable to "gcc-4.0".

After I did that, everything worked. :)

Ben

On Oct 21, 2009, at 1:46 PM, Ben Anderman wrote:

> I think the style is good; it's great to keep things self-contained. I
> just to finish though, and got errors on the first file in the make
> step of Cairo. Here's the output:
> make  all-recursive
> Making all in src
> make  all-am
> ../doltcompile gcc -DHAVE_CONFIG_H -I. -I..  -I. -I/Users/ben/
> Documents/programming_stuff/BuildCairo/include/pixman-1      -I/Users/
> ben/Documents/programming_stuff/BuildCairo/include/libpng12       -
> Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration -
> Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-
> prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-
> enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self -
> Wunsafe-loop-optimizations -Wdeclaration-after-statement -Wold-style-
> definition -Wno-missing-field-initializers -Wno-unused-parameter -Wno-
> attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -
> Wp,-D_FORTIFY_SOURCE=2          -I/sw/include  -Os -arch ppc -arch
> i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c -o cairo-analysis-
> surface.lo cairo-analysis-surface.c
> In file included from cairoint.h:60,
>                  from cairo-analysis-surface.c:37:
> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
> stdarg.h: No such file or directory
> In file included from cairoint.h:60,
>                  from cairo-analysis-surface.c:37:
> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
> stdarg.h: No such file or directory
> lipo: can't figure out the architecture type of: /var/folders/mf/
> mf3Jw2Pc2RWV-k+1YxDPA++++TI/-Tmp-//ccf5YsnW.out
> make[3]: *** [cairo-analysis-surface.lo] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> Seems like Cairo uses something that's not available in 10.4?
>
> Ben
> (Mac packager for Wesnoth / crimson_penguin on IRC)
>
> On Oct 20, 2009, at 1:20 AM, Travis Griggs wrote:
>
>>
>> On Oct 19, 2009, at 8:35 PM, Ben Anderman wrote:
>>
>>> I haven't finished yet, but I'm going to bed now. Here's a couple
>>> problems:
>>> mkdir ${BuildDir) has a closing bracket instead of brace.
>>> Typo in tar -xzf pkconfig.tgz (missing the g in pkg).
>>> The mv lines (like "mv pkg* pkgconfig") won't work properly because
>>> the .tgz files are still there, and are matched by the glob.
>>>
>>> I also think it'd be good to make it clear that these are dylibs,
>>> not frameworks, and that they're made to be packaged inside a .app.
>>> It doesn't specifically claim that they are frameworks, but it makes
>>> it sound like they are (in my opinion).
>>>
>>> Other than that it looks pretty good, and it's definitely a nice
>>> thing to have!
>>
>> Suppose I should actually test my own page, huh? :)
>>
>> I've done so now, making sure one can simply copy-paste between
>> browser and command line.
>>
>> Thanks for the feedback.
>>
>> I'm assuming that the actual "style" is OK with people then?  
>> Getting a
>> lot of good technical feedback, the actual layout doesn't seem to be
>> raising too many concerns. I'll write up the Windows one along the
>> same lines tomorrow.
>>
>> --
>> Travis Griggs
>> Objologist
>> "The project was so plagued by politics and ego that when the
>> engineers requested technical oversight, our manager hired a
>> psychologist instead." -- Ron Avitzur
>>
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From domlachowicz at gmail.com  Wed Oct 21 11:32:37 2009
From: domlachowicz at gmail.com (Dominic Lachowicz)
Date: Wed, 21 Oct 2009 14:32:37 -0400
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <78DC0942-37C8-49F3-802B-6B35CF94A66F@happyspork.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
	<E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>
	<AC61CD6B-024B-48BD-BB3B-C40A9B4541E3@happyspork.com>
	<78DC0942-37C8-49F3-802B-6B35CF94A66F@happyspork.com>
Message-ID: <2672cf4d0910211132k3ce94633wf7f4d53c985e4364@mail.gmail.com>

That's odd. Isn't stdarg.h part of the C89 standard, and thus included
by every C compiler shipped in the last 2 decades?

On Wed, Oct 21, 2009 at 2:22 PM, Ben Anderman <ben at happyspork.com> wrote:
> Figured out the problem: I'm using 10.6, which uses gcc 4.2 by
> default, but when compiling with the 10.4 SDK, you have to use gcc
> 4.0. The solution: set the CC environment variable to "gcc-4.0".
>
> After I did that, everything worked. :)
>
> Ben
>
> On Oct 21, 2009, at 1:46 PM, Ben Anderman wrote:
>
>> I think the style is good; it's great to keep things self-contained. I
>> just to finish though, and got errors on the first file in the make
>> step of Cairo. Here's the output:
>> make ?all-recursive
>> Making all in src
>> make ?all-am
>> ../doltcompile gcc -DHAVE_CONFIG_H -I. -I.. ?-I. -I/Users/ben/
>> Documents/programming_stuff/BuildCairo/include/pixman-1 ? ? ?-I/Users/
>> ben/Documents/programming_stuff/BuildCairo/include/libpng12 ? ? ? -
>> Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration -
>> Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-
>> prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-
>> enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self -
>> Wunsafe-loop-optimizations -Wdeclaration-after-statement -Wold-style-
>> definition -Wno-missing-field-initializers -Wno-unused-parameter -Wno-
>> attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -
>> Wp,-D_FORTIFY_SOURCE=2 ? ? ? ? ?-I/sw/include ?-Os -arch ppc -arch
>> i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c -o cairo-analysis-
>> surface.lo cairo-analysis-surface.c
>> In file included from cairoint.h:60,
>> ? ? ? ? ? ? ? ? ?from cairo-analysis-surface.c:37:
>> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
>> stdarg.h: No such file or directory
>> In file included from cairoint.h:60,
>> ? ? ? ? ? ? ? ? ?from cairo-analysis-surface.c:37:
>> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
>> stdarg.h: No such file or directory
>> lipo: can't figure out the architecture type of: /var/folders/mf/
>> mf3Jw2Pc2RWV-k+1YxDPA++++TI/-Tmp-//ccf5YsnW.out
>> make[3]: *** [cairo-analysis-surface.lo] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> Seems like Cairo uses something that's not available in 10.4?
>>
>> Ben
>> (Mac packager for Wesnoth / crimson_penguin on IRC)
>>
>> On Oct 20, 2009, at 1:20 AM, Travis Griggs wrote:
>>
>>>
>>> On Oct 19, 2009, at 8:35 PM, Ben Anderman wrote:
>>>
>>>> I haven't finished yet, but I'm going to bed now. Here's a couple
>>>> problems:
>>>> mkdir ${BuildDir) has a closing bracket instead of brace.
>>>> Typo in tar -xzf pkconfig.tgz (missing the g in pkg).
>>>> The mv lines (like "mv pkg* pkgconfig") won't work properly because
>>>> the .tgz files are still there, and are matched by the glob.
>>>>
>>>> I also think it'd be good to make it clear that these are dylibs,
>>>> not frameworks, and that they're made to be packaged inside a .app.
>>>> It doesn't specifically claim that they are frameworks, but it makes
>>>> it sound like they are (in my opinion).
>>>>
>>>> Other than that it looks pretty good, and it's definitely a nice
>>>> thing to have!
>>>
>>> Suppose I should actually test my own page, huh? :)
>>>
>>> I've done so now, making sure one can simply copy-paste between
>>> browser and command line.
>>>
>>> Thanks for the feedback.
>>>
>>> I'm assuming that the actual "style" is OK with people then?
>>> Getting a
>>> lot of good technical feedback, the actual layout doesn't seem to be
>>> raising too many concerns. I'll write up the Windows one along the
>>> same lines tomorrow.
>>>
>>> --
>>> Travis Griggs
>>> Objologist
>>> "The project was so plagued by politics and ego that when the
>>> engineers requested technical oversight, our manager hired a
>>> psychologist instead." -- Ron Avitzur
>>>
>>> _______________________________________________
>>> cairo mailing list
>>> cairo at cairographics.org
>>> http://lists.cairographics.org/mailman/listinfo/cairo
>>
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>



-- 
"I like to pay taxes. With them, I buy civilization." --  Oliver Wendell Holmes

From ben at happyspork.com  Wed Oct 21 11:38:54 2009
From: ben at happyspork.com (Ben Anderman)
Date: Wed, 21 Oct 2009 14:38:54 -0400
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <2672cf4d0910211132k3ce94633wf7f4d53c985e4364@mail.gmail.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
	<E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>
	<AC61CD6B-024B-48BD-BB3B-C40A9B4541E3@happyspork.com>
	<78DC0942-37C8-49F3-802B-6B35CF94A66F@happyspork.com>
	<2672cf4d0910211132k3ce94633wf7f4d53c985e4364@mail.gmail.com>
Message-ID: <B4FEA38F-D4A5-4971-972E-1641AF829666@happyspork.com>

Well, it IS there, if you look closely, it's stdarg.h that's trying to  
include itself. I don't quite understand why it doesn't work to be  
honest, but I asked around, that was the answer I got, and it worked.

Ben

On Oct 21, 2009, at 2:32 PM, Dominic Lachowicz wrote:

> That's odd. Isn't stdarg.h part of the C89 standard, and thus included
> by every C compiler shipped in the last 2 decades?
>
> On Wed, Oct 21, 2009 at 2:22 PM, Ben Anderman <ben at happyspork.com>  
> wrote:
>> Figured out the problem: I'm using 10.6, which uses gcc 4.2 by
>> default, but when compiling with the 10.4 SDK, you have to use gcc
>> 4.0. The solution: set the CC environment variable to "gcc-4.0".
>>
>> After I did that, everything worked. :)
>>
>> Ben
>>
>> On Oct 21, 2009, at 1:46 PM, Ben Anderman wrote:
>>
>>> I think the style is good; it's great to keep things self- 
>>> contained. I
>>> just to finish though, and got errors on the first file in the make
>>> step of Cairo. Here's the output:
>>> make  all-recursive
>>> Making all in src
>>> make  all-am
>>> ../doltcompile gcc -DHAVE_CONFIG_H -I. -I..  -I. -I/Users/ben/
>>> Documents/programming_stuff/BuildCairo/include/pixman-1      -I/ 
>>> Users/
>>> ben/Documents/programming_stuff/BuildCairo/include/libpng12       -
>>> Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration -
>>> Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-
>>> prototypes -Wmissing-declarations -Wnested-externs -Wpacked - 
>>> Wswitch-
>>> enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self -
>>> Wunsafe-loop-optimizations -Wdeclaration-after-statement -Wold- 
>>> style-
>>> definition -Wno-missing-field-initializers -Wno-unused-parameter - 
>>> Wno-
>>> attributes -Wno-long-long -Winline -fno-strict-aliasing -fno- 
>>> common -
>>> Wp,-D_FORTIFY_SOURCE=2          -I/sw/include  -Os -arch ppc -arch
>>> i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c -o cairo-analysis-
>>> surface.lo cairo-analysis-surface.c
>>> In file included from cairoint.h:60,
>>>                  from cairo-analysis-surface.c:37:
>>> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
>>> stdarg.h: No such file or directory
>>> In file included from cairoint.h:60,
>>>                  from cairo-analysis-surface.c:37:
>>> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
>>> stdarg.h: No such file or directory
>>> lipo: can't figure out the architecture type of: /var/folders/mf/
>>> mf3Jw2Pc2RWV-k+1YxDPA++++TI/-Tmp-//ccf5YsnW.out
>>> make[3]: *** [cairo-analysis-surface.lo] Error 1
>>> make[2]: *** [all] Error 2
>>> make[1]: *** [all-recursive] Error 1
>>> make: *** [all] Error 2
>>>
>>> Seems like Cairo uses something that's not available in 10.4?
>>>
>>> Ben
>>> (Mac packager for Wesnoth / crimson_penguin on IRC)
>>>
>>> On Oct 20, 2009, at 1:20 AM, Travis Griggs wrote:
>>>
>>>>
>>>> On Oct 19, 2009, at 8:35 PM, Ben Anderman wrote:
>>>>
>>>>> I haven't finished yet, but I'm going to bed now. Here's a couple
>>>>> problems:
>>>>> mkdir ${BuildDir) has a closing bracket instead of brace.
>>>>> Typo in tar -xzf pkconfig.tgz (missing the g in pkg).
>>>>> The mv lines (like "mv pkg* pkgconfig") won't work properly  
>>>>> because
>>>>> the .tgz files are still there, and are matched by the glob.
>>>>>
>>>>> I also think it'd be good to make it clear that these are dylibs,
>>>>> not frameworks, and that they're made to be packaged inside  
>>>>> a .app.
>>>>> It doesn't specifically claim that they are frameworks, but it  
>>>>> makes
>>>>> it sound like they are (in my opinion).
>>>>>
>>>>> Other than that it looks pretty good, and it's definitely a nice
>>>>> thing to have!
>>>>
>>>> Suppose I should actually test my own page, huh? :)
>>>>
>>>> I've done so now, making sure one can simply copy-paste between
>>>> browser and command line.
>>>>
>>>> Thanks for the feedback.
>>>>
>>>> I'm assuming that the actual "style" is OK with people then?
>>>> Getting a
>>>> lot of good technical feedback, the actual layout doesn't seem to  
>>>> be
>>>> raising too many concerns. I'll write up the Windows one along the
>>>> same lines tomorrow.
>>>>
>>>> --
>>>> Travis Griggs
>>>> Objologist
>>>> "The project was so plagued by politics and ego that when the
>>>> engineers requested technical oversight, our manager hired a
>>>> psychologist instead." -- Ron Avitzur
>>>>
>>>> _______________________________________________
>>>> cairo mailing list
>>>> cairo at cairographics.org
>>>> http://lists.cairographics.org/mailman/listinfo/cairo
>>>
>>> _______________________________________________
>>> cairo mailing list
>>> cairo at cairographics.org
>>> http://lists.cairographics.org/mailman/listinfo/cairo
>>
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>>
>
>
>
> -- 
> "I like to pay taxes. With them, I buy civilization." --  Oliver  
> Wendell Holmes
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


From tgriggs at cincom.com  Wed Oct 21 13:11:09 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Wed, 21 Oct 2009 13:11:09 -0700
Subject: [cairo] Another set of OSX Build Instructions
In-Reply-To: <78DC0942-37C8-49F3-802B-6B35CF94A66F@happyspork.com>
References: <F14AFA6A-0120-4465-A5F6-20100DB65735@cincom.com>
	<306A6812-0D73-41A6-B11D-D2D123C3ECE1@happyspork.com>
	<E8870613-59D4-4A6F-ACAA-472824A1B507@cincom.com>
	<AC61CD6B-024B-48BD-BB3B-C40A9B4541E3@happyspork.com>
	<78DC0942-37C8-49F3-802B-6B35CF94A66F@happyspork.com>
Message-ID: <AC948C35-C239-4A9E-AF9D-5043F2811015@cincom.com>


On Oct 21, 2009, at 11:22 AM, Ben Anderman wrote:

> Figured out the problem: I'm using 10.6, which uses gcc 4.2 by
> default, but when compiling with the 10.4 SDK, you have to use gcc
> 4.0. The solution: set the CC environment variable to "gcc-4.0".
>
> After I did that, everything worked. :)

Can you tweak the Wiki? Or shall I? I build on 10.5.

--
Travis Griggs
Objologist
Light travels faster than sound. This is why some people appear bright  
until you hear them speak...





From siarhei.siamashka at gmail.com  Wed Oct 21 20:32:19 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Thu, 22 Oct 2009 06:32:19 +0300
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <ye8pr8hheyx.fsf@camel27.daimi.au.dk>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<200910200233.44965.siarhei.siamashka@gmail.com>
	<ye8pr8hheyx.fsf@camel27.daimi.au.dk>
Message-ID: <200910220632.24296.siarhei.siamashka@gmail.com>

On Wednesday 21 October 2009, Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > First introduce something like 'pixman_init' function. Right now CPU type
> > detection is done on the first call to the function. It introduces some
> > minor overhead by having an extra pointer check on each function call.
> > Another problem is that we can't be completely sure that CPU capabilities
> > detection check is always fully reentrant. For example, some platforms
> > may try to set a signal handler and expect to catch SIGILL or something
> > like this.
> >
> > This initialization function would just detect CPU capabilities and set
> > some function pointers. The whole CPU-specific implementation of
> > 'pixman_blt' may be just called via this pointer directly by a client. Or
> > 'pixman_blt' can be just a small thunk which does a call via function
> > pointer, passes exactly the same arguments to it and does nothing more.
> > In this case there will be really no excuse for the compiler for not
> > using tail call, see
> > below.
>
> Adding a pixman_init() that applications would be required to call
> first, would not be a compatible change. If we are designing new API,
> then I really think it should be done in such a way that it can be
> extended to handle the core rendering primitives.

OK, then let's not touch pixman API for now :)

> It does likely make sense to make the pixman_implementation_t type
> public at some point (renamed to pixman_t probably) and then pass it
> directly to the various entry points. This would be necessary if we
> add hardware acceleration to pixman.
>
> > > Also, I really don't see much potential for saving here. For a NEON
> > > implementation of blt, the callchain would be:
> > >
> > >    pixman_blt() ->  _pixman_implementation_blt() -> neon_blt()
> > >
> > > and getting rid of delegates wouldn't really affect that at all. You
> > > could get rid of the _pixman_implementation_blt() call by making it a
> > > macro, but as I mentioned before, gcc turns it into a tail call that
> > > reused the arguments on the stack, so the overhead really is minimal.

Could you have a look and review the patches from the following branch?
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt-v2

It should be more or less final and it adds full support for pixman_blt
source/destination areas overlapping to pixman. Also delegates are removed
for pixman_blt, they really look like an overkill for this simple function.

> > On what kind of platform and with which version of gcc are you getting
> > proper tail call here?
>
> I meant that the
>
>         _pixman_implemenation_blt() -> neon_blt()
>
> would be a tail call. GCC v 4.3.2 on x86-32 produces:
>
>         _pixman_implementation_blt:
>                 pushl   %ebp
>                 movl    %esp, %ebp
>                 movl    8(%ebp), %edx
>                 popl    %ebp
>                 movl    12(%edx), %ecx
>                 jmp     *%ecx
>                 .size   _pixman_implementation_blt,
>                 .-_pixman_implementation_blt
>                 .p2align 4,,15

OK, thanks, I see.

> > I don't see it being used and the overhead is rather hefty, which is
> > also confirmed by benchmarking and profiling.
>
> Well, with a microbenchmark you can make anything stand out.
> Ultimately, this function is called from XCopyArea(), and compared to
> the marshalling of the client call and the long call chain inside the
> X server, these 35 instructions or so, really are not very
> significant.

The code around XCopyArea also needs some cleanups and optimizations.

Application benchmarks show that generally only a fraction of time is spent
in the leaf pixel processing functions. The rest is spread across various
layers. It's quite hard to start optimizing and simplifying all this stuff
(and see the real effect) because lots of small cumulative performance losses
can be found in a lot of places. Not all the images are large enough to ignore
call overhead, there are also small icons, UI elements, fonts...

Long call chains are also bad because processors usually have some limit on
the depth of return address prediction. It's just 8 for ARM Cortex-A8, 12 for
the original AMD Athlon, 24 for AMD Phenom. Intel most likely also has some
limit here, but I did not find it easily. So when going up and down through
some insanely long call chains frequently, a lot of function returns may
suffer from mispredict penalty. And such chains may be very long because
they may be originating from the user application and come through lots of
layers.

Whenever it's easy to remove some of the redundant nested calls, it's better
to do this. Also callgraphs will have less boxes and will become easier to
decipher :)

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cairographics.org/archives/cairo/attachments/20091022/1192a062/attachment.pgp 

From ku.b at gmx.de  Wed Oct 21 22:55:59 2009
From: ku.b at gmx.de (Kai-Uwe Behrmann)
Date: Thu, 22 Oct 2009 07:55:59 +0200 (CEST)
Subject: [cairo] update on cairo-gl performance
In-Reply-To: <1256079394.4771.21.camel@gaiman.anholt.net>
References: <1256079394.4771.21.camel@gaiman.anholt.net>
Message-ID: <alpine.LSU.2.00.0910220753220.4571@sirius.rasena>

Am 20.10.09, 15:56 -0700 schrieb Eric Anholt:
> backend, so I haven't fixed it yet.  Anyone understand that?
>
> I've done most of my profiling on firefox-talos-gfx, and through fixes
> mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
> on this hardware to 56 seconds.  At this point, the test consumes around
> 90% of the CPU still, while around 10% of the time it's idle blocked on
> the hardware due to the useless clears of temporary buffers.

> Finally, the numbers:
>
> [ # ]  backend                         test   min(s) median(s) stddev. count

Does the numbers read like minutes in opposite to frames per second?

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


> [  0]    image            firefox-talos-gfx   44.507   44.591   0.13%    3/3
> [  0]       gl            firefox-talos-gfx   56.005   56.231   0.37%    3/3
> [  0]     xlib            firefox-talos-gfx   92.570   92.631   0.15%    3/3
> [  1]    image                         gvim    7.421    7.438   0.19%    3/3
> [  1]       gl                         gvim   91.088   91.207   0.38%    3/3
> [  1]     xlib                         gvim   49.632   49.638   0.29%    3/3
> [  2]    image         firefox-planet-gnome   37.715   37.952   0.53%    3/3
> [  2]       gl         firefox-planet-gnome   91.796   92.135   0.29%    3/3
> [  2]     xlib         firefox-planet-gnome   48.483   48.596   0.19%    3/3
> [  3]    image                    evolution    6.148    6.156   0.28%    3/3
> [  3]       gl                    evolution   66.187   66.418   1.43%    3/3
> [  3]     xlib                    evolution   41.207   41.226   0.98%    3/3
> [  4]    image                      poppler    5.968    5.978   1.09%    3/3
> [  4]       gl                      poppler   16.815   16.843   3.98%    3/3
> [  4]     xlib                      poppler   35.851   35.888   0.16%    3/3
> [  5]    image            firefox-talos-svg   74.505   76.889   1.48%    3/3
> [  5]       gl            firefox-talos-svg  111.540  111.883   1.00%    3/3
> [  5]     xlib            firefox-talos-svg   96.115   96.513   0.24%    3/3
> [  6]    image         gnome-system-monitor    8.001    8.057   0.35%    3/3
> [  6]       gl         gnome-system-monitor    7.865    7.891   0.55%    3/3
> [  6]     xlib         gnome-system-monitor    9.322    9.547   2.79%    3/3
> [  7]    image           gnome-terminal-vim    8.504    8.520   0.20%    3/3
> [  7]       gl           gnome-terminal-vim   14.916   14.956   1.03%    3/3
> [  7]     xlib           gnome-terminal-vim   44.785   44.864   0.95%    3/3
> [  8]    image           swfdec-giant-steps    3.039    3.047   0.21%    3/3
> [  8]       gl           swfdec-giant-steps   10.318   10.391   0.34%    3/3
> [  8]     xlib           swfdec-giant-steps    6.883    6.929   0.57%    3/3
> [  9]    image               swfdec-youtube    7.953    8.015   0.42%    3/3
> [  9]       gl               swfdec-youtube    9.134    9.215   1.52%    3/3
> [  9]     xlib               swfdec-youtube    5.417    5.473   0.52%    3/3
>
>
> -- 
> Eric Anholt
> eric at anholt.net                         eric.anholt at intel.com
>

From chris at chris-wilson.co.uk  Thu Oct 22 01:37:35 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 22 Oct 2009 09:37:35 +0100
Subject: [cairo] update on cairo-gl performance
In-Reply-To: <alpine.LSU.2.00.0910220753220.4571@sirius.rasena>
References: <1256079394.4771.21.camel@gaiman.anholt.net>
	<alpine.LSU.2.00.0910220753220.4571@sirius.rasena>
Message-ID: <1256199575-sup-7977@broadwater.alporthouse.com>

Excerpts from Kai-Uwe Behrmann's message of Thu Oct 22 06:55:59 +0100 2009:
> Am 20.10.09, 15:56 -0700 schrieb Eric Anholt:
> > Finally, the numbers:
> >
> > [ # ]  backend                         test   min(s) median(s) stddev. count
> 
> Does the numbers read like minutes in opposite to frames per second?

Indeed. The measurement is the duration of the test run. Each test
represents a trace of an application doing a fixed quantity of real
work, which aims to give us a sense of overall system improvement for
each change.

As has been pointed out, they do not represent ideal cases, but
snapshots of real world usage. If an application makes a substantial
improvement to its rendering engine (like poppler has recently done), we
will drop the old trace and replace it, as we do not wish to continue
optimising for obsolete behaviour.

Similarly, it would be useful for application level benchmarks to put
the gfx system in perspective. There are few applications that are
particularly sensitive to gfx throughput (as being measured here) - but
some may be very sensitive to any latency between input and the (initial)
result being visible. And then there are applications where consistent
throughput is paramount, and even tiny stutters are highly visible - cases
where both high throughput and low, consistent, latency is required.

cairo-perf-trace has been a tremendous step forward for us to be able to
make quantifiable changes to the gfx stack. I hope that we will in the
future have similar benchmarks to drive further improvements across the
whole desktop (and shift the focus away from throughput being paramount).
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From islewind at gmail.com  Thu Oct 22 02:59:51 2009
From: islewind at gmail.com (=?ISO-8859-1?B?2Hl2aW5kIEtvbOVz?=)
Date: Thu, 22 Oct 2009 10:59:51 +0100
Subject: [cairo] Color Filter for ColorBlind
In-Reply-To: <59c687850910202123g42a4ee0dn369102ac1ae5519b@mail.gmail.com>
References: <59c687850910202119o715ec601u621bc6fef3cec715@mail.gmail.com>
	<59c687850910202123g42a4ee0dn369102ac1ae5519b@mail.gmail.com>
Message-ID: <7bf6f2dc0910220259h551ded39w9d7df049082af3ad@mail.gmail.com>

On Wed, Oct 21, 2009 at 5:23 AM, Tiago Rezende Campos Falcao
<tiagofalcao at gmail.com> wrote:
> First, I would like to introduce myself. ?I am a student at a?Brazilian
> University (Unicamp), attending a graduation course entitled?"Communitary
> Informatics". ?Me and other 2 fellows are interested in?contributing?with
> GCompris, but we can apply the fix filter in lower layer like Cairo to give
> this option to all cairo based programs.
> We would like to know from you if we can try do this and if it is
> interesting for Cairo Community.

What type of "color filter for color blind" are we talking about here?
One useful for Color Blind people or developers/designers taking such
users into account?

Simulating color deficient vision is simpler than augmenting a color
image with extra contrast helping a color blind person perceive
differences that otherwise would not be perceived.

Simulating color blindness by simply changing individual colors is
useful for designers/developers to understand how different color
deficiencies cause an interface to be perceived and address problems
and can be implemented as a point-filter. I believe a proper filter to
add back the spatial contrast lost by observers with deficient color
vision needs to be a spatial filter (like a blur) on the final UI.

I do believe that both kinds of such filters belong either in the
application(s) themselves or in the window manager/windowing system
along other forms of color profiles.

/?yvind K.
-- 
?The future is already here. It's just not very evenly distributed?
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/

From pcjc2 at cam.ac.uk  Thu Oct 22 05:58:20 2009
From: pcjc2 at cam.ac.uk (Peter Clifton)
Date: Thu, 22 Oct 2009 13:58:20 +0100
Subject: [cairo] Color Filter for ColorBlind
In-Reply-To: <7bf6f2dc0910220259h551ded39w9d7df049082af3ad@mail.gmail.com>
References: <59c687850910202119o715ec601u621bc6fef3cec715@mail.gmail.com>
	<59c687850910202123g42a4ee0dn369102ac1ae5519b@mail.gmail.com>
	<7bf6f2dc0910220259h551ded39w9d7df049082af3ad@mail.gmail.com>
Message-ID: <1256216300.3724.6.camel@pcjc2lap>

On Thu, 2009-10-22 at 10:59 +0100, ?yvind Kol?s wrote:
> On Wed, Oct 21, 2009 at 5:23 AM, Tiago Rezende Campos Falcao
> <tiagofalcao at gmail.com> wrote:
> > First, I would like to introduce myself.  I am a student at a Brazilian
> > University (Unicamp), attending a graduation course entitled "Communitary
> > Informatics".  Me and other 2 fellows are interested in contributing with
> > GCompris, but we can apply the fix filter in lower layer like Cairo to give
> > this option to all cairo based programs.
> > We would like to know from you if we can try do this and if it is
> > interesting for Cairo Community.
> 
> What type of "color filter for color blind" are we talking about here?
> One useful for Color Blind people or developers/designers taking such
> users into account?
> 
> Simulating color deficient vision is simpler than augmenting a color
> image with extra contrast helping a color blind person perceive
> differences that otherwise would not be perceived.
> 
> Simulating color blindness by simply changing individual colors is
> useful for designers/developers to understand how different color
> deficiencies cause an interface to be perceived and address problems
> and can be implemented as a point-filter. I believe a proper filter to
> add back the spatial contrast lost by observers with deficient color
> vision needs to be a spatial filter (like a blur) on the final UI.
> 
> I do believe that both kinds of such filters belong either in the
> application(s) themselves or in the window manager/windowing system
> along other forms of color profiles.

Just a quick note, that if you are using compiz, then you will already
have the feature you need in its accessibility section. I believe it
uses an OpenGL pixel shader (or some other OpenGL-fu) to implement the
filter very efficiently. (I can watch full-screen videos with the filter
enabled with no notable CPU penalty).

Regards,

Peter Clifton


From eric at anholt.net  Thu Oct 22 08:21:19 2009
From: eric at anholt.net (Eric Anholt)
Date: Thu, 22 Oct 2009 08:21:19 -0700
Subject: [cairo] update on cairo-gl performance
In-Reply-To: <alpine.LSU.2.00.0910220753220.4571@sirius.rasena>
References: <1256079394.4771.21.camel@gaiman.anholt.net>
	<alpine.LSU.2.00.0910220753220.4571@sirius.rasena>
Message-ID: <1256224879.32075.3.camel@gaiman.anholt.net>

On Thu, 2009-10-22 at 07:55 +0200, Kai-Uwe Behrmann wrote:
> Am 20.10.09, 15:56 -0700 schrieb Eric Anholt:
> > backend, so I haven't fixed it yet.  Anyone understand that?
> >
> > I've done most of my profiling on firefox-talos-gfx, and through fixes
> > mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
> > on this hardware to 56 seconds.  At this point, the test consumes around
> > 90% of the CPU still, while around 10% of the time it's idle blocked on
> > the hardware due to the useless clears of temporary buffers.
> 
> > Finally, the numbers:
> >
> > [ # ]  backend                         test   min(s) median(s) stddev. count
> 
> Does the numbers read like minutes in opposite to frames per second?

Time in seconds.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20091022/3c42e2bf/attachment.pgp 

From tgriggs at cincom.com  Thu Oct 22 13:36:14 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Thu, 22 Oct 2009 13:36:14 -0700
Subject: [cairo] Test post
Message-ID: <20FC5C41-BB6C-4B21-A97B-79D68B2D7D56@cincom.com>

you can ignore

--
Travis Griggs
Objologist
"Some people are like slinkies, not really good for much, but they can  
bring a smile to your face when you push them down the stairs."


From chris at chris-wilson.co.uk  Thu Oct 22 14:13:40 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 22 Oct 2009 22:13:40 +0100
Subject: [cairo] Pixman glyph performance, and beyond!
Message-ID: <1256244449-sup-6649@broadwater.alporthouse.com>


So I'm reviewing how cairo handles compositing, looking at how we may
drive cairo-gl more efficiently. As part of that process, I've had the
opportunity to remove some overhead from within cairo-image. However,
glyph composition still suffers from substantial overhead since every
glyph is composited separately.

firefox-talos-gfx on a slow Celeron 600MHz:
# Overhead  Symbol
# ........  ......
    23.76%  [.] _pixman_run_fast_path
    23.34%  [.] sse2_composite_add_n_8888_8888_ca
    11.82%  [.] sse2_composite_over_n_8888_8888_ca
     6.31%  [.] pixman_image_composite
     4.69%  [.] walk_region_internal
     4.44%  [.] pixman_blt_sse2
     3.18%  [.] _pixman_image_validate
     2.30%  [.] sse2_composite_over_n_8_8888
     2.23%  [.] pixman_compute_composite_region32
     2.19%  [.] pixman_fill_sse2
     1.91%  [.] sse2_composite

(And to put it in perspective:
    46.35%  /usr/local/lib/libpixman-1.so.0.17.1                                                  
    28.25%  /home/ickle/src/cairo/src/.libs/libcairo.so.2.10905.0                                 
    14.24%  [kernel])

S?ren has looked at this problem in the past and begun work on
fast-path and faster-fast-path branches, looking to cache prior
fast-path resolutions. These are not yet as effective as one would hope.

How insane would it be to push the get_fast_path() to the user and to be
able to pass in the implementation + composite function instead of
performing the search every time? This would also be useful for spans.
And considering how most cairo operations are first performed to a mask,
cairo could very effectively cache the fast path for its most frequent
operations.

I'm particular interested in suggestions and experiences from the
ARM/NEON guys as they seem to be suffering acutely from similar overheads
in pixman - and so I presume are also looking at this issue.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From tgriggs at cincom.com  Thu Oct 22 14:45:02 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Thu, 22 Oct 2009 14:45:02 -0700
Subject: [cairo] SVG(Inkscape?) Misunderstanding?
Message-ID: <35481FD7-8963-4A0C-98F0-7E8D0AFF9B8D@cincom.com>

I apologize for this being possibly off topic. I'm trying to use Cairo  
to draw an SVG file (the one attached for example). And something's  
not going right. I must be missing something obvious.

When rendered as an icon from Inkscape, I end up with a 16x16 icon,  
with 9 little orange gradient squares. They're nicely pixel aligned to  
keep it crisp. If I understand the SVG correctly, I should be able to  
do the following cairo stuff in pseudo code:

// These values derived from the height/width and the viewBox of the  
root svg node
scale( cr , 16 / 64.424 , 16 / 51.278 );
// apply the transform found at the g4466 node
matrix.xx = 0.6031636;
matrix.yx = 0;
matrix.xy = 0;
matrix.yy = 0.6190702;
matrix.x0 = 7.87836;
matrix.y0 = 5.1860675;
set_matrix( cr , &matrix );
// rect3654
rectangle(cr,
	-5.9716139,
	-15.317435,
	-5.9716139 + 28.360464,
	-15.317435 + 27.631762);
//set a source and fill after this

Unfortunately, this doesn't end up right. If I work the numbers by  
pencil myself, at least for the origin of the rectangle, I get:

(-5.9716139 * 0.6031636 + 7.87836) * (16 / 64.424) --> 1.06209
(-15.317435 * 0.6190702 + 5.1860675) * (16 / 51.278) --> -1.34061

I could almost believe that the 1.06 was just rounding error (rather  
severe actually), but the y value shouldn't be negative at all, and  
it's not at all near integral.

I don't know what I'm doing wrong. I'm wondering at this point, if  
I've mixed something in the application of viewBox.

Any helps or hints would be hugely appreciated.


--
Travis Griggs
Objologist
"Is success the potential of what could be, or the reality of what is?"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Array.svg
Type: image/svg+xml
Size: 12373 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091022/03d8fb69/attachment.svg 
-------------- next part --------------



From cworth at cworth.org  Thu Oct 22 14:59:57 2009
From: cworth at cworth.org (Carl Worth)
Date: Thu, 22 Oct 2009 14:59:57 -0700
Subject: [cairo] SVG(Inkscape?) Misunderstanding?
In-Reply-To: <35481FD7-8963-4A0C-98F0-7E8D0AFF9B8D@cincom.com>
References: <35481FD7-8963-4A0C-98F0-7E8D0AFF9B8D@cincom.com>
Message-ID: <1256248661-sup-9352@yoom.home.cworth.org>

Excerpts from Travis Griggs's message of Thu Oct 22 14:45:02 -0700 2009:
> When rendered as an icon from Inkscape, I end up with a 16x16 icon,  
> with 9 little orange gradient squares. They're nicely pixel aligned to  
> keep it crisp. If I understand the SVG correctly, I should be able to  
> do the following cairo stuff in pseudo code:

I haven't tried to understand your SVG nor your pseudo-code yet, but I
ran our litttle svg2png utility (that uses librsvg) and the result
seems reasonable.

Then I ran:

     cairo-trace svg2png array.svg array.png

and achieved the attached output. Hopefully it will be enlightening.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svg2png.16183.trace
Type: application/octet-stream
Size: 17181 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091022/74934c8a/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091022/74934c8a/attachment-0001.pgp 

From sandmann at daimi.au.dk  Thu Oct 22 18:37:39 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 23 Oct 2009 03:37:39 +0200
Subject: [cairo] Pixman glyph performance, and beyond!
In-Reply-To: <1256244449-sup-6649@broadwater.alporthouse.com>
References: <1256244449-sup-6649@broadwater.alporthouse.com>
Message-ID: <ye8tyxq51r0.fsf@camel16.daimi.au.dk>

Chris Wilson <chris at chris-wilson.co.uk> writes:

> So I'm reviewing how cairo handles compositing, looking at how we may
> drive cairo-gl more efficiently. As part of that process, I've had the
> opportunity to remove some overhead from within cairo-image. However,
> glyph composition still suffers from substantial overhead since every
> glyph is composited separately.

The X server suffers from essentially the same problem, except worse
because each glyph is actually a new pixman_image_t, so there is
horrible overhead from malloc() etc. for each and every glyph.

> firefox-talos-gfx on a slow Celeron 600MHz:
> # Overhead  Symbol
> # ........  ......
>     23.76%  [.] _pixman_run_fast_path
>     23.34%  [.] sse2_composite_add_n_8888_8888_ca
>     11.82%  [.] sse2_composite_over_n_8888_8888_ca
>      6.31%  [.] pixman_image_composite
>      4.69%  [.] walk_region_internal
>      4.44%  [.] pixman_blt_sse2
>      3.18%  [.] _pixman_image_validate
>      2.30%  [.] sse2_composite_over_n_8_8888
>      2.23%  [.] pixman_compute_composite_region32
>      2.19%  [.] pixman_fill_sse2
>      1.91%  [.] sse2_composite

Are these percentages of the 46.35% below, so it is 23.76% of 46.35% =
11.02% for _pixman_run_fast_path?

Either way, it's clearly not good.

> (And to put it in perspective:
>     46.35%  /usr/local/lib/libpixman-1.so.0.17.1                                                  
>     28.25%  /home/ickle/src/cairo/src/.libs/libcairo.so.2.10905.0                                 
>     14.24%  [kernel])
> 
> S?ren has looked at this problem in the past and begun work on
> fast-path and faster-fast-path branches, looking to cache prior
> fast-path resolutions. 

The latest incarnation of that work is the 'flags' branch here:

    http://cgit.freedesktop.org/~sandmann/pixman/log/?h=flags

which contains several optimizations in this area.

Here is a summary of what's in it:

- It moves the computation of the various image properties out of the
  get_fast_path() loop and replaces them bit masks that are much
  faster to check.

- It turns general_composite() and fast_composite_scale_nearest() into
  fast paths, so that all compositing goes through that path.

- It eliminates all the composite methods from pixman_implementation_t

- It adds a fast path cache

- It speeds up the operator 'strength reduction' that Antoine added a
  long time ago, by storing the table more compactly and doing the
  mapping in O(1) time.

I need to clean it up, break it into smaller bits, and send them to
the list for review.

> These are not yet as effective as one would hope.

It might be worthwhile rerunning the benchmark against that branch,
though I suspect there is still some overhead. Almost anything will
show up when the images are as small as glyphs are.
 
> How insane would it be to push the get_fast_path() to the user and to be
> able to pass in the implementation + composite function instead of
> performing the search every time? This would also be useful for spans.
> And considering how most cairo operations are first performed to a mask,
> cairo could very effectively cache the fast path for its most frequent
> operations.

I really think the fast paths need to be kept an implementation
detail, because exposing them would constrain what information about
the images you could rely on to compute the fast path. 

For example, right now pixman does not rely on the alignment of the
image data when it selects the fast path. This means someone could
look up a fast path, then go on to use with several
differently-aligned images, which would mean pixman couldn't later on
add alignment optimizations.

However, I do agree that glyph compositing needs to become much faster
in both X and cairo, but I think that a better way would be to move
the Render glyph management code into pixman and expose a new

        pixman_glyph_set_t

along with something like a pixman_composite_glyphs() similar to how
Render works. This would allow both cairo and X to become
substantially faster, while sharing glyph caching code.

For spans, I still think that a polygon image type in pixman is the
way to go, since again this would benefit both X and cairo. There
could certainly be a call to convert it into spans if that is useful
to other cairo backends, so that we wouldn't need to have two
rasterizers.


Thanks,
Soren

From tgriggs at cincom.com  Thu Oct 22 21:45:58 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Thu, 22 Oct 2009 21:45:58 -0700
Subject: [cairo] SVG viewBox misunderstanding
In-Reply-To: <35481FD7-8963-4A0C-98F0-7E8D0AFF9B8D@cincom.com>
References: <35481FD7-8963-4A0C-98F0-7E8D0AFF9B8D@cincom.com>
Message-ID: <559132BF-40EB-4921-B020-D482D3B476D5@cincom.com>

Carl's response, and some further discussion in irc helped me get to  
the bottom of things, kind of.

Carl's svg2png trace showed that the svg file does represent the icon  
properly, which isn't a surprise (I've attached a lighter/trimmed  
version of it again).

What the trace shows is a singular matrix set:

[0.141041    0                     1.842245
0                 0.144761        3.217366 ]

What I don't get is how it came to that conclusion, *in particular*  
the yy value. The 3 inputs from the svg file are:

viewBox ( 0 0 64.424 51.278 )
width&height 16
additional transform matrix (0.6031636,  0,  0,  0.6190702,  7.87836,   
5.1860675)

If one runs the number for the XX component of the matrix, it should  
be 16 / 64.424 * 0.6031636. Which it is. It's correct. But if one does  
16 / 51.278 * 0.619072, it is NOT 0.144761. What seems to be correct,  
is to ignore the height of the viewBox attribute, and use the width as  
the height instead: 16 / 64.424 * 0.619072.

So what I don't understand, and am begging any SVG gurus to explain,  
is why the 64.424 is used for both width and height. That's obviously  
what I'm supposed to have done here, but I don't get *why*. I looked  
around in librsvg a *little* and didn't see anything obvious right away.

TIA

--
Travis Griggs
Objologist
My Other Machine runs OSX. But then... so does this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Array.svg
Type: image/svg+xml
Size: 5295 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091022/c192ae7a/attachment.svg 
-------------- next part --------------


From chris at chris-wilson.co.uk  Fri Oct 23 01:49:40 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Fri, 23 Oct 2009 09:49:40 +0100
Subject: [cairo] Pixman glyph performance, and beyond!
In-Reply-To: <ye8tyxq51r0.fsf@camel16.daimi.au.dk>
References: <1256244449-sup-6649@broadwater.alporthouse.com>
	<ye8tyxq51r0.fsf@camel16.daimi.au.dk>
Message-ID: <1256284366-sup-8626@broadwater.alporthouse.com>

Excerpts from Soeren Sandmann's message of Fri Oct 23 02:37:39 +0100 2009:
> The latest incarnation of that work is the 'flags' branch here:
> 
>     http://cgit.freedesktop.org/~sandmann/pixman/log/?h=flags
> 
> which contains several optimizations in this area.

[snip]

> It might be worthwhile rerunning the benchmark against that branch,
> though I suspect there is still some overhead. Almost anything will
> show up when the images are as small as glyphs are.

Very effective, S?ren, it eliminated the get_fast_path() overhead entirely:

  32.84%  [.] sse2_composite_add_n_8888_8888_ca
  17.13%  [.] sse2_composite_over_n_8888_8888_ca
  15.98%  [.] pixman_image_composite
   5.78%  [.] pixman_blt_sse2
   5.40%  [.] _pixman_image_validate
   3.98%  [.] pixman_compute_composite_region32
   2.12%  [.] pixman_fill_sse2

It looks like it's been absorbed into pixman_image_composite(), but the
runtime improved by over 10% -- indicative that the lookup overhead was
eliminated. Though there is still around 25% to be recovered.

> I really think the fast paths need to be kept an implementation
> detail, because exposing them would constrain what information about
> the images you could rely on to compute the fast path. 
> 
> For example, right now pixman does not rely on the alignment of the
> image data when it selects the fast path. This means someone could
> look up a fast path, then go on to use with several
> differently-aligned images, which would mean pixman couldn't later on
> add alignment optimizations.

I think you've effectively demonstrated that the overhead from selecting
the fast path should be negligible. So we should move on to the question
of how to push large batches of work to pixman efficiently.

> However, I do agree that glyph compositing needs to become much faster
> in both X and cairo, but I think that a better way would be to move
> the Render glyph management code into pixman and expose a new
> 
>         pixman_glyph_set_t
> 
> along with something like a pixman_composite_glyphs() similar to how
> Render works. This would allow both cairo and X to become
> substantially faster, while sharing glyph caching code.
> 
> For spans, I still think that a polygon image type in pixman is the
> way to go, since again this would benefit both X and cairo. There
> could certainly be a call to convert it into spans if that is useful
> to other cairo backends, so that we wouldn't need to have two
> rasterizers.

I'm actually not so convinced that this the direction that pixman should
be going in. From my perspective cairo requires specific path -> backend
geometry converters, and a polygon rasteriser with a span line interface
has quickly become the default method for pushing masks around. Whereas
traps have been relegated to mostly handling boxes, aside from when the
most efficient wire request we have available is CompositeTraps. (Has
anyone else noticed that the RLE mask for curved geometry is often an
order of magnitude smaller than the equivalent set of trapezoids,
almost as small as the original path?) Similarly, I'd rather not add the
overhead of an independent layer of glyph management. With that bias,
I'd prefer that pixman retained its focus on pixel manipulation routines
and we improve the interfaces for performing large sets of similar
operations.

One issue that we will encounter very soon is the pain caused by forcing
the user to emit cairo_show_glyphs() early for each change in font. This
can be fixed up in the backends that batch requests and use a
consolidated glyph atlas (i.e. there is no level state change and so the
geometry is just accumulated onto the previous operation). [There is
still substantial overhead from cairo doing the analysis on the extra
operations.] Similarly we can move away from an immediate mode, direct
access, pixman - and treat pixman more like a GPU, if it is performant.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From sandmann at daimi.au.dk  Fri Oct 23 05:28:44 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 23 Oct 2009 14:28:44 +0200
Subject: [cairo] Pixman glyph performance, and beyond!
In-Reply-To: <1256284366-sup-8626@broadwater.alporthouse.com>
References: <1256244449-sup-6649@broadwater.alporthouse.com>
	<ye8tyxq51r0.fsf@camel16.daimi.au.dk>
	<1256284366-sup-8626@broadwater.alporthouse.com>
Message-ID: <ye8pr8eqooz.fsf@camel26.daimi.au.dk>

Hi Chris,

> > The latest incarnation of that work is the 'flags' branch here:
> > 
> >     http://cgit.freedesktop.org/~sandmann/pixman/log/?h=flags
> > 
> > which contains several optimizations in this area.
> 
> [snip]
> 
> > It might be worthwhile rerunning the benchmark against that branch,
> > though I suspect there is still some overhead. Almost anything will
> > show up when the images are as small as glyphs are.
> 
> Very effective, S?ren, it eliminated the get_fast_path() overhead entirely:
> 
>   32.84%  [.] sse2_composite_add_n_8888_8888_ca
>   17.13%  [.] sse2_composite_over_n_8888_8888_ca
>   15.98%  [.] pixman_image_composite
>    5.78%  [.] pixman_blt_sse2
>    5.40%  [.] _pixman_image_validate
>    3.98%  [.] pixman_compute_composite_region32
>    2.12%  [.] pixman_fill_sse2
> 
> It looks like it's been absorbed into pixman_image_composite(), but the
> runtime improved by over 10% -- indicative that the lookup overhead was
> eliminated. Though there is still around 25% to be recovered.

Some of those 25% might be recovable from the _pixman_image_validate()
by precomputing the flags, but other than that, I don't think there is
all that much more to be gained without a better interface for glyph
rendering.

> > However, I do agree that glyph compositing needs to become much faster
> > in both X and cairo, but I think that a better way would be to move
> > the Render glyph management code into pixman and expose a new
> > 
> >         pixman_glyph_set_t
> > 
> > along with something like a pixman_composite_glyphs() similar to how
> > Render works. This would allow both cairo and X to become
> > substantially faster, while sharing glyph caching code.
> > 
> > For spans, I still think that a polygon image type in pixman is the
> > way to go, since again this would benefit both X and cairo. There
> > could certainly be a call to convert it into spans if that is useful
> > to other cairo backends, so that we wouldn't need to have two
> > rasterizers.
> 
> I'm actually not so convinced that this the direction that pixman should
> be going in. From my perspective cairo requires specific path -> backend
> geometry converters, and a polygon rasteriser with a span line interface
> has quickly become the default method for pushing masks around. Whereas
> traps have been relegated to mostly handling boxes, aside from when the
> most efficient wire request we have available is CompositeTraps. (Has
> anyone else noticed that the RLE mask for curved geometry is often an
> order of magnitude smaller than the equivalent set of trapezoids,
> almost as small as the original path?) 

One of the major reasons for adding a polygon image to pixman is that
it would make a PictPolygon render picture possible, thereby finally
eliminating the use of trapezoids, while allowing the X server to do
one-pass compositing of geometry, at least in software.

I am not proposing to tesselate the polygons in pixman, but to
composite them directly scanline by scanline. Using Tor's clever trick
[1] of representing scanlines as accumulation buffers, the operation

        (source IN polygon) OVER dest

can be implemented by

        /* Generate polygon scanline accumulation buffer */
        for reach subpixel scanline
                for each active edge
                        add delta to one pixel in accumulation buffer
                        bresenham step

        uint8_t m = 0
        for each pixel:
                m += polygon[i]
                if (m)
                {
                        s = load_source();
                        d = load_dest()
                
                        d = composite (s, m, d);
                }

which is very SIMD-able and allows us to not allocate and zero-fill a
potentially large temporary mask. I think this would be faster than
the arrays of spans. This would benefit at least the image backend
too, but in any case, there is a clear need to do better than
trapezoids for uploading geometry to X.

It's less convenient for shaders because of the horizontal prefix sum,
which is why there could be a

        pixman_poly_image_make_spans (...)

interface to generate spans for the cairo GPU backends, or a
callback-based one like the one in current cairo. DDX drivers could
use this as well, as could pixman GPU backends.

> Similarly, I'd rather not add the overhead of an independent layer
> of glyph management. 

Simply moving the Render glyph code into pixman would be an immediate
improvement for non-hardware-accelerated X servers since the remaining
overhead in the profile above would essentially disappear.

A little longer term, it would allow storing the glyphs as efficiently
as possible for the CPU in question (since pixman already has details
about the CPU). For example, the SSE2 backend could benefit greatly if
the glyphs were stored in a 16 x n image, possibly sorted by
approximate use frequency. This would improve both cache performance
and allow aligned loads to be used.

I'm not sure I understand what 'overhead of an independent layer of
glyph management' you see for cairo. For at least the image backend, I
don't see anything that a pixman_glyph_set_t could not provide, and it
seems like a win to share this code with the X server. For other
backends, it may not be as useful, but it won't be harmful either.

> With that bias, I'd prefer that pixman retained its focus on pixel
> manipulation routines and we improve the interfaces for performing
> large sets of similar operations.

> One issue that we will encounter very soon is the pain caused by forcing
> the user to emit cairo_show_glyphs() early for each change in font. This
> can be fixed up in the backends that batch requests and use a
> consolidated glyph atlas (i.e. there is no level state change and so the
> geometry is just accumulated onto the previous operation). [There is
> still substantial overhead from cairo doing the analysis on the extra
> operations.] Similarly we can move away from an immediate mode, direct
> access, pixman - and treat pixman more like a GPU, if it is performant.

Even with glyphs and polygons in pixman, I agree that there is
potentially a lot of benefit to be had from submitting more work to
pixman at a time. 

I don't have a clear proposal for what such an interface would look
like, but here are some things that are worth thinking about:

      - How well does the interface help if pixman is multithreaded?

      - How well does it help if pixman gains GPU backends?

      - Can we eliminate temporary images. Ie., if someone does

                cairo_push_group()
                <some simple stuff>
                cairo_pop_to_source()
                cairo_paint()

        can we do the whole operation in one pass without allocating
        a temporary mask? One way to do this would be to add a new 

                pixman_image_composited_t

        image type, that would contain pointers to two other images,
        then composite them on the fly when the toplevel image is
        asked to fetch a scanline. This leads to the idea of an
        'expression tree' of images as the way to submit a lots of
        work.

      - Can it be JIT compiled? There are two quite different
        approaches to JIT compilation:

              - Generate code similar to the current fast paths and
                cache it. This is simpler to get going at first, but
                also fundamentally requires temporary images.

              - Generate one-shot code for a lot of operations at
                once. With the expression tree idea, this might make a
                lot of sense. The compiler could look at the tree and
                generate the code that would produce the least amount
                of memory traffic.

                Shader code could be generated from this as well.

Thanks,
Soren



[1] http://lists.cairographics.org/archives/cairo/2007-August/011136.html

From zlc53 at 163.com  Fri Oct 23 10:15:26 2009
From: zlc53 at 163.com (=?gbk?B?1cXB4bS6?=)
Date: Sat, 24 Oct 2009 01:15:26 +0800 (CST)
Subject: [cairo] cairo surface blit
Message-ID: <3580160.662491256318126406.JavaMail.coremail@app196.163.com>


void PaintDeviceCairo::BlitToMemory(MemoryImage& image, const ClipRect& rect)
{
    int width = cairo_image_surface_get_stride(m_surface);
    char* target = (char*)image.buffer + image.pitch * rect._y + rect._x * sizeof(UINT);
    char* pixels = (char*)cairo_image_surface_get_data(m_surface) + 
        width * rect._y + rect._x * sizeof(UINT);
    
    for(int _y = 0; _y < rect._h; _y ++)
    {
        memcpy(target, pixels, sizeof(UINT) * rect._w);
        pixels += width;
        target += image.pitch;
    }
}

I'd like a cairo surface part of the draw into the memory, but I found that always show all black. Why? 
Note: This memory is D3D SURFACE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091024/94c31b58/attachment.html 

From k.kooi at student.utwente.nl  Fri Oct 23 11:02:24 2009
From: k.kooi at student.utwente.nl (Koen Kooi)
Date: Fri, 23 Oct 2009 20:02:24 +0200
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
 destination pixel data
In-Reply-To: <200910200013.15632.siarhei.siamashka@gmail.com>
References: <200906031242.48765.siarhei.siamashka@gmail.com>	<ye8tz2w4z3k.fsf@camel18.daimi.au.dk>
	<200910200013.15632.siarhei.siamashka@gmail.com>
Message-ID: <hbsr3g$n8g$1@ger.gmane.org>

On 19-10-09 23:13, Siarhei Siamashka wrote:
> On Thursday 04 June 2009, Soeren Sandmann wrote:
>> Siarhei Siamashka<siarhei.siamashka at gmail.com>  writes:
>>> What kind of guarantees (or the lack of) pixman and XRender are supposed
>>> to provide when dealing with overlapping parts of images?
>>
>> (Adding xorg-devel). See this thread:
>>
>>      http://lists.freedesktop.org/archives/xorg/2008-October/039346.html
>>
>> The guarantee that I would suggest for Render and pixman is that if
>> any pixel is both read and written in the same request, then the
>> result of the whole request is undefined, except that it obeys the
>> clipping rules.
>>
>>> The practical use case could be scrolling of data inside of a single big
>>> image. If rendering with overlapped source and destination areas is not
>>> supported, a temporary image has to be created to achieve expected result
>>> and this is an additional performance hit.
>>
>> Yes, scrolling is one thing that the current pixman API doesn't really
>> provide. 'pixman_blt()' only deals with cases where the source and
>> destination don't overlap.
>>
>> I think the best solution is to move all of the X primitives
>> (CopyArea, DrawLine, DrawArc, etc.) into pixman. For CopyArea it would
>> probably look something like this:
>>
>>          void
>>          pixman_copy_area (pixman_image_t *src,
>>                            pixman_image_t *dest,
>>                            pixman_gc_t *gc,
>>                            int src_x,
>>                            int src_y,
>>                            int width,
>>                            int height,
>>                            int dest_x,
>>                            int dest_y);
>>
>> and that would be guaranteed to handle overlapping src and dest. A
>> pixman_gc_t would be a new type of object, corresponding to an X GC.
>>
>> pixman_blt() would then become a deprecated wrapper that would just
>> call pixman_copy_area(). Same for pixman_fill() and a new
>> pixman_fill_rectangles().
>
> I'm not sure about pixman_gc_t since most of the needed operations are just
> simple copies. What about starting with just introducing a variant
> of 'pixman_blt' which is overlapping aware?
>
> I created a work-in-progress branch with 'pixman_blt' function (generic C
> implementation for now) extended to support overlapped source/destination
> case. A simple test program is also included:
> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt

Would using said branch give me 'magically' a performance boost (e.g. 
not make firefox unusably slow as it is now on an 600MHz cortex a8) or 
would I need to patch other libs (e.g. xrender) as well?

regards,

Koen


From chris at chris-wilson.co.uk  Fri Oct 23 14:24:15 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Fri, 23 Oct 2009 22:24:15 +0100
Subject: [cairo] Pixman glyph performance, and beyond!
In-Reply-To: <20091023200506.GA19180@soprano>
References: <1256244449-sup-6649@broadwater.alporthouse.com>
	<ye8tyxq51r0.fsf@camel16.daimi.au.dk>
	<1256284366-sup-8626@broadwater.alporthouse.com>
	<ye8pr8eqooz.fsf@camel26.daimi.au.dk>
	<20091023200506.GA19180@soprano>
Message-ID: <1256330245-sup-9678@broadwater.alporthouse.com>

Excerpts from Aaron Plattner's message of Fri Oct 23 21:05:07 +0100 2009:
> This is maybe only sort of related, but can we push even more of that work
> to the server?  Modern GPUs can evaluate Bezier curves very efficiently,
> and can rasterize them quickly without having to tesselate at all.  An
> approach that stores the control points in video memory and evaluates them
> using something akin to a display list call should be WAY faster than any
> amount of RLE or fancy span encoding or even sending polygons.  The server
> could always decompose it into spans if the implementation can't do the
> paths itself.

Indeed, this is the goal we are working towards. :-)

Pixman is interesting as it is both the lowest common denominator and
reference implementation, and also serves as a vital baseline against
which we can measure driver performance. If we can not render faster than
the CPU, or if we consume more power using the GPU, then our drivers suck.

At the moment, I'm looking at an incremental approach to move
tessellation to the server, and the first steps along that path would be
to use more compact mask representations and extend the current Render
protocol to match current and desired usage.

We're playing with high quality rendering of paths using the GPU via
cairo-gl. Carl has proposed to talk at LCA on this subject, so the goal
is to have something useful in place for him to demonstrate ;-). The
emphasis here, IMO, has to be to maintain cairo's high image quality -
jittered or multisampled stencil based approaches are vastly inferior
(as is the output of some other *slower* 2D libraries, I'm not bitter
;-), though there is a strong push to use those for animations where
the moving image is more forgiving to jaggies and sparkles.

My ulterior motive is then to push cairo into the X server (with cairo
talking over the wire to a cairo extension, which then uses GL or in
some of my wilder plans DRM), so that we can share the tessellation
code between client and server. Or Gallium, or other grand vision du
jour. But first, cairo-gl needs to achieve cairo-drm levels of
performance on the client (as in be faster than the CPU!), before it
becomes an intriguing prospect of pushing to the server. So in the
meantime, I'm trying to work out why the EXA/UXA drivers are so
slow, and see what we can do to improve the current architecture.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From robert at ocallahan.org  Fri Oct 23 14:37:33 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 24 Oct 2009 10:37:33 +1300
Subject: [cairo] Pixman glyph performance, and beyond!
In-Reply-To: <1256330245-sup-9678@broadwater.alporthouse.com>
References: <1256244449-sup-6649@broadwater.alporthouse.com>
	<ye8tyxq51r0.fsf@camel16.daimi.au.dk>
	<1256284366-sup-8626@broadwater.alporthouse.com>
	<ye8pr8eqooz.fsf@camel26.daimi.au.dk> <20091023200506.GA19180@soprano>
	<1256330245-sup-9678@broadwater.alporthouse.com>
Message-ID: <11e306600910231437m7df3dbdck7e79471ec4c4d1b7@mail.gmail.com>

On Sat, Oct 24, 2009 at 10:24 AM, Chris Wilson <chris at chris-wilson.co.uk>wrote:

> The emphasis here, IMO, has to be to maintain cairo's high image quality -
> jittered or multisampled stencil based approaches are vastly inferior
> (as is the output of some other *slower* 2D libraries, I'm not bitter
> ;-), though there is a strong push to use those for animations where
> the moving image is more forgiving to jaggies and sparkles.
>

If there are unavoidable quality/performance tradeoffs, then as a consumer
of cairo (Firefox) I would really like to be able to choose our tradeoff
point, because most of the time for us performance is more important than
quality. Or better said, slow animation or rendering is a much more obvious
quality problem than slightly degraded antialiasing.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091024/71f64768/attachment.htm 

From mike.shaver at gmail.com  Fri Oct 23 14:49:16 2009
From: mike.shaver at gmail.com (Mike Shaver)
Date: Fri, 23 Oct 2009 17:49:16 -0400
Subject: [cairo] Pixman glyph performance, and beyond!
In-Reply-To: <11e306600910231437m7df3dbdck7e79471ec4c4d1b7@mail.gmail.com>
References: <1256244449-sup-6649@broadwater.alporthouse.com>
	<ye8tyxq51r0.fsf@camel16.daimi.au.dk>
	<1256284366-sup-8626@broadwater.alporthouse.com>
	<ye8pr8eqooz.fsf@camel26.daimi.au.dk> <20091023200506.GA19180@soprano>
	<1256330245-sup-9678@broadwater.alporthouse.com>
	<11e306600910231437m7df3dbdck7e79471ec4c4d1b7@mail.gmail.com>
Message-ID: <cc092ba00910231449w3808c44cl278f8717c3f43d12@mail.gmail.com>

On Fri, Oct 23, 2009 at 5:37 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> If there are unavoidable quality/performance tradeoffs, then as a consumer
> of cairo (Firefox) I would really like to be able to choose our tradeoff
> point, because most of the time for us performance is more important than
> quality. Or better said, slow animation or rendering is a much more obvious
> quality problem than slightly degraded antialiasing.

And, indeed, during animations and so forth the quality difference may
not be perceptible, so we might well want to slip into "not quite as
awesome" mode during transitions and animations and scrolling or
whatever, and then do the last frame in "great!" mode.  If we are
doing a bounded animation and can use the GPU, we could even prepare
that visually stunning end frame while the animation was being
processed...

Mike

From marco.maggi-ipsu at poste.it  Sat Oct 24 00:22:58 2009
From: marco.maggi-ipsu at poste.it (Marco Maggi)
Date: Sat, 24 Oct 2009 09:22:58 +0200
Subject: [cairo] cairo documentation and license
Message-ID: <87eiot6yst.fsf@rapitore.luna>

Ciao,

  I am purely  new to Cairo; I am  writing a binding between
Cairo  and a  programming language;  I use  Texinfo  for the
documentation  and I  was thinking  to include  the original
Cairo documentation reformatted in Texinfo.

  Let's  say that  I succeed  in converting  Cairo's  doc to
Texinfo  using docbook2texi  (not  tried yet),  what is  the
doc's  license?   Is it  possible  to  embed  it in  a  Free
Documentation License document or do I have to distribute a
separate document with Cairo's doc only?

TIA
-- 
Marco Maggi

From chris at chris-wilson.co.uk  Sat Oct 24 01:02:48 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Sat, 24 Oct 2009 09:02:48 +0100
Subject: [cairo] High-performance Priority Queue / Heap for glib
In-Reply-To: <1256350604.25954.66.camel@pcjc2lap>
References: <20090303164510.49cf6d7b@rz-nethiwi.rz.uni-karlsruhe.de>
	<49B17F4E.9000802@behdad.org> <20090306221513.7381aaf2@Maik-2130>
	<20090310205305.0c7bdca0@rz-nethiwi.rz.uni-karlsruhe.de>
	<1256350604.25954.66.camel@pcjc2lap>
Message-ID: <1256371032-sup-3635@broadwater.alporthouse.com>

Excerpts from Peter Clifton's message of Sat Oct 24 03:16:44 +0100 2009:
> I'm looking at implementing a computational geometry algorithm (based on
> Bentley-Ottmann) (and I've not got much experience in that field).

Peter, I know you talked about using Cairo in the past and I know you've
also done stencil based tessellation... Can you tell me what your
requirements are and whether Cairo can help? It sounds like you have an
interesting and demanding application, that I would like to use a
performance test case.

Thanks,
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From Flippinho at gmx.de  Sun Oct 25 05:31:08 2009
From: Flippinho at gmx.de (philipp koehler)
Date: Sun, 25 Oct 2009 13:31:08 +0100
Subject: [cairo] cairo + librsvg = svg viewer
Message-ID: <20091025123108.223570@gmx.net>


Hello,

I am trying to do the same thing like you (display svg in Delphi-programs using cairo for rendering and librsvg for svg-parsing)and I have 
exactly the same problem like you.

I was using the h2pas tool from Lazarus 
http://wiki.lazarus.freepascal.org/Creating_bindings_for_C_libraries
to do a header conversion of the librsvg.dll-headers I found on the gnome homepage. Unfortunatly I got stuck because in those header-files there are dependencies which point out of the scope covered by the header-files.
I was suspecting I had the wrong header files because afaik header-files for dynamic libs should not have outside dependencies except for maybe very basic libaries.
May be you have advanced a little bit in the problem of converting the librsvg header-files or have found other solutions to display svg in Delphi.

I would be happy to hear from you,

Greets, Philipp

-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

From cairo-2009d at ryandesign.com  Sun Oct 25 14:03:49 2009
From: cairo-2009d at ryandesign.com (Ryan Schmidt)
Date: Sun, 25 Oct 2009 16:03:49 -0500
Subject: [cairo] No news entry about 1.9.4 on the web site
Message-ID: <686221C2-0A57-44A0-B94F-7D251242749C@ryandesign.com>

The 1.9.4 snapshot isn't mentioned on

http://cairographics.org/news/

or

http://cairographics.org/

These still say 1.9.2 is the latest.




From siarhei.siamashka at gmail.com  Sun Oct 25 17:28:24 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Mon, 26 Oct 2009 02:28:24 +0200
Subject: [cairo] [PATCH] pixman: C fast path for add_1000_1000 and
	over_n_1_8888
Message-ID: <200910260228.24561.siarhei.siamashka@gmail.com>

Hello,

These two fast path functions dealing with 1-bit data are needed
to improve performance of xfce4 terminal. Some other applications
may potentially benefit too.

The patches are also available here:
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=1bit-for-master

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-blitters-test-updated-to-also-randomly-generate-mask.patch
Type: text/x-diff
Size: 1954 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091026/b0faa5ab/attachment.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-C-fast-path-for-add_1000_1000-and-over_n_1_8888.patch
Type: text/x-diff
Size: 6549 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091026/b0faa5ab/attachment-0001.patch 

From siarhei.siamashka at gmail.com  Sun Oct 25 17:57:09 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Mon, 26 Oct 2009 02:57:09 +0200
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <hbsr3g$n8g$1@ger.gmane.org>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<200910200013.15632.siarhei.siamashka@gmail.com>
	<hbsr3g$n8g$1@ger.gmane.org>
Message-ID: <200910260257.09905.siarhei.siamashka@gmail.com>

On Friday 23 October 2009, Koen Kooi wrote:
> > I'm not sure about pixman_gc_t since most of the needed operations are just
> > simple copies. What about starting with just introducing a variant
> > of 'pixman_blt' which is overlapping aware?
> >
> > I created a work-in-progress branch with 'pixman_blt' function (generic C
> > implementation for now) extended to support overlapped source/destination
> > case. A simple test program is also included:
> > http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt
 
First, this branch is outdated. There is a new branch with the final code :)
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt-v2

> Would using said branch give me 'magically' a performance boost (e.g. 
> not make firefox unusably slow as it is now on an 600MHz cortex a8) or 
> would I need to patch other libs (e.g. xrender) as well?

Not really, it's just a small extension of pixman functionality. Currently
the handling of overlapped blt operation (for software rendering) is done
in xorg-server. As it is the responsibility of pixman to provide CPU-specific
SIMD optimizations (NEON for ARM Cortex-A8), it would be quite natural to
move this work to pixman. So the next steps are to add NEON optimizations
to pixman_plt and make sure that xserver takes advantage of these
optimizations for the overlapped blit too.

As for improving scrolling performance (and assuming a standard fbdev driver),
the most important thing is to improve framebuffer memory performance. Right
now framebuffer memory is mapped as noncached writecombine on OMAP3. Enabling
write-through cache for it (with a simple kernel patch) improves scrolling
and moving windows performance by 4x-5x factor (unless shadow framebuffer is
used, which is also not good for performance). This works fine if nothing
but CPU can modify framebuffer memory. But if GPU or DSP can also access
framebuffer memory or compositing manager is used, everything gets more
complicated. Cache invalidate operations will have to be inserted in
appropriate places in order to ensure memory coherency and uniform view
of its content from all the units. If default write-back cache is used
instead of write-through, cache flush operations are needed too.

Unpatched firefox is also quite slow for another reason - it tries to
always work with 32bpp data internally, no matter what color depth is
used for desktop.

-- 
Best regards,
Siarhei Siamashka

From k.kooi at student.utwente.nl  Mon Oct 26 01:11:12 2009
From: k.kooi at student.utwente.nl (Koen Kooi)
Date: Mon, 26 Oct 2009 09:11:12 +0100
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
 destination pixel data
In-Reply-To: <200910260257.09905.siarhei.siamashka@gmail.com>
References: <200906031242.48765.siarhei.siamashka@gmail.com>	<200910200013.15632.siarhei.siamashka@gmail.com>	<hbsr3g$n8g$1@ger.gmane.org>
	<200910260257.09905.siarhei.siamashka@gmail.com>
Message-ID: <hc3lj0$5gv$1@ger.gmane.org>

On 26-10-09 01:57, Siarhei Siamashka wrote:
> On Friday 23 October 2009, Koen Kooi wrote:
>>> I'm not sure about pixman_gc_t since most of the needed operations are just
>>> simple copies. What about starting with just introducing a variant
>>> of 'pixman_blt' which is overlapping aware?
>>>
>>> I created a work-in-progress branch with 'pixman_blt' function (generic C
>>> implementation for now) extended to support overlapped source/destination
>>> case. A simple test program is also included:
>>> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt
>
> First, this branch is outdated. There is a new branch with the final code :)
> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt-v2
>
>> Would using said branch give me 'magically' a performance boost (e.g.
>> not make firefox unusably slow as it is now on an 600MHz cortex a8) or
>> would I need to patch other libs (e.g. xrender) as well?
>
> Not really, it's just a small extension of pixman functionality. Currently
> the handling of overlapped blt operation (for software rendering) is done
> in xorg-server. As it is the responsibility of pixman to provide CPU-specific
> SIMD optimizations (NEON for ARM Cortex-A8), it would be quite natural to
> move this work to pixman. So the next steps are to add NEON optimizations
> to pixman_plt and make sure that xserver takes advantage of these
> optimizations for the overlapped blit too.

So:

1) merge your branch into pixman master
2) move overlapped blit handling from xserver-xorg to pixman
3) add SIMD optimizations to pixman

Would give us better scrolling, right?

> As for improving scrolling performance (and assuming a standard fbdev driver),
> the most important thing is to improve framebuffer memory performance. Right
> now framebuffer memory is mapped as noncached writecombine on OMAP3. Enabling
> write-through cache for it (with a simple kernel patch) improves scrolling
> and moving windows performance by 4x-5x factor (unless shadow framebuffer is
> used, which is also not good for performance). This works fine if nothing
> but CPU can modify framebuffer memory. But if GPU or DSP can also access
> framebuffer memory or compositing manager is used, everything gets more
> complicated. Cache invalidate operations will have to be inserted in
> appropriate places in order to ensure memory coherency and uniform view
> of its content from all the units. If default write-back cache is used
> instead of write-through, cache flush operations are needed too.

I have no idea how the sgx or dsp handle the framebuffer, but I'm using 
both.

> Unpatched firefox is also quite slow for another reason - it tries to
> always work with 32bpp data internally, no matter what color depth is
> used for desktop.

I'm already using your patch for that :)

regards,

Koen


From cworth at cworth.org  Mon Oct 26 05:09:22 2009
From: cworth at cworth.org (Carl Worth)
Date: Mon, 26 Oct 2009 05:09:22 -0700
Subject: [cairo] No news entry about 1.9.4 on the web site
In-Reply-To: <686221C2-0A57-44A0-B94F-7D251242749C@ryandesign.com>
References: <686221C2-0A57-44A0-B94F-7D251242749C@ryandesign.com>
Message-ID: <1256558897-sup-752@yoom.home.cworth.org>

Excerpts from Ryan Schmidt's message of Sun Oct 25 14:03:49 -0700 2009:
> The 1.9.4 snapshot isn't mentioned on
> 
> http://cairographics.org/news/
> 
> or
> 
> http://cairographics.org/
> 
> These still say 1.9.2 is the latest.

Thanks for pointing this out. I had made a git-commit to the wiki when
I did the release, but I had forgotten to push it.

It's there now.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091026/252daa02/attachment.pgp 

From otte at gnome.org  Mon Oct 26 08:00:03 2009
From: otte at gnome.org (Benjamin Otte)
Date: Mon, 26 Oct 2009 16:00:03 +0100
Subject: [cairo] [ANNOUNCE] Video hackfest
Message-ID: <a4ed255b0910260800s747204ay115a491015e0d8ff@mail.gmail.com>

Hi,

I'd like to announce the Video hackfest.[1]  Its goal is to improve
the Linux desktop video experience.  The hackfest will take place in
Collabora's Barcelona offices on the 4 days from Thursday, November
19th to Sunday, November 22nd, 2009. See the wiki for details[1].
A big thanks goes to the X Foundation for funding and Collabora
Multimedia for providing the location.

The idea to this hackfest originated in my idea to bridge X, Cairo and
GStreamer and make them work together better. I prototyped some code
touching every part of the stack, the result of which can be seen on
my blog[2][3]. If you are interested in technical details, I sent them
to the gstreamer and cairo lists before[4][5]. While doing this work
we realized that there is a lack of knowledge about the challenges
that the other projects face. Which is when we decided to do a
hackfest focussing on improving the Linux desktop video experience.

We are currently in the process of collecting topics for the hackfest.
The current list is at [6]. If you think there are issues that should
be discussed and are missing from the list, just add them. You don't
have to be a participant to do that. Just edit the wiki.

Also, if you think this hackfest covers exactly the stuff you are
hacking on and you should participate in the hackfest, it's most
likely a sign you are right and I forgot you. In that case, please
mail me at otte at gnome.org or poke me on IRC (my nick is Company on
freenode) and we'll figure something out. We might even be able to pay
for you, if you are a poor student.

Cheers,
Benjamin


[1]: http://gstreamer.freedesktop.org/wiki/VideoHackfest
[2]: http://blogs.gnome.org/otte/2009/10/05/cairo-is-slow/
[3]: http://blogs.gnome.org/otte/2009/10/14/video-hackfest/
[4]: http://lists.cairographics.org/archives/cairo/2009-September/018121.html
[5]: http://lists.cairographics.org/archives/cairo/2009-September/018221.html
[6]: http://gstreamer.freedesktop.org/wiki/VideoHackfest/Agenda

From cilloni at callegari1930.com  Mon Oct 26 07:57:13 2009
From: cilloni at callegari1930.com (Claudio Cilloni)
Date: Mon, 26 Oct 2009 15:57:13 +0100
Subject: [cairo] wrong kerning while scaling the whole drawing
Message-ID: <200910261557.13681.cilloni@callegari1930.com>

Hi all.

This is my first time signalling a bug. I apologize if I'm doing this in some 
wrong way.

I found an error in the kerning calculations while scaling the whole document.
I made a simple test-case python program:

---------------------------------------------------------------------------------
import pango, cairo, pangocairo

sf = 72 / 25.4

surface = cairo.PDFSurface('/tmp/test.pdf', 210*sf, 297*sf)
ctx = cairo.Context(surface)

ctx.scale(sf, sf)

pctx = pangocairo.CairoContext(ctx)
pctx.new_path()
pctx.move_to(20, 20)

layout = pctx.create_layout()
layout.set_text('Ve Te To')
pctx.show_layout(layout)

surface.finish()
---------------------------------------------------------------------------------

As you can see in the /tmp/test.pdf file, the lowercase letters are too near 
to the preceding uppercase letters. This behaviour can be accentuated 
increasing the value of the sf variable. With sf = 1, the letter kerning 
seems to be ok.

I'm running cairo-1.8.8, pango-1.24.5, python-2.6.2, pycairo-1.8.8.

Thanks for you help!
Ciao.

P.S.: there is a way to disable kerning?


From sandmann at daimi.au.dk  Mon Oct 26 09:14:04 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 26 Oct 2009 17:14:04 +0100
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <200910140113.17147.siarhei.siamashka@gmail.com>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
Message-ID: <ye8fx96w2sz.fsf@camel29.daimi.au.dk>

Hi,

> This branch has new ARM NEON optimizations:
> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=arm-neon-update

In general, I like this a lot, though I have some questions and
comments about it. See below.

> The reasons to use GNU assembler are:

> 1. Full control over registers allocation (there are not too many of
> them, considering that up to 3 images are supported with their
> strides, pointers, prefetch stuff). I encountered problems running
> out of registers with inline assembly and compiling with frame
> pointer.

> 2. This allows the use of more or less advanced macro preprocessor
> and makes everything easier. A bit more flexible option would be to
> use JIT code generation here (this is actually something to consider
> later).

Yes, JIT compiling is very much worth considering, and in fact, your
general framework pretty much *is* a JIT compiler, except that it runs
at compile time and is slightly difficult to read because it is
written in the GNU as meta-language.

> Technically, there should be no problem catching up with SSE2,
> especially if instructions scheduling perfection could be skipped at
> the first stage. Right now only the existing NEON fast path
> functions are reimplemented plus just a few more.

Right, instruction scheduling is the main disadvantage to using the
assembler as opposed to intrinsics. Cortex A9 is out-of-order I
believe, so it will have different scheduling requirements than the
A8, which in turn likely has different scheduling requirements than
earlier in-order CPUs. Though, a reasonable approach might be to
assume that the A9 will not be very sensitive to scheduling at all
(due to it being out-of-order), and then simply optimize for the A8.

> Now the thing to solve is how to handle the systems other than
> linux. There is a potential problem with ABI compatibility - the
> functions must be fully compatible with the calling conventions,
> etc. For now I'm only sure that they are compatible with Linux
> EABI. Most likely the other systems should be fine too, or will be
> fine with a few tweaks.

I think it's perfectly fine even if it is Linux specific at first;
people interested in other operating systems can feel free to send
patches.

Comments on the code:

I have mostly looked at the general framework, and paid less attention
to the various uses of it, except as a reference to understand how the
framework works. And of course, since I'm unfamiliar with both GNU as
and ARM, I may have misread things.

Overall, I like this a lot. As you say, it seems to be general enough
to support pretty much all the pixman operations, as long as there are
no transformations involved or 24 bpp formats (which are always a
pain).

It would be interesting to do something similar for the SSE2 backend.

General

If possible, I think it would be useful to break down the
composite_composite_function macro into smaller bits, that mirror the
structure of the generated code, and then add a comment to the top of
each sub-routine. For example, a sub-macro for the initialization of
the registers plus setup, one for the left unligned part of the
scanline, one for the middle part, one for the right unaligned part,
one for moving to the next line, and one for doing the small rectangle
part. 

I think this would make it easier to grasp what is going on.

Also, in various places, more specific comments would be useful, in
addition to the (generally good) highlevel comments that are already
there.

For example, 

* I don't fully understand what the abits argument to the load/store
  functions is supposed to be doing. Does it have to do with masking
  in 0xff as appropriate? Part of this may be that I don't know what

     [ &mem_operand&, :&abits& ]!

  means

* A comment that .regs_shortage really means that H and W are spilled
  to the stack.

and similar.

Though in general, the code is well commented.

Denterleaving:

What is the benefit of deinterleaving? 

Why is there is no deinterleaving for the inner loop, and only for the
head and tail? Are the callers supposed to do this themselves if they
want it?

Cache preload:

* As far as I can tell, this macro is preloading with PF_X relative to
  PF_SRC, but PF_X is always an offset into a scanline because you
  subtract ORIG_W whenever it exceed, and PF_SRC is set to SRC, but
  never updated anywhere that I can see. So it preloads different
  parts of the first line over and over?

* It seems like you could save a bunch of registers by simply always
  prefetching some fixed number of pixels ahead of where you are going
  to read. Or alternatively, just dump PF_X and keep the number of
  pixels to prefetch ahead in that register. But presumably there is
  some reason not to do this.

* If prefetch_distance is 0, shouldn't this macro not generate
  anything at all?

* I see that you have (H - 1) stored in the upper 28 bits of PF_CTL,
  but are those bits actually being used for anything other than
  preventing the ldrs? Ie., it will still attempt to use the plds
  below the image, right?

If I'm misreading this completely, it would be good to have some more
detailed comments here.

A couple of things that it may or may not be worth thinking about:

* Maybe add support for skipping unnecessary destination reads? Ie.,
  in the case of OVER, there is no reason to read the destination if
  the mask is 0, or if the combined (SRC IN MASK) is 1.

  In my experience, this is a win for many images that
  happen in practice. Consider these common cases:

         - Text: most pixels are either fully opaque or fully
           transparent, and in either case, no destination read is
           necessary.

         - Rounded antialiased rectangle. The corners are transparent
           and the body is opaque or transparent. Essentially none of
           the pixels actually need the destination.

* Does ARM have the equivalent of movnt? It may or may not be
  interesting to use them for the operations that are essentially
  solid fills.

* I don't fully understand why you need the tail/head_tail/head split,
  but if it is to save a branch instruction, maybe you could use the
  standard compiler trick of turning a while loop into this:

           jump test
        body:
           <body>
        test:
           <test code>
           conditional_jump body.


Thanks,
Soren

From sandmann at daimi.au.dk  Mon Oct 26 09:44:51 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 26 Oct 2009 17:44:51 +0100
Subject: [cairo] [PATCH] pixman: C fast path for add_1000_1000 and
	over_n_1_8888
In-Reply-To: <200910260228.24561.siarhei.siamashka@gmail.com>
References: <200910260228.24561.siarhei.siamashka@gmail.com>
Message-ID: <ye8bpjuw1do.fsf@camel29.daimi.au.dk>

Hi,

> These two fast path functions dealing with 1-bit data are needed
> to improve performance of xfce4 terminal. Some other applications
> may potentially benefit too.

A couple of minor comments:

Can we get the two fast paths enabled in two separate commits to
facilitate bisecting?

> +static void
> +fast_composite_over_n_1_8888 (pixman_implementation_t *imp,
> +                              pixman_op_t              op,
> +
> + [...]
> +	    if (bitcache & bitmask)
> +		*dst = over (src, *dst);

It would likely be a big win to check whether the alpha channel of the
source is 0xFF (which is almost always is), then simply writing out
the source if it is. That would completely avoid reading the
destination from memory.

> +    { PIXMAN_OP_OVER, PIXMAN_solid,    PIXMAN_a1,       PIXMAN_a8r8g8b8, fast_composite_over_n_1_8888, 0 },
> +    { PIXMAN_OP_OVER, PIXMAN_solid,    PIXMAN_a1,       PIXMAN_x8r8g8b8, fast_composite_over_n_1_8888, 0 },

I think this one can be enabled for destinations of type x8b8g8r8 and
a8b8g8r8 as well, since pixman_image_get_solid() takes care of the
swapping.

Other than those things, it looks good to me.


Thanks,
Soren

From sandmann at daimi.au.dk  Mon Oct 26 09:52:28 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 26 Oct 2009 17:52:28 +0100
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
	destination pixel data
In-Reply-To: <200910260257.09905.siarhei.siamashka@gmail.com>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<200910200013.15632.siarhei.siamashka@gmail.com>
	<hbsr3g$n8g$1@ger.gmane.org>
	<200910260257.09905.siarhei.siamashka@gmail.com>
Message-ID: <ye87huiw10z.fsf@camel29.daimi.au.dk>

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> write-through cache for it (with a simple kernel patch) improves scrolling
> and moving windows performance by 4x-5x factor (unless shadow framebuffer is
> used, which is also not good for performance). 

What is the issue with the shadow framebuffer? It does add some extra
memory traffic from the final copy, but I would have thought that
everything else becoming much faster, would more than make up for it.


Soren

From sandmann at daimi.au.dk  Mon Oct 26 10:06:34 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 26 Oct 2009 18:06:34 +0100
Subject: [cairo] Faster bilinear scaling
In-Reply-To: <200910140135.30335.siarhei.siamashka@gmail.com>
References: <ye8ljjoz3qt.fsf@camel24.daimi.au.dk>
	<200910140135.30335.siarhei.siamashka@gmail.com>
Message-ID: <ye83a56w0dh.fsf@camel29.daimi.au.dk>

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> More specialized benchmarks would be nice to see too. For example benchmark
> scaling 99x99 to 101x101 and compare it to a simple copy of 100x100 image.
> That would give an estimate about how much this operation is memory throughput
> limited and how much it can be potentially improved.

Indeed, bilinear scaling may be a case where we would not actually be
memory bound, even with an SSE or NEON implementation. 

> > Also, if anyone is interested in adding support for SIMD acceeleration
> > of fetchers, the the bilinear_interpolation() function is begging to
> > be written with SSE2 or NEON.
> 
> This can be tried indeed.

There is a number of cases where support for implementation defined
fetchers would be useful, including gradients and the two SSE2
fetchers in bugzilla that Steve Snyder wrote.

> But as long as the code is well covered by regression tests, having
> more than one implementation should not be a problem.

Well, sometimes regression tests cause people to get sloppy and assume
that their code works just because no tests failed. Generally, I think
careful code review is desirable along with regression tests.

I went ahead and merged the bilinear optimizations.


Soren

From jonathan.morton at movial.com  Mon Oct 26 10:30:52 2009
From: jonathan.morton at movial.com (Jonathan Morton)
Date: Mon, 26 Oct 2009 19:30:52 +0200
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <ye8fx96w2sz.fsf@camel29.daimi.au.dk>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
	<ye8fx96w2sz.fsf@camel29.daimi.au.dk>
Message-ID: <1256578252.18132.87.camel@localhost.localdomain>

On Mon, 2009-10-26 at 17:14 +0100, Soeren Sandmann wrote:
> Right, instruction scheduling is the main disadvantage to using the
> assembler as opposed to intrinsics. Cortex A9 is out-of-order I
> believe, so it will have different scheduling requirements than the
> A8, which in turn likely has different scheduling requirements than
> earlier in-order CPUs.

> Though, a reasonable approach might be to
> assume that the A9 will not be very sensitive to scheduling at all
> (due to it being out-of-order), and then simply optimize for the A8.

Because A9 is OoO, it should be roughly as insensitive to scheduling as
a modern desktop processor is.  That's a huge step forward in the ARM
world, as all previous ARMs (that I know about) have been single- or
dual-issue in-order machines.

For comparison, the Pentium and Pentium-MMX were dual-issue in-order
machines, the 486 having been single-issue but superscalar (able to keep
multiple pipelines in use at once).  The P6 core introduced OoO, along
with everything else.

I can't immediately identify a mainstream PowerPC that *isn't* OoO,
except possibly the head-end core in the Cell.

Instead, the remaining v7-A CPUs without OoO are worth focusing on for
scheduling: the A8, the Snapdragon (which is very broadly similar to the
A8), and the brand-new A5 (which is single-issue).

It's not difficult to write code that works well on both A8 and
Snapdragon.  A good rule of thumb is to issue a "processing" and a
"moving" instruction together, where "moving" could be a load/store, a
register move, a vector permute, a branch or a simple-ALU instruction,
while a "processing" instruction would be any ALU op or any non-permute
vector op.  This is common to many small RISC designs, OoO or not.

The A5 is probably quite scheduling-compatible with code written for A8
or Snapdragon, and will simply run it more slowly because it can never
dual-issue.  It can apparently fold predicted branches, though.  The one
thing I would be careful of is that you can no longer do preloads for
free in the middle of a heavy processing loop - instead you have to find
an unavoidable bubble to fill to avoid slowing down the cached case.

The A9 does seem to have another trick up it's sleeve: an
auto-prefetcher.  If that's anywhere near as good as the one in the
PowerPC 970, that's going to essentially eliminate any need for manual
preloading.

> * I don't fully understand what the abits argument to the load/store
>   functions is supposed to be doing. Does it have to do with masking
>   in 0xff as appropriate? Part of this may be that I don't know what
> 
>      [ &mem_operand&, :&abits& ]!
> 
>   means

This is a hint to the CPU that the address will be aligned to a
guaranteed degree.  This can save a cycle in the LSU on the A8.

> * Does ARM have the equivalent of movnt? It may or may not be
>   interesting to use them for the operations that are essentially
>   solid fills.

Not that I know of.  But if you write to uncached memory, all the v7-A
cores will do write-combining quite well (unlike v6 and earlier).

If you write to cached memory, the cache controller *might* figure out
that you've filled the whole cacheline and avoid the line-fill read, but
that is likely to be more core-specific.  If you make several passes
over the same pixmap, the cached behaviour makes sense to keep rather
than forcing a bypass of it.

The difference between cached and uncached memory is rather important
actually.  You have to bias much harder towards large aligned read
instructions on uncached memory, since each one effectively counts as a
full cache miss.  With cached memory, every cache miss loads the whole
cacheline, making nearby reads available very quickly afterwards.

> * Maybe add support for skipping unnecessary destination reads? Ie.,
>   in the case of OVER, there is no reason to read the destination if
>   the mask is 0, or if the combined (SRC IN MASK) is 1.

That seems to be a valid optimisation for the rounded-rectangle case at
least, probably less so for text.  Text has more edges, so most SIMD
vectors (which are about the width of a typical glyph) would end up with
at least one translucent pixel to deal with.

It is probably possible to preprocess the source and mask vectors to
make a binary go/not decision on a per-vector basis fairly cheaply.  For
situations where memory bandwidth is the constraint, that's a good idea.
It could also allow eliminating the multiplies for that vector.

But it's also worth pointing out that sequential reads are much faster
than scattered reads or read/write/read cycles, and that branches are
themselves potentially expensive - and on Snapdragon, conditional
execution is unpredicted, making it difficult to use efficiently (unlike
conditional branches).

Except for rather large round-rectangle-type cases, a simplified inner
loop and a whole-scanline preload might be a better idea.  Of course,
real benchmarks would be needed to tell the difference reliably.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com



From k.kooi at student.utwente.nl  Mon Oct 26 10:37:20 2009
From: k.kooi at student.utwente.nl (Koen Kooi)
Date: Mon, 26 Oct 2009 18:37:20 +0100
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <ye8fx96w2sz.fsf@camel29.daimi.au.dk>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
	<ye8fx96w2sz.fsf@camel29.daimi.au.dk>
Message-ID: <hc4moh$nhb$1@ger.gmane.org>

On 26-10-09 17:14, Soeren Sandmann wrote:

>> Technically, there should be no problem catching up with SSE2,
>> especially if instructions scheduling perfection could be skipped at
>> the first stage. Right now only the existing NEON fast path
>> functions are reimplemented plus just a few more.
>
> Right, instruction scheduling is the main disadvantage to using the
> assembler as opposed to intrinsics. Cortex A9 is out-of-order I
> believe, so it will have different scheduling requirements than the
> A8, which in turn likely has different scheduling requirements than
> earlier in-order CPUs. Though, a reasonable approach might be to
> assume that the A9 will not be very sensitive to scheduling at all
> (due to it being out-of-order), and then simply optimize for the A8.

A9 has a big downside though: the NEON block was cut-down to make place 
for a full VFP block instead of the VFPlite block in the A8 cores, so 
using NEON will be slower compared to A8. Hopefully the out-of-order 
will make up for it, but pure NEON code will take a hit.

regards,

Koen


From jonathan.morton at movial.com  Mon Oct 26 10:42:29 2009
From: jonathan.morton at movial.com (Jonathan Morton)
Date: Mon, 26 Oct 2009 19:42:29 +0200
Subject: [cairo] [RFC] Pixman & compositing with overlapping source and
 destination pixel data
In-Reply-To: <ye87huiw10z.fsf@camel29.daimi.au.dk>
References: <200906031242.48765.siarhei.siamashka@gmail.com>
	<200910200013.15632.siarhei.siamashka@gmail.com>
	<hbsr3g$n8g$1@ger.gmane.org>
	<200910260257.09905.siarhei.siamashka@gmail.com>
	<ye87huiw10z.fsf@camel29.daimi.au.dk>
Message-ID: <1256578949.18132.98.camel@localhost.localdomain>

On Mon, 2009-10-26 at 17:52 +0100, Soeren Sandmann wrote:

> > write-through cache for it (with a simple kernel patch) improves scrolling
> > and moving windows performance by 4x-5x factor (unless shadow framebuffer is
> > used, which is also not good for performance). 
> 
> What is the issue with the shadow framebuffer? It does add some extra
> memory traffic from the final copy, but I would have thought that
> everything else becoming much faster, would more than make up for it.

The shadow framebuffer has one additional source of overhead: the
damage-region tracking it does to accumulate multiple updates into a
single post-copy.  If you do a lot of small writes to the shadow, the
damage region gets complex and slows everything down.  We have a trivial
pathological reproduction case, involving spraying random small
rectangles all over the screen.

It also seems that enabling shadow also forces on backing stores, which
is another unnecessary memory overhead and probably involves more
copying.

It is of course possible to imagine a "sloppy damage" tracker, to reduce
overhead by limiting damage-region complexity.  ISTR writing one for a
VNC server a long time ago, simply because I didn't want or need precise
region tracking.

If we don't want to deal with uncached framebuffers in Pixman, and
nobody seems entirely comfortable with cached physical framebuffers,
maybe it's worth my digging my old code out and seeing if it can be
adapted.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com



From behdad at behdad.org  Mon Oct 26 12:45:59 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Mon, 26 Oct 2009 15:45:59 -0400
Subject: [cairo] wrong kerning while scaling the whole drawing
In-Reply-To: <200910261557.13681.cilloni@callegari1930.com>
References: <200910261557.13681.cilloni@callegari1930.com>
Message-ID: <4AE5FC77.9000308@behdad.org>

Please see:
https://bugzilla.gnome.org/show_bug.cgi?id=341481

I have a patch for this locally.  Will push it out in a release today.

behdad

On 10/26/2009 10:57 AM, Claudio Cilloni wrote:
> Hi all.
>
> This is my first time signalling a bug. I apologize if I'm doing this in some
> wrong way.
>
> I found an error in the kerning calculations while scaling the whole document.
> I made a simple test-case python program:
>
> ---------------------------------------------------------------------------------
> import pango, cairo, pangocairo
>
> sf = 72 / 25.4
>
> surface = cairo.PDFSurface('/tmp/test.pdf', 210*sf, 297*sf)
> ctx = cairo.Context(surface)
>
> ctx.scale(sf, sf)
>
> pctx = pangocairo.CairoContext(ctx)
> pctx.new_path()
> pctx.move_to(20, 20)
>
> layout = pctx.create_layout()
> layout.set_text('Ve Te To')
> pctx.show_layout(layout)
>
> surface.finish()
> ---------------------------------------------------------------------------------
>
> As you can see in the /tmp/test.pdf file, the lowercase letters are too near
> to the preceding uppercase letters. This behaviour can be accentuated
> increasing the value of the sf variable. With sf = 1, the letter kerning
> seems to be ok.
>
> I'm running cairo-1.8.8, pango-1.24.5, python-2.6.2, pycairo-1.8.8.
>
> Thanks for you help!
> Ciao.
>
> P.S.: there is a way to disable kerning?
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>

From siarhei.siamashka at gmail.com  Mon Oct 26 19:18:25 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 27 Oct 2009 04:18:25 +0200
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <ye8fx96w2sz.fsf@camel29.daimi.au.dk>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
	<ye8fx96w2sz.fsf@camel29.daimi.au.dk>
Message-ID: <200910270418.30150.siarhei.siamashka@gmail.com>

On Monday 26 October 2009, Soeren Sandmann wrote:
> Hi,
>
> > This branch has new ARM NEON optimizations:
> > http://cgit.freedesktop.org/~siamashka/pixman/log/?h=arm-neon-update
>
> In general, I like this a lot, though I have some questions and
> comments about it. See below.
>
> > The reasons to use GNU assembler are:
> >
> > 1. Full control over registers allocation (there are not too many of
> > them, considering that up to 3 images are supported with their
> > strides, pointers, prefetch stuff). I encountered problems running
> > out of registers with inline assembly and compiling with frame
> > pointer.
> >
> > 2. This allows the use of more or less advanced macro preprocessor
> > and makes everything easier. A bit more flexible option would be to
> > use JIT code generation here (this is actually something to consider
> > later).
>
> Yes, JIT compiling is very much worth considering, and in fact, your
> general framework pretty much *is* a JIT compiler, except that it runs
> at compile time and is slightly difficult to read because it is
> written in the GNU as meta-language.
>
> > Technically, there should be no problem catching up with SSE2,
> > especially if instructions scheduling perfection could be skipped at
> > the first stage. Right now only the existing NEON fast path
> > functions are reimplemented plus just a few more.
>
> Right, instruction scheduling is the main disadvantage to using the
> assembler as opposed to intrinsics.

Well, in practice it's the other way around :) Compilers (at least gcc)
usually do a really bad job scheduling instructions, probably they are
spoiled by the dominance of out-of-order processors nowadays. They also
sometimes do a bad job at registers allocation, especially when an algorithm
uses many variables.

> Cortex A9 is out-of-order I believe, so it will have different scheduling
> requirements than the A8, which in turn likely has different scheduling
> requirements than earlier in-order CPUs. Though, a reasonable approach might
> be to assume that the A9 will not be very sensitive to scheduling at all
> (due to it being out-of-order), and then simply optimize for the A8.

More or less all the processors share similar properties. Instructions are
pipelined and have some latency for providing result, dual issue is possible
if they don't depend on each other and CPU has enough execution units
available to run them. Jonathan provided some very detailed explanation.

> > Now the thing to solve is how to handle the systems other than
> > linux. There is a potential problem with ABI compatibility - the
> > functions must be fully compatible with the calling conventions,
> > etc. For now I'm only sure that they are compatible with Linux
> > EABI. Most likely the other systems should be fine too, or will be
> > fine with a few tweaks.
>
> I think it's perfectly fine even if it is Linux specific at first;
> people interested in other operating systems can feel free to send
> patches.

I was more worried about what to do with the old NEON code. How do we even
know whether it is even used (or will be used) by anyone on any non-linux
systems?

I would probably even go as far as removing old NEON optimizations completely.
They are available in 0.16.x versions of pixman and can be taken back into
action if needed. Feedback from the users of Windows Mobile, Symbian and
maybe some other systems running on ARM would be welcome.

> Comments on the code:
>
> I have mostly looked at the general framework, and paid less attention
> to the various uses of it, except as a reference to understand how the
> framework works. And of course, since I'm unfamiliar with both GNU as
> and ARM, I may have misread things.
>
> Overall, I like this a lot. As you say, it seems to be general enough
> to support pretty much all the pixman operations, as long as there are
> no transformations involved or 24 bpp formats (which are always a
> pain).

Yes, and even 24bpp can be supported, though it will add a lot more
of conditionally compiled parts and clutter the code a bit.

24bpp may be quite useful for accelerating some of the GDK stuff. I actually
think about the idea of also reusing NEON graphics optimizations in different
libraries like GDK, SDL and maybe something else in order to improve
overall performance of the software in linux in general.

> It would be interesting to do something similar for the SSE2 backend.

I actually thought that VMX variant may be the easiest and straightforward
conversion.

> General
>
> If possible, I think it would be useful to break down the
> composite_composite_function macro into smaller bits, that mirror the
> structure of the generated code, and then add a comment to the top of
> each sub-routine. For example, a sub-macro for the initialization of
> the registers plus setup, one for the left unligned part of the
> scanline, one for the middle part, one for the right unaligned part,
> one for moving to the next line, and one for doing the small rectangle
> part.
>
> I think this would make it easier to grasp what is going on.

I was considering to add more comments there, but was not sure whether it
makes much sense before all the features are implemented (like 24bpp support).

> Also, in various places, more specific comments would be useful, in
> addition to the (generally good) highlevel comments that are already
> there.
>
> For example,
>
> * I don't fully understand what the abits argument to the load/store
>   functions is supposed to be doing. Does it have to do with masking
>   in 0xff as appropriate? Part of this may be that I don't know what
>
>      [ &mem_operand&, :&abits& ]!

That's an alignment specifier. Load/store instructions with strictly
specified alignment (128-bit or more) are a bit faster. And surely,
memory address needs to be properly aligned, otherwise we get an
exception.

>   means
>
> * A comment that .regs_shortage really means that H and W are spilled
>   to the stack.

Yes, for the most complex cases like having source, mask and destination,
there are not enough spare registers for all the local variables, so some
of the data has to go to stack.

> and similar.
>
> Though in general, the code is well commented.
>
> Denterleaving:
>
> What is the benefit of deinterleaving?

We just can load the following data
A1R1G1B1 A2R2G2B2 A3R3G3B3 A4R4G4B4 A5R5G5B5 A6R6G6B6 A7R7G7B7 A8R8G8B8

... into four 64-bit NEON registers like this:
A1A2A3A4A5A6A7A8 R1R2R3R4R5R6R7R8 G1G2G3G4G5G6G7G8 B1B2B3B4B5B6B7B8

It can be done either by a dedicated VLD4 instruction (takes 4 cycles) or
by VLD1 instruction followed by 4 VUZP instructions (takes 3 + 4 cycles).

And then it is easy to do bulk SIMD multiplication of A1A2A3A4A5A6A7A8 by
R1R2R3R4R5R6R7R8 or similar operations. Doing eight 8-bit multiplications
per cycle makes alpha blending really fast.

> Why is there is no deinterleaving for the inner loop, and only for the
> head and tail? Are the callers supposed to do this themselves if they
> want it?

Deinterleaving is optional, and the developer who is implementing a new fast
path function may decide not to use it. It just does not make sense for
SRC or ADD operations, but helps OVER a lot.

Inner loop has to do some memory operations, so it has to use the right 
instruction (either VLD1 or VLD4) depending on the preferred data
representation.

> Cache preload:
>
> * As far as I can tell, this macro is preloading with PF_X relative to
>   PF_SRC, but PF_X is always an offset into a scanline because you
>   subtract ORIG_W whenever it exceed, and PF_SRC is set to SRC, but
>   never updated anywhere that I can see. So it preloads different
>   parts of the first line over and over?

PF_SRC is updated by LDRGEB instruction (it is pre-increment variant of
addressing), so it gets changed to the next scanline there.

> * It seems like you could save a bunch of registers by simply always
>   prefetching some fixed number of pixels ahead of where you are going
>   to read. Or alternatively, just dump PF_X and keep the number of
>   pixels to prefetch ahead in that register. But presumably there is
>   some reason not to do this.

Yes, it is just generally faster, I posted some benchmarks earlier:
http://lists.cairographics.org/archives/cairo/2009-July/017813.html

A longer explanation is the following. Because at least OMAP3 has
a rather slow memory, prefetch distance needs to be quite large.
Depending on the performance of data processing part, prefetch may need
to be up to ~300 bytes ahead to work efficiently. 300 bytes ahead is
something like 150 pixels for 16bpp and it is rather a lot.

When using some fixed prefetch distance, handling of relatively small
images becomes inefficient for the cases when stride is much larger than
width. So 300 bytes ahead prefetch would be totally useless and even
harmful for processing images having width smaller than 150 pixels. Though
admittedly, most images have stride more or less equal to width (unless
somebody makes a heavy use of "subimages"). On the other hand, when
prefetching is needed for the destination buffer (for OVER operation),
fine-grained prefetch helps a lot because stride and width are quite
common to be different for the destination buffer.

> * If prefetch_distance is 0, shouldn't this macro not generate
>   anything at all?

Well, this behavior is undefined at the moment :)

Having an option to either disable prefetch completely or use a simple "fixed
distance ahead" prefetcher may be a useful addition.

Simple prefetcher may be probably useful for A5 cores, based on the
information from Jonathan.

> * I see that you have (H - 1) stored in the upper 28 bits of PF_CTL,
>   but are those bits actually being used for anything other than
>   preventing the ldrs? Ie., it will still attempt to use the plds
>   below the image, right?

It is used as the counter which limits the number of jumps to the next
scanline. Once the counter gets negative, the scanline gets latched
and prefetch may run over the last scanline multiple times but never
goes below it.

> If I'm misreading this completely, it would be good to have some more
> detailed comments here.
>
> A couple of things that it may or may not be worth thinking about:
>
> * Maybe add support for skipping unnecessary destination reads? Ie.,
>   in the case of OVER, there is no reason to read the destination if
>   the mask is 0, or if the combined (SRC IN MASK) is 1.
>
>   In my experience, this is a win for many images that
>   happen in practice. Consider these common cases:
>
>          - Text: most pixels are either fully opaque or fully
>            transparent, and in either case, no destination read is
>            necessary.
>
>          - Rounded antialiased rectangle. The corners are transparent
>            and the body is opaque or transparent. Essentially none of
>            the pixels actually need the destination.

NEON code processes 8 pixels at once. Checking individual pixels is not going
to work well. Checking any NEON computed result (like "SRC IN MASK") and
branching based on it is also not going to work well just because transferring
data from NEON to ARM is very slow (~20 cycles).

> * Does ARM have the equivalent of movnt? It may or may not be
>   interesting to use them for the operations that are essentially
>   solid fills.

There is no such instruction as far as I know.

> * I don't fully understand why you need the tail/head_tail/head split,
>   but if it is to save a branch instruction, maybe you could use the
>   standard compiler trick of turning a while loop into this:
>
>            jump test
>         body:
>            <body>
>         test:
>            <test code>
>            conditional_jump body.

No, it's just a trick to improve instructions scheduling. Let's suppose
that we have to use 4 instructions per pixel (L - load from the source buffer,
A and B - some arithmetic, S - store to the destination buffer). In this
case, a naive loop for processing 4 pixels would look like this:

(L1 A1 B1 S1) (L2 A2 B2 S2) (L3 A3 B3 S3) (L4 A4 B4 S4)

Let's also suppose that each four instructions for processing each pixel
make up a dependency chain which prevents dual issue.

Now let's split pixels processing code into "head" (L A) and "tail" (B S)
parts. The pipelined loop processing this data would look like:

head1 (tail1 head2) (tail2 head3) (tail3 head4) tail4

or if we expand code to instructions and reorder them a bit:

L1 A1 (L2 B1 A2 S1) (L3 B2 A3 S2) (L4 B3 A4 S3) B4 S4

This is much better for performance because now we have pairs of instructions 
which have some very nice properties:
1. they are now fully independent from each other
2. they use different execution units (load-store and arithmetic), which is
critical for NEON as it is the only dual issue possibility

So we get some small setup overhead, but the main loop can run up to twice
faster because of dual issue possibilities.

But even without considering dual issue, the instructions may have (and do
have) some latencies. With the pipelined variant of code, now the distance
between L2 and S2 for example is much larger and spans over two loop
iterations. If we suppose that each of the instruction had latency 2 and we
had a single cycle stall after each instruction in the original code, then
the pipelined code can execute without any stalls and the performance is
doubled again.

In practice, with real NEON fast path functions on Cortex-A8, pipelining
provides up to 30-40% speedup for working with the data fully cached in L1
cache.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cairographics.org/archives/cairo/attachments/20091027/4fb5f34c/attachment.pgp 

From k.kooi at student.utwente.nl  Tue Oct 27 00:52:11 2009
From: k.kooi at student.utwente.nl (Koen Kooi)
Date: Tue, 27 Oct 2009 08:52:11 +0100
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <200910270418.30150.siarhei.siamashka@gmail.com>
References: <200910140113.17147.siarhei.siamashka@gmail.com>	<ye8fx96w2sz.fsf@camel29.daimi.au.dk>
	<200910270418.30150.siarhei.siamashka@gmail.com>
Message-ID: <hc68rb$9dn$1@ger.gmane.org>

On 27-10-09 03:18, Siarhei Siamashka wrote:
> On Monday 26 October 2009, Soeren Sandmann wrote:

>>> Now the thing to solve is how to handle the systems other than
>>> linux. There is a potential problem with ABI compatibility - the
>>> functions must be fully compatible with the calling conventions,
>>> etc. For now I'm only sure that they are compatible with Linux
>>> EABI. Most likely the other systems should be fine too, or will be
>>> fine with a few tweaks.
>>
>> I think it's perfectly fine even if it is Linux specific at first;
>> people interested in other operating systems can feel free to send
>> patches.
>
> I was more worried about what to do with the old NEON code. How do we even
> know whether it is even used (or will be used) by anyone on any non-linux
> systems?
>
> I would probably even go as far as removing old NEON optimizations completely.
> They are available in 0.16.x versions of pixman and can be taken back into
> action if needed. Feedback from the users of Windows Mobile, Symbian and
> maybe some other systems running on ARM would be welcome.

WinMo and WinCE don't support NEON currently, you can hack it in, but 
then you loose VFP support. Supposedly fixed in the next WinMo release 
(R4?).

regards,

Koen


From siarhei.siamashka at gmail.com  Tue Oct 27 04:25:34 2009
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 27 Oct 2009 13:25:34 +0200
Subject: [cairo] [PATCH] pixman: C fast path for add_1000_1000 and
	over_n_1_8888
In-Reply-To: <ye8bpjuw1do.fsf@camel29.daimi.au.dk>
References: <200910260228.24561.siarhei.siamashka@gmail.com>
	<ye8bpjuw1do.fsf@camel29.daimi.au.dk>
Message-ID: <200910271325.38290.siarhei.siamashka@gmail.com>

On Monday 26 October 2009, Soeren Sandmann wrote:
> Hi,
>
> > These two fast path functions dealing with 1-bit data are needed
> > to improve performance of xfce4 terminal. Some other applications
> > may potentially benefit too.
>
> A couple of minor comments:
>
> Can we get the two fast paths enabled in two separate commits to
> facilitate bisecting?
>
> > +static void
> > +fast_composite_over_n_1_8888 (pixman_implementation_t *imp,
> > +                              pixman_op_t              op,
> > +
> > + [...]
> > +	    if (bitcache & bitmask)
> > +		*dst = over (src, *dst);
>
> It would likely be a big win to check whether the alpha channel of the
> source is 0xFF (which is almost always is), then simply writing out
> the source if it is. That would completely avoid reading the
> destination from memory.

A good catch.

> > +    { PIXMAN_OP_OVER, PIXMAN_solid,    PIXMAN_a1,       PIXMAN_a8r8g8b8,
> > fast_composite_over_n_1_8888, 0 }, +    { PIXMAN_OP_OVER, PIXMAN_solid,  
> >  PIXMAN_a1,       PIXMAN_x8r8g8b8, fast_composite_over_n_1_8888, 0 },
>
> I think this one can be enabled for destinations of type x8b8g8r8 and
> a8b8g8r8 as well, since pixman_image_get_solid() takes care of the
> swapping.
>
> Other than those things, it looks good to me.

Thanks for the review.

Patches corrected according to your comments, tested on both big and little
endian systems and pushed to master.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cairographics.org/archives/cairo/attachments/20091027/e99ef6ca/attachment.pgp 

From uraymeiviar at yahoo.com  Tue Oct 27 04:27:16 2009
From: uraymeiviar at yahoo.com (uray meiviar)
Date: Tue, 27 Oct 2009 04:27:16 -0700 (PDT)
Subject: [cairo] transparency with alpha channel RGBA
Message-ID: <378542.28834.qm@web54101.mail.re2.yahoo.com>

Hello,

few question, i'am trying to build openGL application which most of the textures are generated by Cairo, I create cairo surface using cairo_image_surface_create_for_data() with CAIRO_FORMAT_ARGB32 format and fetch the data to the GPU texture, but my problem is, on these codes:

cairo_set_source_rgba (this->canvas, 1.0, 1.0, 1.0, 0.5);
cairo_set_operator (this->canvas, CAIRO_OPERATOR_SOURCE);
cairo_paint (this->canvas);

I got grayed texture instead of white texture with half transparency, on the cairo surface data I got 0x808080808080...
instead of 0xFFFFFF80FFFFFF80FF.... it seems that the white color (1.0,1.0,1.0) are premultiplied by its alpha channel value of (0.5) resulting to (0.5,0.5,0.5,0.5 = 0x80808080...).

how do I get, non-premultiplied color so my openGL texture will have correct alpha channel values?

thank you.


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091027/94666c33/attachment-0001.htm 

From sandmann at daimi.au.dk  Tue Oct 27 04:57:30 2009
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: 27 Oct 2009 12:57:30 +0100
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <200910270418.30150.siarhei.siamashka@gmail.com>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
	<ye8fx96w2sz.fsf@camel29.daimi.au.dk>
	<200910270418.30150.siarhei.siamashka@gmail.com>
Message-ID: <ye87huhjbh1.fsf@camel24.daimi.au.dk>

Hi,

> > I think it's perfectly fine even if it is Linux specific at first;
> > people interested in other operating systems can feel free to send
> > patches.
> 
> I was more worried about what to do with the old NEON code. How do we even
> know whether it is even used (or will be used) by anyone on any non-linux
> systems?
> 
> I would probably even go as far as removing old NEON optimizations completely.
> They are available in 0.16.x versions of pixman and can be taken back into
> action if needed. Feedback from the users of Windows Mobile, Symbian and
> maybe some other systems running on ARM would be welcome.

I agree. It makes sense to remove them at least in the 0.17 series,
and if people complain, we can pull them back in.

> Yes, and even 24bpp can be supported, though it will add a lot more
> of conditionally compiled parts and clutter the code a bit.
> 
> 24bpp may be quite useful for accelerating some of the GDK stuff. I actually
> think about the idea of also reusing NEON graphics optimizations in different
> libraries like GDK, SDL and maybe something else in order to improve
> overall performance of the software in linux in general.

At some point it makes sense to make the pixman API available for
general consumption so that people can use it in cases like
those. This may require an API break first though, since parts of the
API are currently somewhat embarrassing (pixman_set_static_pointers(),
and pixman_blt()/fill() come to mind, but the 16 bit regions should
also eventually go away).

Some of those cases should probably just use cairo.

> > If possible, I think it would be useful to break down the
> > composite_composite_function macro into smaller bits, that mirror the
> > structure of the generated code, and then add a comment to the top of
> > each sub-routine. For example, a sub-macro for the initialization of
> > the registers plus setup, one for the left unligned part of the
> > scanline, one for the middle part, one for the right unaligned part,
> > one for moving to the next line, and one for doing the small rectangle
> > part.
> >
> > I think this would make it easier to grasp what is going on.
> 
> I was considering to add more comments there, but was not sure whether it
> makes much sense before all the features are implemented (like 24bpp
> support).

Breaking it down into submacros that mirror the structure of the
generated code would be useful before pushing this, I think.

> > Also, in various places, more specific comments would be useful, in
> > addition to the (generally good) highlevel comments that are already
> > there.
> >
> > For example,
> >
> > * I don't fully understand what the abits argument to the load/store
> >   functions is supposed to be doing. Does it have to do with masking
> >   in 0xff as appropriate? Part of this may be that I don't know what
> >
> >      [ &mem_operand&, :&abits& ]!
> 
> That's an alignment specifier. Load/store instructions with strictly
> specified alignment (128-bit or more) are a bit faster. And surely,
> memory address needs to be properly aligned, otherwise we get an
> exception.

Ok, that sense. I had gotten it into my head that "a" stood for alpha,
so I couldn't make heads or tail of it.

> > * If prefetch_distance is 0, shouldn't this macro not generate
> >   anything at all?
> 
> Well, this behavior is undefined at the moment :)

But in pixman_composite_src_n_8_asm_neon(), you do set it to 0?



Soren

From Jacob.Bramley at arm.com  Tue Oct 27 07:13:15 2009
From: Jacob.Bramley at arm.com (Jacob Bramley)
Date: Tue, 27 Oct 2009 14:13:15 -0000
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <hc4moh$nhb$1@ger.gmane.org>
References: <200910140113.17147.siarhei.siamashka@gmail.com><ye8fx96w2sz.fsf@camel29.daimi.au.dk>
	<hc4moh$nhb$1@ger.gmane.org>
Message-ID: <000001ca570f$a063c720$e12b5560$@Bramley@arm.com>

> > Right, instruction scheduling is the main disadvantage to using the
> > assembler as opposed to intrinsics. Cortex A9 is out-of-order I
> > believe, so it will have different scheduling requirements than the
> > A8, which in turn likely has different scheduling requirements than
> > earlier in-order CPUs. Though, a reasonable approach might be to
> > assume that the A9 will not be very sensitive to scheduling at all
> > (due to it being out-of-order), and then simply optimize for the A8.
> 
> A9 has a big downside though: the NEON block was cut-down to make place
> for a full VFP block instead of the VFPlite block in the A8 cores, so
> using NEON will be slower compared to A8. Hopefully the out-of-order
> will make up for it, but pure NEON code will take a hit.

Where did you hear this? A8 does indeed have VFPlite (as opposed to A9's full VFP
implementation), but A9 certainly doesn't have a cut-down NEON.

Something to be aware of, however, is that A9 can't issue a VFP instruction until the previous
NEON instruction has cleared out of the pipeline (and vice-versa), so interleaving NEON and VFP
really hurts on A9 but didn't really make a huge difference on A8.





From k.kooi at student.utwente.nl  Tue Oct 27 07:23:09 2009
From: k.kooi at student.utwente.nl (Koen Kooi)
Date: Tue, 27 Oct 2009 15:23:09 +0100
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <8345.18296546793$1256653227@news.gmane.org>
References: <200910140113.17147.siarhei.siamashka@gmail.com><ye8fx96w2sz.fsf@camel29.daimi.au.dk>	<hc4moh$nhb$1@ger.gmane.org>
	<8345.18296546793$1256653227@news.gmane.org>
Message-ID: <hc6vod$k2o$1@ger.gmane.org>

On 27-10-09 15:13, Jacob Bramley wrote:
>>> Right, instruction scheduling is the main disadvantage to using the
>>> assembler as opposed to intrinsics. Cortex A9 is out-of-order I
>>> believe, so it will have different scheduling requirements than the
>>> A8, which in turn likely has different scheduling requirements than
>>> earlier in-order CPUs. Though, a reasonable approach might be to
>>> assume that the A9 will not be very sensitive to scheduling at all
>>> (due to it being out-of-order), and then simply optimize for the A8.
>>
>> A9 has a big downside though: the NEON block was cut-down to make place
>> for a full VFP block instead of the VFPlite block in the A8 cores, so
>> using NEON will be slower compared to A8. Hopefully the out-of-order
>> will make up for it, but pure NEON code will take a hit.
>
> Where did you hear this? A8 does indeed have VFPlite (as opposed to A9's full VFP
> implementation), but A9 certainly doesn't have a cut-down NEON.

I keep hearing it on various places in the internet, but apparently I'm 
wrong. Laurent went on record and said "the A9 NEON unit is the exact 
same as the A8 one"

> Something to be aware of, however, is that A9 can't issue a VFP instruction until the previous
> NEON instruction has cleared out of the pipeline (and vice-versa), so interleaving NEON and VFP
> really hurts on A9 but didn't really make a huge difference on A8.

I guess that's where the confusing stems from. Let's hope google indexes 
this thread so the truth will surface :)

regards,

Koen



From gerdusvanzyl at gmail.com  Tue Oct 27 12:07:08 2009
From: gerdusvanzyl at gmail.com (Gerdus van Zyl)
Date: Tue, 27 Oct 2009 21:07:08 +0200
Subject: [cairo] Windows Show Glyph Bug
Message-ID: <91882ea90910271207i2f79f66am98043121c235b3ed@mail.gmail.com>

I found a bug that only appears on windows surface without alpha.
Surface with alpha uses the fallbacks and does not show this bug.
It looks like it's setting a clip when showing glyphs and does not
remove the clip again.
My cairo using code worked in 1.8.8 but does not in current git
version. See attached images for illustration and patch that fixes the
bug. Probably the wrong way to fix it but works in my limited testing
using my code.

thanks.

~Gerdus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: err.png
Type: image/png
Size: 3704 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091027/4e40f08d/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: good.png
Type: image/png
Size: 3186 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091027/4e40f08d/attachment-0001.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Move-SaveDC-before-setting-clip.patch
Type: application/octet-stream
Size: 1156 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091027/4e40f08d/attachment.obj 

From chris at chris-wilson.co.uk  Tue Oct 27 12:22:33 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 27 Oct 2009 19:22:33 +0000
Subject: [cairo] Windows Show Glyph Bug
In-Reply-To: <91882ea90910271207i2f79f66am98043121c235b3ed@mail.gmail.com>
References: <91882ea90910271207i2f79f66am98043121c235b3ed@mail.gmail.com>
Message-ID: <1256671149-sup-7044@broadwater.alporthouse.com>

Excerpts from Gerdus van Zyl's message of Tue Oct 27 19:07:08 +0000 2009:
> I found a bug that only appears on windows surface without alpha.
> Surface with alpha uses the fallbacks and does not show this bug.
> It looks like it's setting a clip when showing glyphs and does not
> remove the clip again.
> My cairo using code worked in 1.8.8 but does not in current git
> version. See attached images for illustration and patch that fixes the
> bug. Probably the wrong way to fix it but works in my limited testing
> using my code.

Sounds definitely like something I broke when pushing the clip down into
the actual backend operations. Hmm, not convinced that your patch would
restore behaviour without closer inspection... However, as always I'm in
the middle of completely breaking the backends once more, joy!

Thanks for the report and the patch, I'll try to do some win32 testing
before the next overhaul (mainly because I'm optimistic that this
rewiring will have a noticeable performance benefit for win32 in
particular).
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From jonathan.morton at movial.com  Wed Oct 28 04:32:06 2009
From: jonathan.morton at movial.com (Jonathan Morton)
Date: Wed, 28 Oct 2009 13:32:06 +0200
Subject: [cairo] pixman: New ARM NEON optimizations
In-Reply-To: <hc6vod$k2o$1@ger.gmane.org>
References: <200910140113.17147.siarhei.siamashka@gmail.com>
	<ye8fx96w2sz.fsf@camel29.daimi.au.dk>	<hc4moh$nhb$1@ger.gmane.org>
	<8345.18296546793$1256653227@news.gmane.org>
	<hc6vod$k2o$1@ger.gmane.org>
Message-ID: <1256729526.18132.139.camel@localhost.localdomain>

On Tue, 2009-10-27 at 15:23 +0100, Koen Kooi wrote:
> > Something to be aware of, however, is that A9 can't issue a VFP instruction until the previous
> > NEON instruction has cleared out of the pipeline (and vice-versa), so interleaving NEON and VFP
> > really hurts on A9 but didn't really make a huge difference on A8.
> 
> I guess that's where the confusing stems from. Let's hope google indexes 
> this thread so the truth will surface :)

It's also a potentially significant difference from PowerPC's Altivec
(or VMX).  The PPC G4 and G5 have scalar FPUs that are totally separate
from the vector unit, allowing potentially 5 or 6 single-precision FLOPS
per cycle if you really push hard.  This is helped by the triple and
quadruple issue front-ends, which allow some memory and control traffic
in addition to full FP throughput.

On ARMv7-A, the "scalar" FPU is aliased into the NEON registers (and
possibly other hardware), which is probably why the A9 requires the
pipeline flush when switching between the two.  It's still worthwhile to
run integer control logic "behind" the vector computation though, and
double-issue is good enough for that.

Of course, we're not doing heavy FP in Pixman...

Another trick about the A9 I found by scraping the public docs: the A9
has a wide and flexible dispatch logic (each execution unit can pull an
instruction from the queue), but can only decode 2 instructions per
cycle (which then join the dispatch queue).

So for most purposes you should treat it as being dual-issue like an A8,
but with far fewer rules about which instructions can go together, and
less worry about precise latencies - obviously you can still be held up
by saturating an execution unit.  I can't tell whether it is able to
fold a branch in addition to the two full decodes, but if you optimise
for A8 that doesn't matter.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com



From a.g.nienhuis at gmail.com  Wed Oct 28 06:05:14 2009
From: a.g.nienhuis at gmail.com (Arjen Nienhuis)
Date: Wed, 28 Oct 2009 14:05:14 +0100
Subject: [cairo] cairo + librsvg = svg viewer
In-Reply-To: <20091025123108.223570@gmx.net>
References: <20091025123108.223570@gmx.net>
Message-ID: <11ddbd200910280605g3729920k96d18c43b76ebc33@mail.gmail.com>

> May be you have advanced a little bit in the problem of converting the librsvg header-files or have found other solutions to display svg in Delphi.

Doe something like this work?

type SVGHandle = Pointer;

function rsvg_handle_new_from_file(path: PChar; error: Pointer):
SVGHandle; stdcall; external 'librsvg-2-2.dll';
function rsvg_handle_render_cairo(handle: SVGHandle; ctx: Pointer):
BOOL; stdcall; external 'librsvg-2-2.dll';

From luizmed at oi.com.br  Wed Oct 28 09:19:34 2009
From: luizmed at oi.com.br (Luiz Americo Pereira Camara)
Date: Wed, 28 Oct 2009 13:19:34 -0300
Subject: [cairo] cairo + librsvg = svg viewer
In-Reply-To: <20091025123108.223570@gmx.net>
References: <20091025123108.223570@gmx.net>
Message-ID: <4AE86F16.5000606@oi.com.br>

philipp koehler escreveu:
> Hello,
>
> I am trying to do the same thing like you (display svg in Delphi-programs using cairo for rendering and librsvg for svg-parsing)and I have 
> exactly the same problem like you.
>
> I was using the h2pas tool from Lazarus 
> http://wiki.lazarus.freepascal.org/Creating_bindings_for_C_libraries
> to do a header conversion of the librsvg.dll-headers I found on the gnome homepage. Unfortunatly I got stuck because in those header-files there are dependencies which point out of the scope covered by the header-files.
> I was suspecting I had the wrong header files because afaik header-files for dynamic libs should not have outside dependencies except for maybe very basic libaries.
> May be you have advanced a little bit in the problem of converting the librsvg header-files or have found other solutions to display svg in Delphi.
>   

I did that with fpc/Lazarus almost a year ago.

Take a look at 
http://code.google.com/p/luipack/source/browse/trunk/cairo/rsvg/rsvg.pas 
. You can adapt for Delphi

Luiz


From vladimir at pobox.com  Wed Oct 28 11:18:54 2009
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Wed, 28 Oct 2009 11:18:54 -0700
Subject: [cairo] Problems with building Cairo for Windows CE
In-Reply-To: <4AD3DBEB.1000404@onghu.com>
References: <4ACDD95E.4050006@onghu.com> <4ACF5CCF.6070104@onghu.com>	
	<4AD33F55.5040709@onghu.com>
	<91882ea90910121202x583b0fbcn3c8e43e1d869341@mail.gmail.com>
	<4AD3DBEB.1000404@onghu.com>
Message-ID: <4AE88B0E.8070204@pobox.com>

On 10/12/2009 6:46 PM, Mohit Sindhwani wrote:
> Gerdus van Zyl wrote:
>    
>> You might be interested in this patch in the mozilla source code for
>> cairo:
>> http://hg.mozilla.org/mozilla-central/file/3205228e9838/gfx/cairo/wince-fixes.patch
>>
>> If you don't get a reply on the ML you might try asking on the cairo
>> IRC channel, people are sometimes more talkative on there.
>>      
> Thanks Gerdus,
>
> You're right - the list has been quiet on these issues, but I guess
> there are not that many people using it on Windows CE then... all the
> same, I do like Cairo and if it works on Windows CE, it'll be great for
> what I'm planning.  But I need it to work so that I can do a meaningful
> benchmark.
>    

We've actually moved away from using the Win32 surface on CE -- it 
provides very little benefit compared to just using a straight image 
surface and doing a final blit, especially for anything moderately 
complex.  Additionally, CE can't support text rendering using the win32 
fonts API (it has no way to render glyphs), so Freetype has to be used.  
We just render everything to a 24bpp image surface so that we don't pay 
any extra composite cost, and do a final 24->16 blit at the end.

     - Vlad


From ml3p at onghu.com  Wed Oct 28 12:06:25 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Thu, 29 Oct 2009 03:06:25 +0800
Subject: [cairo] Problems with building Cairo for Windows CE
In-Reply-To: <4AE88B0E.8070204@pobox.com>
References: <4ACDD95E.4050006@onghu.com> <4ACF5CCF.6070104@onghu.com>	
	<4AD33F55.5040709@onghu.com>
	<91882ea90910121202x583b0fbcn3c8e43e1d869341@mail.gmail.com>
	<4AD3DBEB.1000404@onghu.com> <4AE88B0E.8070204@pobox.com>
Message-ID: <4AE89631.4080700@onghu.com>

Vladimir Vukicevic wrote:
> On 10/12/2009 6:46 PM, Mohit Sindhwani wrote:
>> Gerdus van Zyl wrote:
>>   
>>> You might be interested in this patch in the mozilla source code for
>>> cairo:
>>> http://hg.mozilla.org/mozilla-central/file/3205228e9838/gfx/cairo/wince-fixes.patch 
>>>
>>>
>>> If you don't get a reply on the ML you might try asking on the cairo
>>> IRC channel, people are sometimes more talkative on there.
>>>      
>> Thanks Gerdus,
>>
>> You're right - the list has been quiet on these issues, but I guess
>> there are not that many people using it on Windows CE then... all the
>> same, I do like Cairo and if it works on Windows CE, it'll be great for
>> what I'm planning.  But I need it to work so that I can do a meaningful
>> benchmark.
>>    
>
> We've actually moved away from using the Win32 surface on CE -- it 
> provides very little benefit compared to just using a straight image 
> surface and doing a final blit, especially for anything moderately 
> complex.  Additionally, CE can't support text rendering using the 
> win32 fonts API (it has no way to render glyphs), so Freetype has to 
> be used.  We just render everything to a 24bpp image surface so that 
> we don't pay any extra composite cost, and do a final 24->16 blit at 
> the end.
>
Thanks Vlad,

Is there a guide/ blog post/ repository that I could use?  Or, just use 
an image surface and that's it?

Cheers,
Mohit.
10/29/2009 | 3:06 AM.



From jpihlaja at cc.helsinki.fi  Wed Oct 28 14:00:01 2009
From: jpihlaja at cc.helsinki.fi (M Joonas Pihlaja)
Date: Wed, 28 Oct 2009 23:00:01 +0200 (EET)
Subject: [cairo] transparency with alpha channel RGBA
In-Reply-To: <378542.28834.qm@web54101.mail.re2.yahoo.com>
References: <378542.28834.qm@web54101.mail.re2.yahoo.com>
Message-ID: <Pine.OSF.4.61.0910282251240.71289@sirppi.helsinki.fi>


Hi,

On Tue, 27 Oct 2009, uray meiviar wrote:

> how do I get, non-premultiplied color so my openGL texture will have 
> correct alpha channel values?

I believe you can use premultiplied textures with OpenGL by 
configuring the right blend function.  For the cases where using 
unpremultiplied data is unavoidable you'll need to convert the 
premultiplied data yourself before uploading the textures.  Various 
implementations of unpremultipliers are available here:

http://cgit.freedesktop.org/~joonas/unpremultiply/tree/

Generally the overhead from unpremultiplication is fairly low as long 
as you don't implement it using three divisions per pixel.

Cheers,

Joonas

From uraymeiviar at yahoo.com  Thu Oct 29 00:14:20 2009
From: uraymeiviar at yahoo.com (uray meiviar)
Date: Thu, 29 Oct 2009 00:14:20 -0700 (PDT)
Subject: [cairo] transparency with alpha channel RGBA
In-Reply-To: <Pine.OSF.4.61.0910282251240.71289@sirppi.helsinki.fi>
References: <378542.28834.qm@web54101.mail.re2.yahoo.com>
	<Pine.OSF.4.61.0910282251240.71289@sirppi.helsinki.fi>
Message-ID: <876900.31524.qm@web54109.mail.re2.yahoo.com>

thank you for your reply,

currently I solved it by un-multiply the RGB value (divide RGB values by A) on fragment shader, which is no significant penalty since it was done on GPU, but now my concern is the wasted CPU cycle for RGB*A multiplication by Cairo (since CPU is far too slow compared to GPU), is there any switch to turn off premultiplied RGB process?



________________________________
From: M Joonas Pihlaja <jpihlaja at cc.helsinki.fi>
To: uray meiviar <uraymeiviar at yahoo.com>
Cc: cairo at cairographics.org
Sent: Thu, October 29, 2009 4:00:01 AM
Subject: Re: [cairo] transparency with alpha channel RGBA


Hi,

On Tue, 27 Oct 2009, uray meiviar wrote:

> how do I get, non-premultiplied color so my openGL texture will have 
> correct alpha channel values?

I believe you can use premultiplied textures with OpenGL by 
configuring the right blend function.  For the cases where using 
unpremultiplied data is unavoidable you'll need to convert the 
premultiplied data yourself before uploading the textures.  Various 
implementations of unpremultipliers are available here:

http://cgit.freedesktop.org/~joonas/unpremultiply/tree/

Generally the overhead from unpremultiplication is fairly low as long 
as you don't implement it using three divisions per pixel.

Cheers,

Joonas



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091029/0d4e2140/attachment.html 

From zhizhonghe at yahoo.com.cn  Thu Oct 29 00:44:05 2009
From: zhizhonghe at yahoo.com.cn (=?gb2312?B?1cWyrg==?=)
Date: Thu, 29 Oct 2009 15:44:05 +0800
Subject: [cairo] A problem about building cairo
Message-ID: <004401ca586b$975a1a50$c60e4ef0$@com.cn>

Hello guys~

 

I have some trouble with building cairo lib. My OS is Vista, and my IDE is
VS2009. I try to do it under the suggestion ?Building On Windows(Mozilla
Build Environment flavor)?. Some preparation has completed, such as
installing zlib libpng and MozillaBuild environment. Pixman has alse be make
successfually. When cairo?s configuration was running in Mingw32.exe, an
error occur, that was ?configure: error: no acceptable ld found in $PATH?.
ld.exe havn?t be found in my PC. There are many questions about that on
Website, however not all solutions are of help? 

 

Thanks~

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091029/c3d2a147/attachment.htm 

From jpihlaja at cc.helsinki.fi  Thu Oct 29 03:28:58 2009
From: jpihlaja at cc.helsinki.fi (M Joonas Pihlaja)
Date: Thu, 29 Oct 2009 12:28:58 +0200 (EET)
Subject: [cairo] transparency with alpha channel RGBA
In-Reply-To: <876900.31524.qm@web54109.mail.re2.yahoo.com>
References: <378542.28834.qm@web54101.mail.re2.yahoo.com>
	<Pine.OSF.4.61.0910282251240.71289@sirppi.helsinki.fi>
	<876900.31524.qm@web54109.mail.re2.yahoo.com>
Message-ID: <Pine.OSF.4.61.0910291226480.71289@sirppi.helsinki.fi>


On Thu, 29 Oct 2009, uray meiviar wrote:

> currently I solved it by un-multiply the RGB value (divide RGB 
> values by A) on fragment shader, which is no significant penalty 
> since it was done on GPU, 

Ah, sounds good!

> but now my concern is the wasted CPU cycle 
> for RGB*A multiplication by Cairo (since CPU is far too slow 
> compared to GPU), is there any switch to turn off premultiplied RGB 
> process?

No, sorry.  I wouldn't worry about it though.

Cheers,

Joonas

From uraymeiviar at yahoo.com  Thu Oct 29 06:11:23 2009
From: uraymeiviar at yahoo.com (uray meiviar)
Date: Thu, 29 Oct 2009 06:11:23 -0700 (PDT)
Subject: [cairo] A problem about building cairo
In-Reply-To: <004401ca586b$975a1a50$c60e4ef0$@com.cn>
References: <004401ca586b$975a1a50$c60e4ef0$@com.cn>
Message-ID: <696458.61762.qm@web54110.mail.re2.yahoo.com>

hello there,

I got Cairo compiled by myself using Visual Studio 2008 IDE & compiler, without mingw or other mozilla/linux build tools & environments, i ran windows 7 x64 version and build x64 version of Cairo, what I need to do was build static library of zlib and libpng, and hardest part was to build pixman static library, once all those library built, it is easy to build cairo DLL, i can share my VS solution if you want.

thanks



________________________________
From: ?? <zhizhonghe at yahoo.com.cn>
To: cairo at cairographics.org
Sent: Thu, October 29, 2009 2:44:05 PM
Subject: [cairo] A problem about building cairo

 
Hello guys~
 
I have some trouble with building cairo lib.
My OS is Vista, and my IDE is VS2009. I try to do it under the suggestion ?Building
On Windows(Mozilla Build Environment flavor)?. Some preparation has completed,
such as installing zlib libpng and MozillaBuild environment. Pixman has alse be
make successfually. When cairo?s configuration was running in Mingw32.exe, an
error occur, that was ?configure: error: no acceptable ld found in $PATH?. ld.exe
havn?t be found in my PC. There are many questions about that on Website,
however not all solutions are of help? 
 
Thanks~
 
 

__________ Information from ESET Smart Security, version of virus signature database 4506 (20091014) __________

The message was checked by ESET Smart Security.

http://www.eset.com



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091029/c1f6534e/attachment.html 

From mikhailkozhevnikov at yandex.ru  Thu Oct 29 07:16:19 2009
From: mikhailkozhevnikov at yandex.ru (Kozhevnikov Mikhail)
Date: Thu, 29 Oct 2009 17:16:19 +0300
Subject: [cairo] indigo/dingo project announce
Message-ID: <28781256825779@webmail45.yandex.ru>

Hi All,

I have a yet another Cairo-based project to announce.

It is a cross-platform C++ library for 2D structural formula rendering, called Dingo (see attachment for a sample output). C and C# interfaces and a command-line utility are available, too. Dingo is released today as a part of the Indigo Cheminformatics toolkit. If there's anyone interested, more information is available at http://opensource.scitouch.net/indigo/dingo.

Comments and suggestions are welcome!

Best regards, 
Mikhail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pdf
Type: application/pdf
Size: 12313 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091029/af95bf4f/attachment-0001.pdf 

From ml3p at onghu.com  Thu Oct 29 07:26:35 2009
From: ml3p at onghu.com (Mohit Sindhwani)
Date: Thu, 29 Oct 2009 22:26:35 +0800
Subject: [cairo] indigo/dingo project announce
In-Reply-To: <28781256825779@webmail45.yandex.ru>
References: <28781256825779@webmail45.yandex.ru>
Message-ID: <4AE9A61B.4080600@onghu.com>

Kozhevnikov Mikhail wrote:
> Hi All,
>
> I have a yet another Cairo-based project to announce.
>
> It is a cross-platform C++ library for 2D structural formula rendering, called Dingo (see attachment for a sample output). C and C# interfaces and a command-line utility are available, too. Dingo is released today as a part of the Indigo Cheminformatics toolkit. If there's anyone interested, more information is available at http://opensource.scitouch.net/indigo/dingo.
>
> Comments and suggestions are welcome!
>
> Best regards, 
> Mikhail.
>   
In my current job, I can't imagine using it, but it looks cool :)

Cheers,
Mohit.
10/29/2009 | 10:26 PM.


From tgriggs at cincom.com  Thu Oct 29 09:38:24 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Thu, 29 Oct 2009 09:38:24 -0700
Subject: [cairo] A problem about building cairo
In-Reply-To: <004401ca586b$975a1a50$c60e4ef0$@com.cn>
References: <004401ca586b$975a1a50$c60e4ef0$@com.cn>
Message-ID: <24DF9D8A-DD3F-4492-9A9B-4CFB6FB5FADD@cincom.com>


On Oct 29, 2009, at 12:44 AM, ?? wrote:

> Hello guys~
>
> I have some trouble with building cairo lib. My OS is Vista, and my  
> IDE is VS2009. I try to do it under the suggestion ?Building On  
> Windows(Mozilla Build Environment flavor)?. Some preparation has  
> completed, such as installing zlib libpng and MozillaBuild  
> environment. Pixman has alse be make successfually. When cairo?s  
> configuration was running in Mingw32.exe, an error occur, that was  
> ?configure: error: no acceptable ld found in $PATH?. ld.exe havn?t  
> be found in my PC. There are many questions about that on Website,  
> however not all solutions are of help?

Couple weeks ago, I finished up a turnkey (i.e. push one button)  
automated build of Cairo on Windows, using devexpress and msys only  
(probably be pretty easy to tweak it for normal VS2009). It downloads,  
arranges, edits, compiles the whole thing. And even as a single dll  
with no extra dependencies. I started documenting it (the steps) on  
the wiki, but got distracted by other things. I'll see if I can't find  
some cycles to finish it up today. It might help.

--
Travis Griggs
Objologist
"You A students, you'll be back soon teaching here with me. You B  
students, you'll actually go on to be real engineers. You C students,  
you'll go into management and tell the A and B students what to do." -  
My Fluid Dynamics Professor whom I have yet to disprove



From linuxhippy at gmail.com  Sat Oct 31 03:47:22 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 31 Oct 2009 06:47:22 -0400
Subject: [cairo] Any chance to get trapezoids into public API?
Message-ID: <194f62550910310347x1c3ddd3u6ad1656b01811eb@mail.gmail.com>

Hello,

I am writing a Java2D plugin, which allows to use Cairo's tesselator+
pixman's trapezoid-rasterizer for antialiased rendering. It works
quite well, however it uses a lot of cairo-internal stuff like:

_cairo_path_fixed_stroke_to_traps, _cairo_path_fixed_fill_to_traps,
cairo_path_fixed_t, cairo_path_buf_t, cairo_traps_t,
cairo_stroke_style_t

I know by completly relying on cairo, I wouldn't have to mess with its
internals - however there is a certain impedance mismatch between
Java2D and Cairo and thats why I choose to use xrender back then.

The ideas I have to deal with this situation would be:

- Get that structures/functions public. I guess thats unlikely to
happen, as its backend-specific.
Would it be possible to some extents?

- Fork cairo specifically for this project (just call it different),
compile it to a shared library and check at run-time wether its
available or not. (fallbacks are available).
This would guarantee compatibility with all the assumptions the binding makes.

How do you think should this be solved?

Thanks, Clemens

PS: The file attached is basically the binding.
-------------- next part --------------
#include <cairo.h>
#include <config.h>
#include <X11/extensions/Xrender.h>
#include <cairoint.h>
#include <cairo-path-fixed-private.h>
#include <jni.h>
#include <jlong.h>
#include <pixman.h>
#include <math.h>

jintArray tesselate(JNIEnv *env, jintArray pointArray, jbyteArray opArray, jint pointCnt, jint opCnt, jintArray xTrapArray, jint xTrapArrayLength, jint windingRule, cairo_stroke_style_t *strokeStyle, cairo_matrix_t *tr, jint clipLowX, jint clipLowY, jint clipHiX, jint clipHiY) {
   jint* points;
   jbyte* ops;

   if((points = (jint *) (*env)->GetPrimitiveArrayCritical(env, pointArray, NULL)) == NULL) {
     return xTrapArray;
   }
   if((ops = (jbyte *) (*env)->GetPrimitiveArrayCritical(env, opArray, NULL)) == NULL) {
     return xTrapArray;
   }
   
   cairo_traps_t traps;
   _cairo_traps_init (&traps);

   traps.has_limits = 1;
   traps.limits.p1.x = _cairo_fixed_from_double(clipLowX);
   traps.limits.p1.y = _cairo_fixed_from_double(clipLowY);
   traps.limits.p2.x = _cairo_fixed_from_double(clipHiX);
   traps.limits.p2.y = _cairo_fixed_from_double(clipHiY);
   
   cairo_path_buf_t buf;
   cairo_path_fixed_t path;
   buf.num_ops = opCnt;
   buf.num_points = pointCnt;
   buf.buf_size = pointCnt*2;
   buf.op = (unsigned char*) ops;
   buf.points = points;
   buf.next = NULL;
   buf.prev = &path.buf_head;
   
   path.has_current_point = 0;
   path.has_curve_to = 1;
   path.buf_tail = &buf;
   path.buf_head.base.next = &buf;
   path.buf_head.base.num_ops = 0;
   path.buf_head.base.num_points = 0;
   path.buf_head.base.buf_size = 0;
   
   if(strokeStyle == NULL) {
     _cairo_path_fixed_fill_to_traps (&path, windingRule, 0.1, &traps);
   }else {
      cairo_matrix_t tr_inv = *tr;
      cairo_matrix_invert(&tr_inv);
     _cairo_path_fixed_stroke_to_traps (&path, strokeStyle, tr, &tr_inv, 0.1, &traps);
   }

   (*env)->ReleasePrimitiveArrayCritical(env, pointArray, points, JNI_ABORT);
   (*env)->ReleasePrimitiveArrayCritical(env, opArray, ops, JNI_ABORT);

   cairo_trapezoid_t *trapPtr = traps.traps;
   jint requiredArraySize = traps.num_traps*10 + 5;
   
   if(requiredArraySize > xTrapArrayLength) {
    xTrapArray = (jintArray) (*env)->NewIntArray(env, requiredArraySize);
   }
   
   jint* xTraps;
   if((xTraps = (jint *) (*env)->GetPrimitiveArrayCritical(env, xTrapArray, NULL)) == NULL) {
     return xTrapArray;
   }
   
   xTraps[0] = traps.num_traps;
   xTraps[1] = (jint) _cairo_fixed_to_double(traps.extents.p1.x); 
   xTraps[2] = (jint) _cairo_fixed_to_double(traps.extents.p1.y);
   xTraps[3] = (jint) ceil(_cairo_fixed_to_double(traps.extents.p2.x));
   xTraps[4] = (jint) ceil(_cairo_fixed_to_double(traps.extents.p2.y));
   
   int i; 
   int intCnt = 5;
   for (i = 0; i < traps.num_traps; i++) {
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].top);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].bottom);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].left.p1.x);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].left.p1.y);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].left.p2.x);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].left.p2.y);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].right.p1.x);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].right.p1.y);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].right.p2.x);
	  xTraps[intCnt++] = _cairo_fixed_to_16_16(trapPtr[i].right.p2.y);
    } 
   
   (*env)->ReleasePrimitiveArrayCritical(env, xTrapArray, xTraps, 0);
   
   _cairo_traps_fini(&traps);
   
  return xTrapArray;
}

JNIEXPORT jintArray JNICALL
Java_sun_java2d_xr_CairoPathBuf_tesselateFillNative
    (JNIEnv *env, jclass xsd, jintArray pointArray, jbyteArray opArray, jint pointCnt, jint opCnt, jintArray xTrapArray, jint xTrapArrayLength, jint windingRule, jint clipLowX, jint clipLowY, jint clipHiX, jint clipHiY) {
  return tesselate(env, pointArray, opArray, pointCnt, opCnt, xTrapArray, xTrapArrayLength, windingRule, NULL, NULL, clipLowX, clipLowY, clipHiX, clipHiY);
}

JNIEXPORT jintArray JNICALL
Java_sun_java2d_xr_CairoPathBuf_tesselateStrokeNative
    (JNIEnv *env, jclass xsd, jintArray pointArray, jbyteArray opArray, jint pointCnt, jint opCnt, jintArray xTrapArray, jint xTrapArrayLength, jdouble lineWidth, jint lineCap, jint lineJoin, jdouble miterLimit, jdoubleArray dashArray, jint dashCnt, jdouble dashOffset,
     jdouble m00, jdouble m01, jdouble m02, jdouble m10, jdouble m11, jdouble m12, jint clipLowX, jint clipLowY, jint clipHiX, jint clipHiY) {
 
      jdouble *dash = NULL;
      if(dashCnt > 0) {
	   if((dash = (jdouble *) (*env)->GetPrimitiveArrayCritical(env, dashArray, NULL)) == NULL) {
	      return xTrapArray;
	}
      }
      
      cairo_matrix_t tr;
      tr.xx = m00;
      tr.xy = m01;
      tr.x0 = m02;
      tr.yx = m10;
      tr.yy = m11;
      tr.y0 = m12;

      
      cairo_stroke_style_t style;
      style.line_width = lineWidth;
      style.line_cap = lineCap;
      style.line_join = lineJoin;
      style.miter_limit = miterLimit;
      style.num_dashes = dashCnt;
      style.dash_offset = dashOffset;
      style.dash = dash;
      
      jintArray result = tesselate(env, pointArray, opArray, pointCnt, opCnt, xTrapArray, xTrapArrayLength, 0, &style, &tr, clipLowX, clipLowY, clipHiX, clipHiY);
      
      if(dashCnt > 0) {
	    (*env)->ReleasePrimitiveArrayCritical(env, dashArray, dash, JNI_ABORT);
      }

      return result;
}

JNIEXPORT jlong JNICALL
Java_sun_java2d_xr_CairoAATileGenerator_rasterizeTrapezoidsNative
  (JNIEnv *env, jclass xsd, jlong maskBitPtr, jintArray xTrapArray, jintArray trapPosArray, jint trapCnt, jbyteArray bufferArray, jint xOff, jint yOff) {
    jint i;
    jint *xTraps;
    jint *trapPos;
    jbyte *buffer;  
    if((xTraps = (jint *) (*env)->GetPrimitiveArrayCritical(env, xTrapArray, NULL)) == NULL) {
     return maskBitPtr;
    }
    if((trapPos = (jint *) (*env)->GetPrimitiveArrayCritical(env, trapPosArray, NULL)) == NULL) {
     return maskBitPtr;
    }
    if((buffer = (jbyte *) (*env)->GetPrimitiveArrayCritical(env, bufferArray, NULL)) == NULL) {
     return maskBitPtr;
    }
    
    memset(buffer, 0, 32*32);
    
    //TODO: we can optimize this, by comparing wether buffer adress stays the same.
    //Warning: multithreading!!
   // pixman_image_t *mask = pixman_image_create_bits(PIXMAN_a8, 32, 32, buffer, 32);
    
    pixman_image_t *mask = (pixman_image_t *) jlong_to_ptr(maskBitPtr);
    
    if(mask == NULL || pixman_image_get_data(mask) != buffer) {
      if(mask != NULL) {
	pixman_image_unref(mask);
	//printf("Old Mask Freed!\n");
      }
      
      mask = pixman_image_create_bits(PIXMAN_a8, 32, 32, buffer, 32);
      maskBitPtr = ptr_to_jlong(mask);
      
     // printf("New Mask created!\n");
      //fflush(stdout);
    }
    

    pixman_fixed_t xTileStart = pixman_double_to_fixed(xOff);
    pixman_fixed_t yTileStart = pixman_double_to_fixed(yOff);
    pixman_fixed_t xTileEnd = xTileStart + pixman_double_to_fixed(32);
    pixman_fixed_t yTileEnd = yTileStart + pixman_double_to_fixed(32);
    
    for(i=0; i < trapCnt; i++) {
      pixman_trapezoid_t trap;
            
      int arrayIndex = trapPos[i]*10 + 5;
      
     /* trap.top = xTraps[arrayIndex + 0];
      trap.bottom = xTraps[arrayIndex + 1];
      trap.left.p1.x = xTraps[arrayIndex + 2];
      trap.left.p1.y = xTraps[arrayIndex + 3];
      trap.left.p2.x = xTraps[arrayIndex + 4];
      trap.left.p2.y = xTraps[arrayIndex + 5];
      trap.right.p1.x = xTraps[arrayIndex + 6];
      trap.right.p1.y = xTraps[arrayIndex + 7];
      trap.right.p2.x = xTraps[arrayIndex + 8];
      trap.right.p2.y = xTraps[arrayIndex + 9];    */
      
      memcpy(&trap, &xTraps[arrayIndex], 40);
     
      //printf("top:%d, tilestart: %d", trap.top, yTileStart);
      //printf(" - bottom:%d, tileend %d", trap.bottom, yTileEnd);
      
      /*Clip trapezoid to mask bounds*/
      if(trap.top < yTileStart) {
	trap.top = yTileStart;
	//printf("- start limited");
      }
      
      if(trap.bottom > yTileEnd) {
	trap.bottom = yTileEnd;
	//printf("- bottom limited");
      }
  
      
      if (trap.left.p1.x <= xTileStart && trap.left.p2.x <= xTileStart) {
	  trap.left.p1.x = xTileStart;
	  trap.left.p2.x = xTileStart;
	 // printf("- left limited");
      }

      if (trap.right.p1.x >= xTileEnd && trap.right.p2.x >= xTileEnd) {
	    trap.right.p1.x = xTileEnd;
	    trap.right.p2.x = xTileEnd;
	//    printf("- right limited");
	}
     
     // printf("\n");
     // fflush(stdout);
     
      pixman_rasterize_trapezoid (mask, &trap, -xOff, -yOff);
    }  
   
    (*env)->ReleasePrimitiveArrayCritical(env, xTrapArray, xTraps, JNI_ABORT);
    (*env)->ReleasePrimitiveArrayCritical(env, trapPosArray, trapPos, JNI_ABORT);
    (*env)->ReleasePrimitiveArrayCritical(env, bufferArray, buffer, 0);
    
    return maskBitPtr;
  }


/*TODO: Manage tiles statically, not re-allocaing everything, makes that obsolete.*/
JNIEXPORT void JNICALL
Java_sun_java2d_xr_CairoAATileGenerator_freePixmanImgPtr
  (JNIEnv *env, jclass xsd, jlong maskBitPtr) {
    pixman_image_t *mask = (pixman_image_t *) jlong_to_ptr(maskBitPtr);
    
    if(mask == NULL) {
	pixman_image_unref(mask);
      }
  }


From chris at chris-wilson.co.uk  Sat Oct 31 12:39:32 2009
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Sat, 31 Oct 2009 19:39:32 +0000
Subject: [cairo] Any chance to get trapezoids into public API?
In-Reply-To: <194f62550910310347x1c3ddd3u6ad1656b01811eb@mail.gmail.com>
References: <194f62550910310347x1c3ddd3u6ad1656b01811eb@mail.gmail.com>
Message-ID: <1257016235-sup-4424@broadwater.alporthouse.com>

Excerpts from Clemens Eisserer's message of Sat Oct 31 10:47:22 +0000 2009:
> I am writing a Java2D plugin, which allows to use Cairo's tesselator+
> pixman's trapezoid-rasterizer for antialiased rendering. It works
> quite well, however it uses a lot of cairo-internal stuff like:
[snip]
> I know by completly relying on cairo, I wouldn't have to mess with its
> internals - however there is a certain impedance mismatch between
> Java2D and Cairo and thats why I choose to use xrender back then.

My answer is simple: take cairo under the freedoms of its license and
incorporate a private copy into your library, and adapt to your needs.
Obviously this make me quite sad. I have a grand vision that involves
pushing cairo in all directions, both to improve its usage across the
desktop and to improve the capabilities for it to be (indirectly) h/w
accelerated.  Already this means that the interfaces you currently hook
into are being phased out as we find faster methods, and Java2D will
continue to suffer as the focus for driver development falls elsewhere.
(For instance, instead of switching from converting your
RenderFillRectangles span renderer to a trapezoid based one, you could
join the discussion in how we can expose a method for passing RLE spans
to RENDER. And what direction we should take the hardware acceleration
for 2D paths. At the moment it appears that we (the cairo/DDX developers)
are the ones pushing hardest and so are focused on our use cases.
Obviously I'd like to expand those use cases to include yours by
encouraging your adoption of Cairo. ;-)

If you have identified inadequacies in the public API or bottlenecks
anywhere within cairo that prevent you from using the library. Please
let us know how we can improve cairo, with profiles if possible!

Sorry for not being more helpful, but I want to ensure Cairo stays
focused on doing just one task and doing it well. Have fun developing
Java2D, I hope you find that Cairo is useful and that you do find ways
we can improve. 
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

From linuxhippy at gmail.com  Sat Oct 31 23:28:21 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sun, 1 Nov 2009 01:28:21 -0500
Subject: [cairo] Any chance to get trapezoids into public API?
In-Reply-To: <1257016235-sup-4424@broadwater.alporthouse.com>
References: <194f62550910310347x1c3ddd3u6ad1656b01811eb@mail.gmail.com>
	<1257016235-sup-4424@broadwater.alporthouse.com>
Message-ID: <194f62550910312328t1064a281oaaec960bc33587f4@mail.gmail.com>

Hi Chris,

> My answer is simple: take cairo under the freedoms of its license and
> incorporate a private copy into your library, and adapt to your needs.
Yes, thats what I thought would be best, too.

> ?Already this means that the interfaces you currently hook
> into are being phased out as we find faster methods, and Java2D will
> continue to suffer as the focus for driver development falls elsewhere.
Sure, but today trapezoids seem to be the best way to push aa coverage
values to the xserver.
When new interfaces come up, I'll adopt to a newer cairo release.

> (For instance, instead of switching from converting your
> RenderFillRectangles span renderer to a trapezoid based one, you could
> join the discussion in how we can expose a method for passing RLE spans
> to RENDER.
> And what direction we should take the hardware acceleration
> for 2D paths.
I only heard once that something like RLE spans are planned for
render,  its a welcome change.
I was never a big fan of trapezoids, and all the complexity and
inefficiency caused by them.
Does the discussion mainly happen on IRC?

> Sorry for not being more helpful, but I want to ensure Cairo stays
> focused on doing just one task and doing it well. Have fun developing
> Java2D, I hope you find that Cairo is useful and that you do find ways
> we can improve.
Thanks for beeing that helpful :)

Thanks again, Clemens

From a.g.nienhuis at gmail.com  Thu Oct 15 05:07:46 2009
From: a.g.nienhuis at gmail.com (Arjen Nienhuis)
Date: Thu, 15 Oct 2009 12:07:46 -0000
Subject: [cairo] Overflow bug painting from PixBuf?
In-Reply-To: <1255564733-sup-75@broadwater.alporthouse.com>
References: <11ddbd200910141624o167de224n26984e97f4bc7353@mail.gmail.com>
	<1255564733-sup-75@broadwater.alporthouse.com>
Message-ID: <11ddbd200910150507o1a923746idc7ba49522e04eb7@mail.gmail.com>

On Thu, Oct 15, 2009 at 2:01 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> It is a known bug, a limitation of the fixed-point 16.16 matrix that we
> use to transform images with pixman. In cairo-1.9.2, we have a
> workaround that takes advantage of the fact that we can do the
> translation independently of the matrix that extends our operating range
> a bit (but still leaves worse than desired inaccuracies). In short, try
> 1.9.2, it's probably good enough for the task at hand.

Hmm, after an hour of dpkg, easy_install, git clone and all sorts of
dependency problems I finally got:

cairo.cairo_version_string() == '1.9.2'

and then I got a segfault.

I'll try it again when there is a Ubuntu repository for it. (is
there?) I tried to upgrade cairo on my system before. When it broke I
found out how many programs depend on cairo. :-)

> Hope this helps, and you have fun with cairo!
> -ickle

I do have fun! See attachment. It's for a web-to-print system so I
could send you the real thing. :-)

Groeten, Arjen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 21.png
Type: image/png
Size: 118384 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091015/8dd85bb0/attachment-0001.png 

From tgriggs at cincom.com  Wed Oct 21 15:27:06 2009
From: tgriggs at cincom.com (Travis Griggs)
Date: Wed, 21 Oct 2009 15:27:06 -0700
Subject: [cairo] SVG Misunderstanding?
Message-ID: <F8975F8E-7F20-4C9B-8540-0B02821E8356@cincom.com>

I apologize for this being possibly off topic. I'm trying to use Cairo  
to draw an SVG file (the one attached for example). And something's  
not going right. I must be missing something obvious.

When rendered as an icon from Inkscape, I end up with a 16x16 icon,  
with 9 little orange gradient squares. They're nicely pixel aligned to  
keep it crisp. If I understand the SVG correctly, I should be able to  
do the following cairo stuff in pseudo code:

// These values derived from the height/width and the viewBox of the  
root svg node
scale( cr , 16 / 64.424 , 16 / 51.278 );
// apply the transform found at the g4466 node
matrix.xx = 0.6031636;
matrix.yx = 0;
matrix.xy = 0;
matrix.yy = 0.6190702;
matrix.x0 = 7.87836;
matrix.y0 = 5.1860675;
set_matrix( cr , &matrix );
// rect3654
rectangle(cr,
	-5.9716139,
	-15.317435,
	-5.9716139 + 28.360464,
	-15.317435 + 27.631762);
//set a source and fill after this

Unfortunately, this doesn't end up right. If I work the numbers by  
pencil myself, at least for the origin of the rectangle, I get:

(-5.9716139 * 0.6031636 + 7.87836) * (16 / 64.424) --> 1.06209
(-15.317435 * 0.6190702 + 5.1860675) * (16 / 51.278) --> -1.34061

I could almost believe that the 1.06 was just rounding error (rather  
severe actually), but the y value shouldn't be negative at all, and  
it's not at all near integral.

I don't know what I'm doing wrong. I'm wondering at this point, if  
I've mixed something in the application of viewBox.

Any helps or hints would be hugely appreciated.

--
Travis Griggs
Objologist
One man's blue plane is another man's pink plane.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Array.svg
Type: image/svg+xml
Size: 301695 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20091021/204c032d/attachment-0001.svg