From psychon at znc.in Thu Nov 1 01:15:05 2012
From: psychon at znc.in (Uli Schlachter)
Date: Thu, 01 Nov 2012 09:15:05 +0100
Subject: [cairo] can't render text
In-Reply-To: <1351700231.96517.YahooMailNeo@web171606.mail.ir2.yahoo.com>
References: <1351700231.96517.YahooMailNeo@web171606.mail.ir2.yahoo.com>
Message-ID: <50922F89.3010901@znc.in>
Hi,
On 31.10.2012 17:17, Techie Help wrote:
[...]
> I am using following code:
>
> Please let me know, what I am doing wrong.
>
> cairo_select_font_face (cr, "monospace", CAIRO_FONT_SLANT_NORMAL, CAIRO_FONT_WEIGHT_NORMAl);
>
> cairo_set_font_size (cr, 14);
>
> cairo_set_source_rgb (cr, 0, 0, 0);
>
> cairo_move_to (cr, 0, 50);
>
> cairo_show_text (cr, "Print Something");
>
Let's turn this into a full, self-contained example (attached). When I compile
and run this code, I get a file called "out.png" which shows the text "Print
Something".
So you aren't doing anything wrong.
Uli
--
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
-- Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.c
Type: text/x-csrc
Size: 631 bytes
Desc: not available
URL:
From chris at chris-wilson.co.uk Thu Nov 1 02:53:18 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 01 Nov 2012 09:53:18 +0000
Subject: [cairo] [patch] gl: for embedded device,
we need smaller vbo size
In-Reply-To: <3955FA337689574EB32F94B12A7E6E9E2470CEE6@sisaex01sj>
References: <3955FA337689574EB32F94B12A7E6E9E2470CEE6@sisaex01sj>
Message-ID:
On Thu, 25 Oct 2012 19:27:56 +0000, "Henry (Yu) Song - SISA" wrote:
> From 702b7a6dbba035a1a0c71d3618c1d2b02be0561e Mon Sep 17 00:00:00 2001
> From: Henry Song
> Date: Thu, 25 Oct 2012 12:25:13 -0700
> Subject: [PATCH] 256*1024 is really too big for embedded device to handle
> during glDraw() 16384 to 32768 seems to be the optimal size
> for VBO
I'd rather keep most of these values the same between GL/GLES as the
optimisation constraints should be very similar, so I pushed a modified
patch to make it 16k for everyone until someone can present good
evidence for another value. At which point, they should also consider
how to automatically select the vbo size.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From ed44 at xs4all.nl Fri Nov 2 07:23:39 2012
From: ed44 at xs4all.nl (ed44)
Date: Fri, 02 Nov 2012 15:23:39 +0100
Subject: [cairo] Bug in 1.12.4 and 1.12.6
In-Reply-To:
References: <50914E6C.9070309@xs4all.nl>
Message-ID: <5093D76B.5040706@xs4all.nl>
On 10/31/2012 05:27 PM, Chris Wilson wrote:
> On Wed, 31 Oct 2012 17:14:36 +0100, ed44 wrote:
>> When stroking two or more curves and the path is clipped
>> the result is wrong in some cases.
>>
>> Looks like the second curve is interpreted as a "line_to"
>>
>> Increased linewith will decrease the error.
> See https://bugs.freedesktop.org/show_bug.cgi?id=56574
> -Chris
>
The bug you pointed to is fixed in the git tree.
I just tested and the stroke error is still there.
Ed
From chris at chris-wilson.co.uk Fri Nov 2 07:57:15 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Fri, 02 Nov 2012 14:57:15 +0000
Subject: [cairo] Bug in 1.12.4 and 1.12.6
In-Reply-To: <5093D76B.5040706@xs4all.nl>
References: <50914E6C.9070309@xs4all.nl>
<5093D76B.5040706@xs4all.nl>
Message-ID: <6c3329$71c1k0@orsmga002.jf.intel.com>
On Fri, 02 Nov 2012 15:23:39 +0100, ed44 wrote:
> On 10/31/2012 05:27 PM, Chris Wilson wrote:
> > On Wed, 31 Oct 2012 17:14:36 +0100, ed44 wrote:
> >> When stroking two or more curves and the path is clipped
> >> the result is wrong in some cases.
> >>
> >> Looks like the second curve is interpreted as a "line_to"
> >>
> >> Increased linewith will decrease the error.
> > See https://bugs.freedesktop.org/show_bug.cgi?id=56574
> > -Chris
> >
> The bug you pointed to is fixed in the git tree.
> I just tested and the stroke error is still there.
Sure enough, it was a separate issue and as it turned out a trivial
typo. Thanks for the report and the test case,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From ed44 at xs4all.nl Fri Nov 2 10:25:33 2012
From: ed44 at xs4all.nl (ed44)
Date: Fri, 02 Nov 2012 18:25:33 +0100
Subject: [cairo] Bug in 1.12.4 and 1.12.6 : FIXED (no content)
In-Reply-To: <6c3329$71c1k0@orsmga002.jf.intel.com>
References: <50914E6C.9070309@xs4all.nl>
<5093D76B.5040706@xs4all.nl> <6c3329$71c1k0@orsmga002.jf.intel.com>
Message-ID: <5094020D.90101@xs4all.nl>
(no content)
From chris at chris-wilson.co.uk Sun Nov 4 07:40:51 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Sun, 4 Nov 2012 15:40:51 +0000
Subject: [cairo] cairo release 1.12.8 now available
Message-ID: <20121104154051.GA18864@cantiga.alporthouse.com>
A new cairo release 1.12.8 is now available from:
http://cairographics.org/releases/cairo-1.12.8.tar.xz
which can be verified with:
http://cairographics.org/releases/cairo-1.12.8.tar.xz.sha1
56a10bf3b804367c97734d655c23a9f652d5c297 cairo-1.12.8.tar.xz
http://cairographics.org/releases/cairo-1.12.8.tar.xz.sha1.asc
(signed by Chris Wilson)
Additionally, a git clone of the source tree:
git clone git://git.cairographics.org/git/cairo
will include a signed 1.12.8 tag which points to a commit named:
cc162915a55cc67587677352bd9e389f16117853
which can be verified with:
git verify-tag 1.12.8
and can be checked out with a command such as:
git checkout -b build 1.12.8
Release 1.12.8 (2012-11-24 Chris Wilson )
===================================================================
Another couple of weeks and a few more bugs have been found and fixed,
it is time to push the next point release. Many thanks to everyone who
reported their issues and helped us track down the bugs and helped
testing the fixes.
Bug fixes
---------
Expand the sanity checking for broken combinations of XSendEvent and
ShmCompletionEvent.
Notice that "The X.Org Foundation" sometimes also identifies itself
as "The Xorg Foundation".
Handle various ages of libXext and its Shm headers.
Fix the invalid clipping of the source drawable when using SHM
transport to upload images.
https://bugs.freedesktop.org/show_bug.cgi?id=56547
Handle all Type1 postscript operators for better font compatibility.
https://bugs.freedesktop.org/show_bug.cgi?id=56265
Fix a couple of memory leaks in Type1 font subsetting
https://bugs.freedesktop.org/show_bug.cgi?id=56566
Tighten the evaluation of the start/stop pen vertices, and catch a few
instances where we would use a fan instead of a bevel.
https://bugs.freedesktop.org/show_bug.cgi?id=56432
Fix assumption that geometric clipping always succeeds with the
span-compositor.
https://bugs.freedesktop.org/show_bug.cgi?id=56574
Fix call to spline intersection when evaluating whether a stoke is
visible.
Remember to copy inferior sources when using SHM to readback the
surface for use as a source.
Complete list of changes since 1.12.6
-------------------------------------
Adrian Johnson (5):
type1-subset: parse all operators
type1-subset: restore correct callothersub behavior
type1-subset: ensure subroutine numnber is an integer
type1-subset: fix memory leak
type1-subset: remove unused variable
Chris Wilson (19):
version: Post release bump to 1.12.7
xlib/shm: Sanity check that the server handles XSendEvent with ShmCompletion
xlib: Check for both X.org and Xorg ServerVendors
xlib/shm: Check for XShm headers
xlib/shm: Use shmstr.h instead of shmproto.h if available
xlib: Apply the image offsets to the destination rather the source
pen: First check whether the in/out edges lie within the single pen vertex
xlib/shm: Fix bogus assertion without shm available
image: Add a couple of tracepoints for spans fallbacks
stroke: Precompute the line half-width
util/show-polygon: Show the limited range of each edge
spans: Do not assume that we manage to perform the clip geometrically
xlib: Fixup standalone header compilation for 'make check'
gl: Tune the default VBO size to reduce overhead on embedded devices
pen: Tighten checking for bevel (start==stop) joins
test: Add stroke-clipped
stroke: Fix calling '_cairo_spline_intersect' for in-bounds checking of splines
xlib/shm: Need IncludeInferiors when creating the source fallback
1.12.8 release
Kevin Tardif (1):
type1-subset, cff-subset: Plugged 2 memory leaks
What is cairo
=============
Cairo is a 2D graphics library with support for multiple output
devices. Currently supported output targets include the X Window
System (via both Xlib and XCB), quartz, win32, and image buffers,
as well as PDF, PostScript, and SVG file output. Experimental backends
include OpenGL, BeOS, OS/2, and DirectFB.
Cairo is designed to produce consistent output on all output media
while taking advantage of display hardware acceleration when available
(for example, through the X Render Extension).
The cairo API provides operations similar to the drawing operators of
PostScript and PDF. Operations in cairo include stroking and filling
cubic B?zier splines, transforming and compositing translucent images,
and antialiased text rendering. All drawing operations can be
transformed by any affine transformation (scale, rotation, shear,
etc.).
Cairo has been designed to let you draw anything you want in a modern
2D graphical user interface. At the same time, the cairo API has been
designed to be as fun and easy to learn as possible. If you're not
having fun while programming with cairo, then we have failed
somewhere---let us know and we'll try to fix it next time around.
Cairo is free software and is available to be redistributed and/or
modified under the terms of either the GNU Lesser General Public
License (LGPL) version 2.1 or the Mozilla Public License (MPL) version
1.1.
Where to get more information about cairo
=========================================
The primary source of information about cairo is:
http://cairographics.org/
The latest versions of cairo can always be found at:
http://cairographics.org/download
Documentation on using cairo and frequently-asked questions:
http://cairographics.org/documentation
http://cairographics.org/FAQ
Mailing lists for contacting cairo users and developers:
http://cairographics.org/lists
Roadmap and unscheduled things to do, (please feel free to help out):
http://cairographics.org/roadmap
http://cairographics.org/todo
--
Chris Wilson, Intel Open Source Technology Centre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
From moreau.steve at free.fr Mon Nov 5 07:24:59 2012
From: moreau.steve at free.fr (Steve Moreau)
Date: Mon, 5 Nov 2012 16:24:59 +0100
Subject: [cairo] How to flatten several data surfaces with transparency
Message-ID:
Hi all,
I was playing with cairo to flatten several layers with transparency.
Some of my surfaces are data surface filled by an external lib.
Pixels on these surfaces have distributed alpha values (not only fully
transparent or opaque).
When I dump any surface independently, the transparency seems to be fine.
But as soon as I want to compose them, the transparent values of the top
layer behaves oddly.
I did a lot of tests but the best I could do to explain is the dummy cpp
file attached.
Basically I draw a gradient manually (let's say it is what the external lib
do). So alpha layer is in [0,1]. I want a red square to be behind this
gradient. So I expect the result square not to change on parts where
transparency is near 0.
When line 52 : buf[y*rowLen+x*4+1] = 50;
I see the square but is already altered because it is not its actual color.
When line 52 : buf[y*rowLen+x*4+1] = 255;
I see everything in green and I just can't explain why for now.
I keep on reading the doc to get it, but if someone could explain what
happens and how I could merge/flatten/composite several layers, it would be
nice, because it is a little unclear to me for now.
Thanks,
Steve
PS:
A copy/paste way to compile and run the example :
$ g++ -g -I/usr/include/cairo -o test Dummy.cpp -lpng -lcairo && ./test
A way to see the result :
$ eog test.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dummy.cpp
Type: text/x-c++src
Size: 5000 bytes
Desc: not available
URL:
From emmanuel.pacaud at lapp.in2p3.fr Mon Nov 5 07:52:28 2012
From: emmanuel.pacaud at lapp.in2p3.fr (Emmanuel Pacaud)
Date: Mon, 05 Nov 2012 16:52:28 +0100
Subject: [cairo] How to flatten several data surfaces with transparency
In-Reply-To:
References:
Message-ID: <1352130748.1868.70.camel@lappc-p348.in2p3.fr>
Hi,
Le lundi 05 novembre 2012 ? 16:24 +0100, Steve Moreau a ?crit :
> I was playing with cairo to flatten several layers with transparency.
I don't know if it can solve your issue, but if you alter surface data
by accessing directly the memory buffer, you have to use
cairo_surface_mark_dirty. If you forget this call, cairo may discard
what you have done.
Emmanuel.
From fredbca21 at gmail.com Mon Nov 5 08:13:02 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Mon, 5 Nov 2012 17:13:02 +0100
Subject: [cairo] Cairo crash with a simple stroke (win32)
In-Reply-To: <50900C200200006F00011944@v-pgw-nlx2.p.nwu.ac.za>
References: <50900C200200006F00011944@v-pgw-nlx2.p.nwu.ac.za>
Message-ID:
Hi,
Thank you Martin for your answer. The thing is, it is a feature that a
surface built on a HDC gets the right clipping region. It is indeed
possible to manually overwrite, re-compute and apply the clipping
region to the cairo context, but it is probably better just to fix
cairo and this feature :-). Also, this problem is also probably
occuring in other cases (it is a crash in the compositing functions).
Has anyone found a way to fix it properly?
I'll double check with the new 1.12.8 that has just been released
(there seem to be changes in this area), but it would be great to have
feedback from the experts.
Regards,
Fred.
2012/10/30 Martin Schlemmer :
> Hi,
>
>> After some additionnal debugging, it appears that the raw data pointer
>> (unsigned char *data;) in the destination image surface for the
>> compositor is invalid, hence the crash. I have not been able to find
>> out where this comes from yet (the multiple casts throughout the code
>> does not make easy for a newcomer to track this field in the image
>> surface). All I can say is it is valid when the fallback image for the
>> surface is created, at the beginning of the cairo_stroke call.
>
>> Does anybody have any clue? I feel a bit lonely on this issue :).
>
> I am not sure if its a feature or a bug, but if you remove the bits that sets the Clip Region directly on the HDC, it does not crash.
> I assume that you should rather use:
>
> cairo_rectangle ()
> cairo_clip ()
>
> on the created context.
>
> I could however be incorrect, and that creating a surface from a HDC which already has a Clip Region set directly on the HDC should not give current results - maybe somebody can verify?
>
>
> Regards,
> Martin
>
>
>>2012/10/25 Fred bca21 :
>> Hi,
>>
>> I have just tested with the latest cairo release (1.12.6), and it
>> appears that the issue is still here (crash at the exact same
>> location). Has anyone an idea of how to fix it? Should I maybe post
>> this to the bugs mailing list?
>>
>> Regards,
>>
>> Fred.
>>
>>
>> 2012/10/19 Fred bca21 :
>>> Hi,
>>>
>>> I am new to this list but I have been using cairo and monitoring posts
>>> for a couple of months now. I have a strange issue on windows when the
>>> intersection between the clipping region and the drawing is very
>>> small, so I am posting here with the hope that someone can help (I am
>>> a bit too new to cairo's internals to debug this problem).
>>>
>>> Typically, the simple code below crashes (I am using a DDB bitmap for
>>> the example, but it also crashes with any DC).
>>>
>>> #include "cairo.h"
>>> #include "cairo-win32.h"
>>> #include
>>> {
>>> // build a bitmap (same issue with DIB, whatever the bit depth)
>>> HDC dc=::CreateCompatibleDC(NULL);
>>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>>> ::SelectObject(dc,hBmp);
>>>
>>> // set clip region for the DC to one single line in the middle of the bitmap
>>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>>> SelectClipRgn(dc, hrgn);
>>> ::DeleteObject(hrgn);
>>>
>>> // create cairo context
>>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>>> if(surface)
>>> {
>>> cairo_t* context=cairo_create(surface);
>>> if(context)
>>> {
>>> // draw one line
>>> cairo_move_to(context,1, 1);
>>> cairo_line_to(context,10,120);
>>> cairo_set_source_rgb(context,1,1,1);
>>>
>>> // CRASHES HERE (see below):
>>> cairo_stroke(context);
>>>
>>> // cleanup
>>> cairo_destroy(context);
>>> }
>>> cairo_surface_destroy(surface);
>>> }
>>> }
>>>
>>> The crash occurs in cairo-image-compositor.c, on line 2197, in
>>> _fill_xrgb32_lerp_opaque_spans():
>>>
>>> } else while (len--) {
>>> // On this line below, d has an invalid address
>>> *d = lerp8x4 (r->u.fill.pixel, a, *d);
>>> d++;
>>> }
>>>
>>> If it may help, am using the static lib version of the latest release
>>> (1.12.4 - pixman 26.2), and it crashes in debug or release mode, 32 or
>>> 64-bit windows. It's too bad because this crash occurs all the time in
>>> my code that extensively uses clipping regions!
>>>
>>> This crash also occurs with the previous version of cairo (1.12.2) and
>>> pixman 26.0, but at a different stage (in pixman if I remember well),
>
>
> Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html
>
From spitzak at gmail.com Mon Nov 5 12:10:53 2012
From: spitzak at gmail.com (Bill Spitzak)
Date: Mon, 05 Nov 2012 12:10:53 -0800
Subject: [cairo] How to flatten several data surfaces with transparency
In-Reply-To:
References:
Message-ID: <50981D4D.8080600@gmail.com>
Cairo wants pre-multiplied data for the OVER composite. This likely
means that the green value should depend on y just like the alpha value
does. Ie set the green to (y < 50 ? 0 : 50 * (y - 50)/height)
Also I recommend filling in the buffer as 32-bit words, rather than
bytes. This is faster and will make the it work on a big-endian machine.
unsigned char* buf = (unsigned char*)malloc(4*width*height);
cairo_surface_t* dataSurface = cairo_image_surface_create_for_data
(buf, CAIRO_FORMAT_ARGB32, width, height, rowLen);
for (y=0; y
>From 18e714f260f18e6ae13979a289b6f7892d7f82c2 Mon Sep 17 00:00:00 2001
From: Henry Song
Date: Mon, 5 Nov 2012 13:16:18 -0800
Subject: [PATCH] gl: add tex_width in cairo_gl_gradient_t structure, there is
no need to set cache_entry.size to be tex_width, this makes
it unlikely overflows gradient cache
---
src/cairo-gl-gradient-private.h | 1 +
src/cairo-gl-gradient.c | 3 ++-
src/cairo-gl-operand.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/cairo-gl-gradient-private.h b/src/cairo-gl-gradient-private.h
index 77f9bbd..c76c7b2 100644
--- a/src/cairo-gl-gradient-private.h
+++ b/src/cairo-gl-gradient-private.h
@@ -69,6 +69,7 @@ typedef struct _cairo_gl_gradient {
cairo_reference_count_t ref_count;
cairo_device_t *device; /* NB: we don't hold a reference */
GLuint tex;
+ int tex_width;
unsigned int n_stops;
const cairo_gradient_stop_t *stops;
cairo_gradient_stop_t stops_embedded[1];
diff --git a/src/cairo-gl-gradient.c b/src/cairo-gl-gradient.c
index 1c1f972..3ceb3ed 100644
--- a/src/cairo-gl-gradient.c
+++ b/src/cairo-gl-gradient.c
@@ -258,7 +258,8 @@ _cairo_gl_gradient_create (cairo_gl_context_t *ctx,
CAIRO_REFERENCE_COUNT_INIT (&gradient->ref_count, 2);
gradient->cache_entry.hash = hash;
- gradient->cache_entry.size = tex_width;
+ gradient->cache_entry.size = sizeof (cairo_gl_gradient_t *);
+ gradient->tex_width = tex_width;
gradient->device = &ctx->base;
gradient->n_stops = n_stops;
gradient->stops = gradient->stops_embedded;
diff --git a/src/cairo-gl-operand.c b/src/cairo-gl-operand.c
index ee6c08e..e9191aa 100644
--- a/src/cairo-gl-operand.c
+++ b/src/cairo-gl-operand.c
@@ -686,7 +686,7 @@ _cairo_gl_operand_bind_to_shader (cairo_gl_context_t *ctx,
height = operand->texture.surface->height;
}
else {
- width = operand->gradient.gradient->cache_entry.size,
+ width = operand->gradient.gradient->tex_width,
height = 1;
}
strcpy (custom_part, "_texdims");
--
1.7.9.5
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From chris at chris-wilson.co.uk Mon Nov 5 13:39:00 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Mon, 05 Nov 2012 21:39:00 +0000
Subject: [cairo] [patch] gl: set tex_with in cairo_gl_gradient_t instead
in cairo_entry.size
In-Reply-To: <3955FA337689574EB32F94B12A7E6E9E2482E538@sisaex01sj>
References: <3955FA337689574EB32F94B12A7E6E9E2482E538@sisaex01sj>
Message-ID:
On Mon, 5 Nov 2012 21:28:31 +0000, "Henry (Yu) Song - SISA" wrote:
> From 18e714f260f18e6ae13979a289b6f7892d7f82c2 Mon Sep 17 00:00:00 2001
> From: Henry Song
> Date: Mon, 5 Nov 2012 13:16:18 -0800
> Subject: [PATCH] gl: add tex_width in cairo_gl_gradient_t structure, there is
> no need to set cache_entry.size to be tex_width, this makes
> it unlikely overflows gradient cache
The idea is that the gradient cache tries to only keep a certain amount
of texture memory cached. It sounds like that limit is too low --
indeed, it is set at 4096 which is only 16k, or roughly 4 gradients.
That would be better with
#define CAIRO_GL_GRADIENT_CACHE_SIZE 16384
judging by desktop usage, and you probably have a better idea for your
use cases.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From hsong at sisa.samsung.com Mon Nov 5 17:34:25 2012
From: hsong at sisa.samsung.com (Henry (Yu) Song - SISA)
Date: Tue, 6 Nov 2012 01:34:25 +0000
Subject: [cairo] [patch] gl: set tex_with in cairo_gl_gradient_t
instead in cairo_entry.size
In-Reply-To:
References: <3955FA337689574EB32F94B12A7E6E9E2482E538@sisaex01sj>,
Message-ID: <3955FA337689574EB32F94B12A7E6E9E24830628@sisaex01sj>
Hi, Chris
I am not sure why cache_entry.size has to be the tex_width. It seems that tex_width has no relation with cache_entry.size. In my patch, the cache_entry.size is set at 4, which allows 1024 gradient cached.
if CAIRO_GL_GRADIENT_CACHE_SIZE = 16384, and let's assume each tex_with is about 64, that is only 256 gradient cache.
The gradient cache should not be limited by system memory, it should, I think, be limited by the GPU memory, because each texture is 1 pixel height, and even, in worst case, each tex_width is 1024, 1024 gradient cache is 4 M (1024x1024x4 (RGBA)) bytes. - that should be OK, I think
Please comments
Thanks
________________________________________
From: cairo-bounces+henry.song=samsung.com at cairographics.org [cairo-bounces+henry.song=samsung.com at cairographics.org] on behalf of Chris Wilson [chris at chris-wilson.co.uk]
Sent: Monday, November 05, 2012 1:39 PM
To: Henry (Yu) Song - SISA; cairo at cairographics.org
Subject: Re: [cairo] [patch] gl: set tex_with in cairo_gl_gradient_t instead in cairo_entry.size
On Mon, 5 Nov 2012 21:28:31 +0000, "Henry (Yu) Song - SISA" wrote:
> From 18e714f260f18e6ae13979a289b6f7892d7f82c2 Mon Sep 17 00:00:00 2001
> From: Henry Song
> Date: Mon, 5 Nov 2012 13:16:18 -0800
> Subject: [PATCH] gl: add tex_width in cairo_gl_gradient_t structure, there is
> no need to set cache_entry.size to be tex_width, this makes
> it unlikely overflows gradient cache
The idea is that the gradient cache tries to only keep a certain amount
of texture memory cached. It sounds like that limit is too low --
indeed, it is set at 4096 which is only 16k, or roughly 4 gradients.
That would be better with
#define CAIRO_GL_GRADIENT_CACHE_SIZE 16384
judging by desktop usage, and you probably have a better idea for your
use cases.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
cairo mailing list
cairo at cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo
From chris at chris-wilson.co.uk Mon Nov 5 21:48:08 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 06 Nov 2012 05:48:08 +0000
Subject: [cairo] [patch] gl: set tex_with in cairo_gl_gradient_t instead
in cairo_entry.size
In-Reply-To: <3955FA337689574EB32F94B12A7E6E9E24830628@sisaex01sj>
References: <3955FA337689574EB32F94B12A7E6E9E2482E538@sisaex01sj>,
<3955FA337689574EB32F94B12A7E6E9E24830628@sisaex01sj>
Message-ID: <84c8a8$6dlet0@orsmga001.jf.intel.com>
On Tue, 6 Nov 2012 01:34:25 +0000, "Henry (Yu) Song - SISA" wrote:
> Hi, Chris
>
> I am not sure why cache_entry.size has to be the tex_width. It seems that tex_width has no relation with cache_entry.size. In my patch, the cache_entry.size is set at 4, which allows 1024 gradient cached.
>
> if CAIRO_GL_GRADIENT_CACHE_SIZE = 16384, and let's assume each tex_with is about 64, that is only 256 gradient cache.
>
>
> The gradient cache should not be limited by system memory, it should, I think, be limited by the GPU memory, because each texture is 1 pixel height, and even, in worst case, each tex_width is 1024, 1024 gradient cache is 4 M (1024x1024x4 (RGBA)) bytes. - that should be OK, I think
Exactly. The limit we want to express upon the cache should be measured
in bytes (or a multiple thereof) and so cache_entry.size should also be
an estimate of how much GPU memory will be consumed by that entry. Then
the cache is able to reap entries to keep its overall GPU memory usage
within the limit. Since the gradients were of variable width but fixed
height, using the width was a reasonable approximation to the amount of
GPU memory required to store it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From moreau.steve at free.fr Mon Nov 5 22:06:53 2012
From: moreau.steve at free.fr (Steve Moreau)
Date: Tue, 6 Nov 2012 07:06:53 +0100
Subject: [cairo] How to flatten several data surfaces with transparency
In-Reply-To: <50981D4D.8080600@gmail.com>
References:
<50981D4D.8080600@gmail.com>
Message-ID:
Thank you guys,
I will try and let you know when it works.
Regards,
Steve
2012/11/5 Bill Spitzak
> Cairo wants pre-multiplied data for the OVER composite. This likely means
> that the green value should depend on y just like the alpha value does. Ie
> set the green to (y < 50 ? 0 : 50 * (y - 50)/height)
>
> Also I recommend filling in the buffer as 32-bit words, rather than bytes.
> This is faster and will make the it work on a big-endian machine.
>
> unsigned char* buf = (unsigned char*)malloc(4*width*height);
> cairo_surface_t* dataSurface = cairo_image_surface_create_**for_data
> (buf, CAIRO_FORMAT_ARGB32, width, height, rowLen);
> for (y=0; y {
> for (x=0; x {
> //setColor(&buf[y*rowLen+x*4], 0x00FF00, y*255.0/3/height);
> buf[y*rowLen+x*4+0] = 0;
> buf[y*rowLen+x*4+1] = 50;
> buf[y*rowLen+x*4+2] = 0;
> buf[y*rowLen+x*4+3] = (y < 50 ? 0 : (y-50)*255.0/height);
> }
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From moreau.steve at free.fr Mon Nov 5 23:37:16 2012
From: moreau.steve at free.fr (Steve Moreau)
Date: Tue, 6 Nov 2012 08:37:16 +0100
Subject: [cairo] How to flatten several data surfaces with transparency
In-Reply-To:
References:
<50981D4D.8080600@gmail.com>
Message-ID:
Hi all,
Thanks for all inputs.
I remember I tested the byte ordering manually so in this case that was not
the problem (even it was not platform independent code I agree).
Here the issue seems to be the problem raised by behdad in Carlos' thread :
http://lists.freedesktop.org/archives/cairo/2012-July/023298.html
* @CAIRO_FORMAT_ARGB32: each pixel is a 32-bit quantity, with
* alpha in the upper 8 bits, then red, then green, then blue.
* The 32-bit quantities are stored native-endian. *Pre-multiplied
* alpha is used. (That is, 50% transparent red is 0x80800000,
* not 0x80ff0000.) (Since 1.0)*
So I had to level the r, g, and b values to "alpha" maximum.
In other words, I understood that r or g or b should never be greater than
the matching opacity value.
For anyone interested, please find below how I interpreted it (for now).
Thanks,
Steve
void setColor(unsigned char* pixel, unsigned int color, unsigned char
opacity = 0xFF)
{
unsigned char r = (color >> 16) & 0xFF;
unsigned char g = (color >> 8) & 0xFF;
unsigned char b = (color) & 0xFF;
r = r*opacity/255;
g = g*opacity/255;
b = b*opacity/255;
*((unsigned int*) pixel) = opacity << 24 | r << 16 | g << 8 | b;
}
2012/11/6 Steve Moreau
> Thank you guys,
>
> I will try and let you know when it works.
> Regards,
>
> Steve
>
>
> 2012/11/5 Bill Spitzak
>
>> Cairo wants pre-multiplied data for the OVER composite. This likely means
>> that the green value should depend on y just like the alpha value does. Ie
>> set the green to (y < 50 ? 0 : 50 * (y - 50)/height)
>>
>> Also I recommend filling in the buffer as 32-bit words, rather than
>> bytes. This is faster and will make the it work on a big-endian machine.
>>
>> unsigned char* buf = (unsigned char*)malloc(4*width*height);
>> cairo_surface_t* dataSurface = cairo_image_surface_create_**for_data
>> (buf, CAIRO_FORMAT_ARGB32, width, height, rowLen);
>> for (y=0; y> {
>> for (x=0; x> {
>> //setColor(&buf[y*rowLen+x*4], 0x00FF00, y*255.0/3/height);
>> buf[y*rowLen+x*4+0] = 0;
>> buf[y*rowLen+x*4+1] = 50;
>> buf[y*rowLen+x*4+2] = 0;
>> buf[y*rowLen+x*4+3] = (y < 50 ? 0 : (y-50)*255.0/height);
>> }
>> }
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From moreau.steve at free.fr Tue Nov 6 02:50:59 2012
From: moreau.steve at free.fr (Steve Moreau)
Date: Tue, 6 Nov 2012 11:50:59 +0100
Subject: [cairo] Fwd: New example to illustrate data buffer manipulation
In-Reply-To:
References:
Message-ID:
Hi all,
Following the question I asked here :
http://lists.freedesktop.org/archives/cairo/2012-November/023716.html, I
tried to make an example to illustrate :
- several layers flattening with transparency
- direct data buffer manipulation
As far I know, there is no example to do that (
http://cairographics.org/samples/ ?), so feel free to made it available if
you think it could help someone.
$ gcc -Wall -I/usr/include/cairo -o DirectBufferManipulation
DirectBufferManipulation.c -lcairo && ./DirectBufferManipulation
or
$ gcc -Wall `pkg-config --cflags cairo` -o DirectBufferManipulation
DirectBufferManipulation.c `pkg-config --libs cairo` &&
./DirectBufferManipulation
See you,
Steve
[image: Images int?gr?es 3]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2137 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DirectBufferManipulation.c
Type: text/x-csrc
Size: 2315 bytes
Desc: not available
URL:
From fredbca21 at gmail.com Wed Nov 7 02:06:29 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Wed, 7 Nov 2012 11:06:29 +0100
Subject: [cairo] Cairo crash with a simple stroke (win32)
In-Reply-To:
References: <50900C200200006F00011944@v-pgw-nlx2.p.nwu.ac.za>
Message-ID:
Hi,
No surprise: the issue is still here in 1.12.8. Running the code below
crashes in _fill_xrgb32_lerp_opaque_spans.
If anyone can give me an idea of how to get started on debugging this,
I'd be glad to help fixing this problem. I have already spent some
time on it, but it's pretty hard to understand where the composite
destination data pointer is changed without not much knowledge of the
cairo code.
Just wondering: why isn't there much interest for this problem?
Thanks!
Fred.
{
// build a bitmap (same issue with DIB, whatever the bit depth)
HDC dc=::CreateCompatibleDC(NULL);
HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
::SelectObject(dc,hBmp);
// set clip region for the DC to one single line in the middle of the bitmap
HRGN hrgn = CreateRectRgn(0,100,100, 101);
SelectClipRgn(dc, hrgn);
::DeleteObject(hrgn);
// create cairo context
cairo_surface_t* surface=cairo_win32_surface_create(dc);
if(surface)
{
cairo_t* context=cairo_create(surface);
if(context)
{
// draw one line
cairo_move_to(context,1, 1);
cairo_line_to(context,10,120);
cairo_set_source_rgb(context,1,1,1);
// CRASHES HERE:
cairo_stroke(context);
// cleanup
cairo_destroy(context);
}
cairo_surface_destroy(surface);
}
}
2012/11/5 Fred bca21 :
> Hi,
>
> Thank you Martin for your answer. The thing is, it is a feature that a
> surface built on a HDC gets the right clipping region. It is indeed
> possible to manually overwrite, re-compute and apply the clipping
> region to the cairo context, but it is probably better just to fix
> cairo and this feature :-). Also, this problem is also probably
> occuring in other cases (it is a crash in the compositing functions).
>
> Has anyone found a way to fix it properly?
>
> I'll double check with the new 1.12.8 that has just been released
> (there seem to be changes in this area), but it would be great to have
> feedback from the experts.
>
> Regards,
>
> Fred.
>
>
> 2012/10/30 Martin Schlemmer :
>> Hi,
>>
>>> After some additionnal debugging, it appears that the raw data pointer
>>> (unsigned char *data;) in the destination image surface for the
>>> compositor is invalid, hence the crash. I have not been able to find
>>> out where this comes from yet (the multiple casts throughout the code
>>> does not make easy for a newcomer to track this field in the image
>>> surface). All I can say is it is valid when the fallback image for the
>>> surface is created, at the beginning of the cairo_stroke call.
>>
>>> Does anybody have any clue? I feel a bit lonely on this issue :).
>>
>> I am not sure if its a feature or a bug, but if you remove the bits that sets the Clip Region directly on the HDC, it does not crash.
>> I assume that you should rather use:
>>
>> cairo_rectangle ()
>> cairo_clip ()
>>
>> on the created context.
>>
>> I could however be incorrect, and that creating a surface from a HDC which already has a Clip Region set directly on the HDC should not give current results - maybe somebody can verify?
>>
>>
>> Regards,
>> Martin
>>
>>
>>>2012/10/25 Fred bca21 :
>>> Hi,
>>>
>>> I have just tested with the latest cairo release (1.12.6), and it
>>> appears that the issue is still here (crash at the exact same
>>> location). Has anyone an idea of how to fix it? Should I maybe post
>>> this to the bugs mailing list?
>>>
>>> Regards,
>>>
>>> Fred.
>>>
>>>
>>> 2012/10/19 Fred bca21 :
>>>> Hi,
>>>>
>>>> I am new to this list but I have been using cairo and monitoring posts
>>>> for a couple of months now. I have a strange issue on windows when the
>>>> intersection between the clipping region and the drawing is very
>>>> small, so I am posting here with the hope that someone can help (I am
>>>> a bit too new to cairo's internals to debug this problem).
>>>>
>>>> Typically, the simple code below crashes (I am using a DDB bitmap for
>>>> the example, but it also crashes with any DC).
>>>>
>>>> #include "cairo.h"
>>>> #include "cairo-win32.h"
>>>> #include
>>>> {
>>>> // build a bitmap (same issue with DIB, whatever the bit depth)
>>>> HDC dc=::CreateCompatibleDC(NULL);
>>>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>>>> ::SelectObject(dc,hBmp);
>>>>
>>>> // set clip region for the DC to one single line in the middle of the bitmap
>>>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>>>> SelectClipRgn(dc, hrgn);
>>>> ::DeleteObject(hrgn);
>>>>
>>>> // create cairo context
>>>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>>>> if(surface)
>>>> {
>>>> cairo_t* context=cairo_create(surface);
>>>> if(context)
>>>> {
>>>> // draw one line
>>>> cairo_move_to(context,1, 1);
>>>> cairo_line_to(context,10,120);
>>>> cairo_set_source_rgb(context,1,1,1);
>>>>
>>>> // CRASHES HERE (see below):
>>>> cairo_stroke(context);
>>>>
>>>> // cleanup
>>>> cairo_destroy(context);
>>>> }
>>>> cairo_surface_destroy(surface);
>>>> }
>>>> }
>>>>
>>>> The crash occurs in cairo-image-compositor.c, on line 2197, in
>>>> _fill_xrgb32_lerp_opaque_spans():
>>>>
>>>> } else while (len--) {
>>>> // On this line below, d has an invalid address
>>>> *d = lerp8x4 (r->u.fill.pixel, a, *d);
>>>> d++;
>>>> }
>>>>
>>>> If it may help, am using the static lib version of the latest release
>>>> (1.12.4 - pixman 26.2), and it crashes in debug or release mode, 32 or
>>>> 64-bit windows. It's too bad because this crash occurs all the time in
>>>> my code that extensively uses clipping regions!
>>>>
>>>> This crash also occurs with the previous version of cairo (1.12.2) and
>>>> pixman 26.0, but at a different stage (in pixman if I remember well),
>>
>>
>> Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html
>>
From fredbca21 at gmail.com Wed Nov 7 04:56:01 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Wed, 7 Nov 2012 13:56:01 +0100
Subject: [cairo] Cairo crash with a simple stroke (win32)
In-Reply-To:
References: <50900C200200006F00011944@v-pgw-nlx2.p.nwu.ac.za>
Message-ID:
Hi Again,
It appears that the bug seems to happen because the extents of the
fallback image has an offset in its origin.
when performing the mapping of the surface to an image, in
cairo-win32-display-surface.c, on line 467:
return _cairo_image_surface_map_to_image (surface->image, extents);
this actually creates a pixman image with an invalid pointer, that is
supposed to be compensated by the device transform, as you can see in
cairo-image-surface.c on line 805:
uint8_t *data;
data = other->data;
data += extents->y * other->stride; // THIS POINTER IS OUTSIDE OF
THE ACTUAL IMAGE (the image is created with the actual extent, not the
entire surface extent)
data += extents->x * PIXMAN_FORMAT_BPP (other->pixman_format)/ 8;
surface =_cairo_image_surface_create_with_pixman_format (data,
other->pixman_format,
extents->width,
extents->height,
other->stride);
cairo_surface_set_device_offset (surface, -extents->x,
-extents->y); /// THIS IS SUPPOSED TO COMPENSATE THE OFFSET ABOVE
return surface;
But in the end, when reaching the _fill_xrgb32_lerp_opaque_spans
function, the data pointer is still the wrong one (as offset in the
function above, not compensated by the device transform).
So either the device transform should be applied at some point and it
is not, or the mapping of the image is wrong and should not use the
origin of the extents,
That's all I can do for now with my imited knowledge, but I hope it
helps a little bit and maybe this will motivate someone to check this
out.
Regards,
Fred.
2012/11/7 Fred bca21 :
> Hi,
>
> No surprise: the issue is still here in 1.12.8. Running the code below
> crashes in _fill_xrgb32_lerp_opaque_spans.
>
> If anyone can give me an idea of how to get started on debugging this,
> I'd be glad to help fixing this problem. I have already spent some
> time on it, but it's pretty hard to understand where the composite
> destination data pointer is changed without not much knowledge of the
> cairo code.
>
> Just wondering: why isn't there much interest for this problem?
>
> Thanks!
>
> Fred.
>
> {
> // build a bitmap (same issue with DIB, whatever the bit depth)
> HDC dc=::CreateCompatibleDC(NULL);
> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
> ::SelectObject(dc,hBmp);
>
> // set clip region for the DC to one single line in the middle of the bitmap
> HRGN hrgn = CreateRectRgn(0,100,100, 101);
> SelectClipRgn(dc, hrgn);
> ::DeleteObject(hrgn);
>
> // create cairo context
> cairo_surface_t* surface=cairo_win32_surface_create(dc);
> if(surface)
> {
> cairo_t* context=cairo_create(surface);
> if(context)
> {
> // draw one line
> cairo_move_to(context,1, 1);
> cairo_line_to(context,10,120);
> cairo_set_source_rgb(context,1,1,1);
>
> // CRASHES HERE:
> cairo_stroke(context);
>
> // cleanup
> cairo_destroy(context);
> }
> cairo_surface_destroy(surface);
> }
> }
>
> 2012/11/5 Fred bca21 :
>> Hi,
>>
>> Thank you Martin for your answer. The thing is, it is a feature that a
>> surface built on a HDC gets the right clipping region. It is indeed
>> possible to manually overwrite, re-compute and apply the clipping
>> region to the cairo context, but it is probably better just to fix
>> cairo and this feature :-). Also, this problem is also probably
>> occuring in other cases (it is a crash in the compositing functions).
>>
>> Has anyone found a way to fix it properly?
>>
>> I'll double check with the new 1.12.8 that has just been released
>> (there seem to be changes in this area), but it would be great to have
>> feedback from the experts.
>>
>> Regards,
>>
>> Fred.
>>
>>
>> 2012/10/30 Martin Schlemmer :
>>> Hi,
>>>
>>>> After some additionnal debugging, it appears that the raw data pointer
>>>> (unsigned char *data;) in the destination image surface for the
>>>> compositor is invalid, hence the crash. I have not been able to find
>>>> out where this comes from yet (the multiple casts throughout the code
>>>> does not make easy for a newcomer to track this field in the image
>>>> surface). All I can say is it is valid when the fallback image for the
>>>> surface is created, at the beginning of the cairo_stroke call.
>>>
>>>> Does anybody have any clue? I feel a bit lonely on this issue :).
>>>
>>> I am not sure if its a feature or a bug, but if you remove the bits that sets the Clip Region directly on the HDC, it does not crash.
>>> I assume that you should rather use:
>>>
>>> cairo_rectangle ()
>>> cairo_clip ()
>>>
>>> on the created context.
>>>
>>> I could however be incorrect, and that creating a surface from a HDC which already has a Clip Region set directly on the HDC should not give current results - maybe somebody can verify?
>>>
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>>>2012/10/25 Fred bca21 :
>>>> Hi,
>>>>
>>>> I have just tested with the latest cairo release (1.12.6), and it
>>>> appears that the issue is still here (crash at the exact same
>>>> location). Has anyone an idea of how to fix it? Should I maybe post
>>>> this to the bugs mailing list?
>>>>
>>>> Regards,
>>>>
>>>> Fred.
>>>>
>>>>
>>>> 2012/10/19 Fred bca21 :
>>>>> Hi,
>>>>>
>>>>> I am new to this list but I have been using cairo and monitoring posts
>>>>> for a couple of months now. I have a strange issue on windows when the
>>>>> intersection between the clipping region and the drawing is very
>>>>> small, so I am posting here with the hope that someone can help (I am
>>>>> a bit too new to cairo's internals to debug this problem).
>>>>>
>>>>> Typically, the simple code below crashes (I am using a DDB bitmap for
>>>>> the example, but it also crashes with any DC).
>>>>>
>>>>> #include "cairo.h"
>>>>> #include "cairo-win32.h"
>>>>> #include
>>>>> {
>>>>> // build a bitmap (same issue with DIB, whatever the bit depth)
>>>>> HDC dc=::CreateCompatibleDC(NULL);
>>>>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>>>>> ::SelectObject(dc,hBmp);
>>>>>
>>>>> // set clip region for the DC to one single line in the middle of the bitmap
>>>>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>>>>> SelectClipRgn(dc, hrgn);
>>>>> ::DeleteObject(hrgn);
>>>>>
>>>>> // create cairo context
>>>>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>>>>> if(surface)
>>>>> {
>>>>> cairo_t* context=cairo_create(surface);
>>>>> if(context)
>>>>> {
>>>>> // draw one line
>>>>> cairo_move_to(context,1, 1);
>>>>> cairo_line_to(context,10,120);
>>>>> cairo_set_source_rgb(context,1,1,1);
>>>>>
>>>>> // CRASHES HERE (see below):
>>>>> cairo_stroke(context);
>>>>>
>>>>> // cleanup
>>>>> cairo_destroy(context);
>>>>> }
>>>>> cairo_surface_destroy(surface);
>>>>> }
>>>>> }
>>>>>
>>>>> The crash occurs in cairo-image-compositor.c, on line 2197, in
>>>>> _fill_xrgb32_lerp_opaque_spans():
>>>>>
>>>>> } else while (len--) {
>>>>> // On this line below, d has an invalid address
>>>>> *d = lerp8x4 (r->u.fill.pixel, a, *d);
>>>>> d++;
>>>>> }
>>>>>
>>>>> If it may help, am using the static lib version of the latest release
>>>>> (1.12.4 - pixman 26.2), and it crashes in debug or release mode, 32 or
>>>>> 64-bit windows. It's too bad because this crash occurs all the time in
>>>>> my code that extensively uses clipping regions!
>>>>>
>>>>> This crash also occurs with the previous version of cairo (1.12.2) and
>>>>> pixman 26.0, but at a different stage (in pixman if I remember well),
>>>
>>>
>>> Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html
>>>
From fredbca21 at gmail.com Wed Nov 7 06:13:56 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Wed, 7 Nov 2012 15:13:56 +0100
Subject: [cairo] Cairo crash with a simple stroke (win32) - PATCH
proposal
Message-ID:
Hi,
Does the patch below make sense to you? It seems the extent should
just be offset to the origin when mapping the win32 surface to an
image, since the image is already created at the right location. I
have not been able to make extensive tests yet, but can someone review
this patch?
BTW, is there any way to build and run the tests on windows? Neither
the configure nor the Makefile.Win32 method work on my system.
Index: src/win32/cairo-win32-display-surface.c
===================================================================
--- src/win32/cairo-win32-display-surface.c
+++ src/win32/cairo-win32-display-surface.c
@@ -464,8 +464,16 @@
surface = to_win32_display_surface (surface->fallback);
done:
GdiFlush();
- return _cairo_image_surface_map_to_image (surface->image, extents);
+ // since the image built above is already offset at the right
position, create the image at 0,0.
+ {
+ cairo_rectangle_int_t r;
+ r.x=0;
+ r.y=0;
+ r.width=extents->width;
+ r.height=extents->height;
+ return _cairo_image_surface_map_to_image (surface->image, &r);
+ }
err:
cairo_surface_destroy (surface->fallback);
surface->fallback = NULL;
2012/11/7 Fred bca21 :
> Hi Again,
>
> It appears that the bug seems to happen because the extents of the
> fallback image has an offset in its origin.
> when performing the mapping of the surface to an image, in
> cairo-win32-display-surface.c, on line 467:
> return _cairo_image_surface_map_to_image (surface->image, extents);
>
> this actually creates a pixman image with an invalid pointer, that is
> supposed to be compensated by the device transform, as you can see in
> cairo-image-surface.c on line 805:
> uint8_t *data;
>
> data = other->data;
> data += extents->y * other->stride; // THIS POINTER IS OUTSIDE OF
> THE ACTUAL IMAGE (the image is created with the actual extent, not the
> entire surface extent)
> data += extents->x * PIXMAN_FORMAT_BPP (other->pixman_format)/ 8;
>
> surface =_cairo_image_surface_create_with_pixman_format (data,
> other->pixman_format,
> extents->width,
> extents->height,
> other->stride);
>
> cairo_surface_set_device_offset (surface, -extents->x,
> -extents->y); /// THIS IS SUPPOSED TO COMPENSATE THE OFFSET ABOVE
> return surface;
>
> But in the end, when reaching the _fill_xrgb32_lerp_opaque_spans
> function, the data pointer is still the wrong one (as offset in the
> function above, not compensated by the device transform).
>
> So either the device transform should be applied at some point and it
> is not, or the mapping of the image is wrong and should not use the
> origin of the extents,
>
> That's all I can do for now with my imited knowledge, but I hope it
> helps a little bit and maybe this will motivate someone to check this
> out.
>
> Regards,
>
> Fred.
>
> 2012/11/7 Fred bca21 :
>> Hi,
>>
>> No surprise: the issue is still here in 1.12.8. Running the code below
>> crashes in _fill_xrgb32_lerp_opaque_spans.
>>
>> If anyone can give me an idea of how to get started on debugging this,
>> I'd be glad to help fixing this problem. I have already spent some
>> time on it, but it's pretty hard to understand where the composite
>> destination data pointer is changed without not much knowledge of the
>> cairo code.
>>
>> Just wondering: why isn't there much interest for this problem?
>>
>> Thanks!
>>
>> Fred.
>>
>> {
>> // build a bitmap (same issue with DIB, whatever the bit depth)
>> HDC dc=::CreateCompatibleDC(NULL);
>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>> ::SelectObject(dc,hBmp);
>>
>> // set clip region for the DC to one single line in the middle of the bitmap
>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>> SelectClipRgn(dc, hrgn);
>> ::DeleteObject(hrgn);
>>
>> // create cairo context
>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>> if(surface)
>> {
>> cairo_t* context=cairo_create(surface);
>> if(context)
>> {
>> // draw one line
>> cairo_move_to(context,1, 1);
>> cairo_line_to(context,10,120);
>> cairo_set_source_rgb(context,1,1,1);
>>
>> // CRASHES HERE:
>> cairo_stroke(context);
>>
>> // cleanup
>> cairo_destroy(context);
>> }
>> cairo_surface_destroy(surface);
>> }
>> }
>>
>> 2012/11/5 Fred bca21 :
>>> Hi,
>>>
>>> Thank you Martin for your answer. The thing is, it is a feature that a
>>> surface built on a HDC gets the right clipping region. It is indeed
>>> possible to manually overwrite, re-compute and apply the clipping
>>> region to the cairo context, but it is probably better just to fix
>>> cairo and this feature :-). Also, this problem is also probably
>>> occuring in other cases (it is a crash in the compositing functions).
>>>
>>> Has anyone found a way to fix it properly?
>>>
>>> I'll double check with the new 1.12.8 that has just been released
>>> (there seem to be changes in this area), but it would be great to have
>>> feedback from the experts.
>>>
>>> Regards,
>>>
>>> Fred.
>>>
>>>
>>> 2012/10/30 Martin Schlemmer :
>>>> Hi,
>>>>
>>>>> After some additionnal debugging, it appears that the raw data pointer
>>>>> (unsigned char *data;) in the destination image surface for the
>>>>> compositor is invalid, hence the crash. I have not been able to find
>>>>> out where this comes from yet (the multiple casts throughout the code
>>>>> does not make easy for a newcomer to track this field in the image
>>>>> surface). All I can say is it is valid when the fallback image for the
>>>>> surface is created, at the beginning of the cairo_stroke call.
>>>>
>>>>> Does anybody have any clue? I feel a bit lonely on this issue :).
>>>>
>>>> I am not sure if its a feature or a bug, but if you remove the bits that sets the Clip Region directly on the HDC, it does not crash.
>>>> I assume that you should rather use:
>>>>
>>>> cairo_rectangle ()
>>>> cairo_clip ()
>>>>
>>>> on the created context.
>>>>
>>>> I could however be incorrect, and that creating a surface from a HDC which already has a Clip Region set directly on the HDC should not give current results - maybe somebody can verify?
>>>>
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>>>
>>>>>2012/10/25 Fred bca21 :
>>>>> Hi,
>>>>>
>>>>> I have just tested with the latest cairo release (1.12.6), and it
>>>>> appears that the issue is still here (crash at the exact same
>>>>> location). Has anyone an idea of how to fix it? Should I maybe post
>>>>> this to the bugs mailing list?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Fred.
>>>>>
>>>>>
>>>>> 2012/10/19 Fred bca21 :
>>>>>> Hi,
>>>>>>
>>>>>> I am new to this list but I have been using cairo and monitoring posts
>>>>>> for a couple of months now. I have a strange issue on windows when the
>>>>>> intersection between the clipping region and the drawing is very
>>>>>> small, so I am posting here with the hope that someone can help (I am
>>>>>> a bit too new to cairo's internals to debug this problem).
>>>>>>
>>>>>> Typically, the simple code below crashes (I am using a DDB bitmap for
>>>>>> the example, but it also crashes with any DC).
>>>>>>
>>>>>> #include "cairo.h"
>>>>>> #include "cairo-win32.h"
>>>>>> #include
>>>>>> {
>>>>>> // build a bitmap (same issue with DIB, whatever the bit depth)
>>>>>> HDC dc=::CreateCompatibleDC(NULL);
>>>>>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>>>>>> ::SelectObject(dc,hBmp);
>>>>>>
>>>>>> // set clip region for the DC to one single line in the middle of the bitmap
>>>>>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>>>>>> SelectClipRgn(dc, hrgn);
>>>>>> ::DeleteObject(hrgn);
>>>>>>
>>>>>> // create cairo context
>>>>>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>>>>>> if(surface)
>>>>>> {
>>>>>> cairo_t* context=cairo_create(surface);
>>>>>> if(context)
>>>>>> {
>>>>>> // draw one line
>>>>>> cairo_move_to(context,1, 1);
>>>>>> cairo_line_to(context,10,120);
>>>>>> cairo_set_source_rgb(context,1,1,1);
>>>>>>
>>>>>> // CRASHES HERE (see below):
>>>>>> cairo_stroke(context);
>>>>>>
>>>>>> // cleanup
>>>>>> cairo_destroy(context);
>>>>>> }
>>>>>> cairo_surface_destroy(surface);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The crash occurs in cairo-image-compositor.c, on line 2197, in
>>>>>> _fill_xrgb32_lerp_opaque_spans():
>>>>>>
>>>>>> } else while (len--) {
>>>>>> // On this line below, d has an invalid address
>>>>>> *d = lerp8x4 (r->u.fill.pixel, a, *d);
>>>>>> d++;
>>>>>> }
>>>>>>
>>>>>> If it may help, am using the static lib version of the latest release
>>>>>> (1.12.4 - pixman 26.2), and it crashes in debug or release mode, 32 or
>>>>>> 64-bit windows. It's too bad because this crash occurs all the time in
>>>>>> my code that extensively uses clipping regions!
>>>>>>
>>>>>> This crash also occurs with the previous version of cairo (1.12.2) and
>>>>>> pixman 26.0, but at a different stage (in pixman if I remember well),
>>>>
>>>>
>>>> Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html
>>>>
From sandmann at cs.au.dk Wed Nov 7 11:09:44 2012
From: sandmann at cs.au.dk (=?utf-8?Q?S=C3=B8ren?= Sandmann)
Date: Wed, 07 Nov 2012 20:09:44 +0100
Subject: [cairo] [cairo-announce] [ANNOUNCE] pixman major release 0.28.0
now available
Message-ID:
A new major release 0.28.0 of the pixman rendering library is now
available. Highlights of this release:
* Support for sRGB coded images [Antti Lankila]
* New API for fast glyph rendering [Soren Sandmann]
* Faster bilinear scaling on iwMMX, Loongson and MMX [Matt Turner]
* More fast paths in the MIPS DSPr2 backend [Nemanja Lukic]
* Faster scaling in general and on SSE2 in particular [Siarhei
Siamashka]
Please send bug reports to pixman at lists.freedesktop.org or file them at
https://bugs.freedesktop.org/enter_bug.cgi?product=pixman
Thanks,
Soren
tar.gz:
http://cairographics.org/releases/pixman-0.28.0.tar.gz
http://xorg.freedesktop.org/archive/individual/lib/pixman-0.28.0.tar.gz
tar.bz2:
http://xorg.freedesktop.org/archive/individual/lib/pixman-0.28.0.tar.bz2
Hashes:
MD5: 0554c354aed2d7845180f310a9a15f20 pixman-0.28.0.tar.gz
MD5: 703c3f62437b161c610056e076560570 pixman-0.28.0.tar.bz2
SHA1: 79828c1a69b459c8cc7d468dd09e2b11ecdc9c19 pixman-0.28.0.tar.gz
SHA1: cfc7a18a8811bf4ff0890f547c315bda8097f6ad pixman-0.28.0.tar.bz2
GPG signature:
http://cairographics.org/releases/pixman-0.28.0.tar.gz.sha1.asc
(signed by S?ren Sandmann Pedersen
Git:
git://git.freedesktop.org/git/pixman
tag: pixman-0.28.0
Log:
Andrea Canciani (3):
build: Fix compilation on win32
mmx: Fix x86 build on MSVC
build: Improve win32 build system
Antti S. Lankila (5):
Faster unorm_to_unorm for wide processing.
Remove unnecessary dst initialization
Add support for sRGB surfaces
Add sRGB blending demo program
Add tests to validate new sRGB behavior
Benny Siegert (1):
configure.ac: PIXMAN_LINK_WITH_ENV fix
Matt Turner (22):
mmx: add and use expand_4xpacked565 function
mmx: implement expand_4x565 in terms of expand_4xpacked565
fast: add add_0565_0565 function
mmx: add add_0565_0565
mmx: add over_reverse_n_8888
mmx: add missing _mm_empty calls
autotools: use custom build rule to build iwMMXt code
configure.ac: add iwmmxt2 configure flag
.gitignore: add test/glyph-test
sse2: enable over_n_0565 for b5g6r5
sse2: add src_x888_0565
Fix distcheck due to custom iwMMXt rules
mmx: Use expand_alpha instead of mask/shift
mmx: add scaled bilinear src_8888_8888
mmx: add scaled bilinear over_8888_8888
mmx: add scaled bilinear over_8888_8_8888
mmx: optimize bilinear function when using 7-bit precision
loongson: optimize _mm_set_pi* functions with shuffle instructions
sse2: add missing ABGR entires for bilinear src_8888_8888
build: Remove useless DEP_CFLAGS/DEP_LIBS variables
sse2: mark pack_565_2x128_128 as static force_inline
iwmmxt: Don't define dummy _mm_empty for >=gcc-4.8
Nemanja Lukic (9):
MIPS: DSPr2: Added several bilinear fast paths with a8 mask
MIPS: DSPr2: Added more bilinear fast paths (without mask)
MIPS: DSPr2: Added fast-paths for OVER operation: - over_8888_n_8888 - ov
MIPS: DSPr2: Added fast-paths for OVER operation: - over_8888_n_0565 - ov
MIPS: DSPr2: Added fast-paths for OVER operation: - over_0565_n_0565 - ov
MIPS: DSPr2: Added OVER combiner and two new fast paths: - over_8888_8888
MIPS: DSPr2: Added fast-paths for ADD operation: - add_n_8_8 - add_n_8_88
MIPS: DSPr2: Added more fast-paths for ADD operation: - add_0565_8_0565 -
MIPS: DSPr2: Added more fast-paths for ADD operation: - add_8888_8888_888
Sebastian Bauer (4):
Qualify the static variables in pixman_f_transform_invert() with the cons
Changed the style of two function headers
Added HAVE_CONFIG_H check before including config.h
Use angle brackets form of including config.h
Siarhei Siamashka (12):
test: OpenMP 2.5 requires signed loop iteration variables
test: fix bisecting issue in fuzzer-find-diff.pl
test: Fix for strict aliasing issue in 'get_random_seed'
test: support nearest/bilinear scaling in lowlevel-blt-bench
sse2: faster bilinear scaling (use _mm_loadl_epi64)
Bilinear interpolation precision is now configurable at compile time
sse2: _mm_madd_epi16 for faster bilinear scaling with 7-bit precision
Change default bilinear interpolation precision to 7 bits
Add scaled nearest repeat fast paths
MIPS: skip runtime detection for DSPr2 if -mdspr2 option is in CFLAGS
Add missing force_inline to in() function used for C fast paths
Workaround for FTBFS with gcc 4.6 (http://gcc.gnu.org/PR54965)
S?ren Sandmann Pedersen (78):
Post-release version bump to 0.27.1
Pass the full image flags to iterators
Make use of image flags in mmx and sse2 iterators
Add doubly linked lists
Add pixman_glyph_cache_t API
Move CRC32 computation from blitters-test.c into utils.c
Add support for alpha maps to compute_crc32_for_image().
test: Add glyph-test
Speed up pixman_composite_glyphs()
Speed up _pixman_composite_glyphs_no_mask()
Speed up _pixman_image_get_solid() in common cases
bits-image: Turn all the fetchers into iterator getters
test: Make glyph test pass on big endian
test: Add missing break in stress-test.c
test: Make stress-test more likely to actually composite something
In fast_composite_tiled_repeat() don't clone images with a palette
Use a compile-time constant for the "K" constraint in the MMX detection.
pixman-cpu.c: Rename disabled to _pixman_disabled() and export it
Move x86 specific CPU detection to a new file pixman-x86.c
Move ARM specific CPU detection to a new file pixman-arm.c
Move PowerPC specific CPU detection to its own file pixman-ppc.c
Move MIPS specific CPU detection to its own file, pixman-mips.c
Move the remaining bits of pixman-cpu into pixman-implementation.c
Simplify MIPS CPU detection
Simplifications to ARM CPU detection
Simplify CPU detection on PPC.
Cleanups and simplifications in x86 CPU feature detection
Make pixman-mmx.c compile on x86-32 without optimization
Add make-srgb.pl to EXTRA_DIST
stress-test: Avoid overflows in clip rectangles
glyph-test: Avoid setting solid images as alpha maps.
Pre-release version bump to 0.27.2
Post-release version bump to 0.27.3
Define TIMER_BEGIN and TIMER_END even when timers are not enabled
Make show_image() cope with more formats
demos: Add srgb_trap_test.c
Remove pointless declaration of _pixman_image_get_scanline_generic_64()
Remove obsolete TODO file
pixel_checker: Move sRGB conversion into get_limits()
test/utils.c: Use pow(), not powf() in sRGB conversion routines
implementation: Write lookup_combiner() in a less convoluted way.
Move blt delegation into pixman-implementation.c
Move fill delegation into pixman-implementation.c
Move delegation of src/dest iter init into pixman-implementation.c
Rename _pixman_lookup_composite_function() to _pixman_implementation_look
_pixman_implementation_create(): Initialize implementation with memset()
implementation: Rename delegate to fallback
Add PIXMAN_x8b8g8r8 and PIXMAN_a8b8g8r8 formats to scaling-test
Fix bug in fast_composite_scaled_nearest()
Fix bugs in component alpha combiners for separable PDF operators
Add rotate-test.c test program
Fix bugs in pixman-image.c
pixman-combine.c.template: Formatting clean-ups
affine-test: Print out the transformation matrix when verbose
test: Add inifinite-loop test
Fix for infinite-loop test
rotate-test: Call image_endian_swap() in make_image()
Make pixman.h more const-correct
glyph-test: Prepare for floating point
blitters-test: Prepare for floating point
Add pixman-combine-float.c
Add combiner test
pixman-utils.c, pixman-private.h: Add floating point conversion routines
pixman-access.c: Add floating point accessor functions
Switch the wide pipeline over to using floating point
Remove 64 bit pipeline
Don't auto-generate pixman-combine32.[ch] anymore
Speed up pixman_expand_to_float()
Remove BUILT_SOURCES
Only regard images as pixbufs if they have identity transformations
region: Formatting fix
region: Remove overlap argument from pixman_op()
Add new pixman_image_create_bits_no_clear() API
pixman_composite_trapezoids(): Factor out extents computation
pixman_composite_trapezoids(): don't clip to extents for some operators
Pre-release version bump to 0.27.4
Post-release version bump to 0.27.5
Pre-release version bump to 0.28.0
_______________________________________________
cairo-announce mailing list
cairo-announce at lists.cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo-announce
From techieinfo at yahoo.co.uk Wed Nov 7 13:28:32 2012
From: techieinfo at yahoo.co.uk (Techie Help)
Date: Wed, 7 Nov 2012 21:28:32 +0000 (GMT)
Subject: [cairo] Cairo and freetype
Message-ID: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
Hi,
I am new to Graphics, so new to cairo as well.
I am trying to render some text using Cairo and freetype.
The backend that I am using is gcm, and it does not support any glyphs etc.
Can anyone please provide me with an example how to do this.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From justin at sweaky.com Wed Nov 7 15:13:00 2012
From: justin at sweaky.com (Justin Thomas)
Date: Wed, 7 Nov 2012 15:13:00 -0800
Subject: [cairo] Cairo and freetype
In-Reply-To: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
References: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
Message-ID:
If your platform is PS3 and your using GCM already your best option is to
use the freetype library and glyph/font rendering already available in the
SDK. However, if your set on using cairo then most likely you will need to
render to an image surface first then copy it to the gcm surface, a pseudo
example:
FT_Error err = 0;
FT_Face fontFace = 0;
if((err = FT_New_Face(, "font.ttf", 0, &fontFace)) !=
0)
{
printf("failed to create font (0x%x)\n", err);
exit(1)
}
cairo_font_face_t* cairoFontFace =
cairo_ft_font_face_create_for_ft_face(fontFace, 0);
cairo_matrix_t mxSize;
cairo_matrix_t mxIdent;
cairo_matrix_init_scale(&mxSize, 16, 16); // sizing..
cairo_matrix_init_identity(&mxIdent);
cairo_scaled_font_t* cairoFont = cairo_scaled_font_create(cairoFontFace,
&mxSize, &mxIdent, 0);
// context = cairo_create()
cairo_set_scaled_font(context, cairoFont);
cairo_set_font_size(context, 16);
cairo_new_path(context);
cairo_move_to(context, 25, 25);
cairo_text_path(context, "CAIRO TEXT!");
cairo_set_source_rgb(context, 1, 0, 0);
cairo_fill(context);
.. then take your image surface and paint to the gcm context (I actually
don't know if this is the best way, I imagine there are others using fill
and source operator, maybe someone else with more experience can chime
in)...
cairo_set_source_surface(gcmContext, imageSurface, 0, 0);
cairo_paint(gcmContext);
-JT
On Wed, Nov 7, 2012 at 1:28 PM, Techie Help wrote:
> Hi,
>
> I am new to Graphics, so new to cairo as well.
> I am trying to render some text using Cairo and freetype.
> The backend that I am using is gcm, and it does not support any glyphs etc.
> Can anyone please provide me with an example how to do this.
>
> Thanks
>
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From techieinfo at yahoo.co.uk Thu Nov 8 02:51:23 2012
From: techieinfo at yahoo.co.uk (Techie Help)
Date: Thu, 8 Nov 2012 10:51:23 +0000 (GMT)
Subject: [cairo] Cairo and freetype
In-Reply-To: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
References: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
Message-ID: <1352371883.74619.YahooMailNeo@web171605.mail.ir2.yahoo.com>
Hi Jutsin,
?
I did it the way you suggested:
Here's what I did:
?
?
cairo_device_t *? cairo_device=cairo_gcm_device_create(1024*1024*10, 1024*1024*15, 1024*1024*20);
??????? cairo_surface_t * surface = cairo_gcm_surface_create_for_texture(cairo_device, 1500, 1500);
??? ?
?? /* Init freetype */
??int error;
??FT_Library ft_library;
??error = FT_Init_FreeType(&ft_library);
??if (error)
??{
???printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__, __LINE__);
??}
??//Load our fonts
??FT_Face ft_face = NULL;
??????? error = FT_New_Face(ft_library, "/app_home/FreeMonoBold.ttf", 0, &ft_face);
??if (error)
??{
???printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__, __LINE__);
??}
???
??cairo_font_face_t *myfont_face;
??myfont_face =? cairo_ft_font_face_create_for_ft_face(ft_face,0);
??
??cairo_matrix_t mxSize;
??cairo_matrix_t mxIdent;
??cairo_matrix_init_scale(&mxSize, 16, 16); // sizing..
??cairo_matrix_init_identity(&mxIdent);
??cairo_scaled_font_t* cairoFont = cairo_scaled_font_create(myfont_face, &mxSize, &mxIdent, 0);
??cairo_t *cr = cairo_create (surface);
??
??cairo_set_scaled_font(cr, cairoFont);
??cairo_set_font_size(cr, 16);
??cairo_new_path(cr);
??cairo_move_to(cr, 200, 200);
??
??cairo_text_path(cr, "Print Something");
??cairo_set_source_rgb(cr, 1, 0, 0);
??cairo_fill(cr);
??cairo_set_source_surface(cr, surface, 0, 0);
??cairo_paint(cr);?
sys_timer_usleep(20 *1000000);
?
I added sleep in the end, so that if there is any text I can see it before application exits.
But I still don't see anything.
?
Sorry, I am totally new to all this. You mentioned that it will be better if I use
freetype library and glyph/font rendering already available in the SDK(yes, my platform is PS3)
but I am not sure how to find what is available in SDK and how to use it?
?
Please if you can provide any more guidance it would be of great help.
Thanks
________________________________
From: Techie Help
To: "cairo at cairographics.org"
Sent: Wednesday, 7 November 2012, 21:28
Subject: Cairo and freetype
Hi,
I am new to Graphics, so new to cairo as well.
I am trying to render some text using Cairo and freetype.
The backend that I am using is gcm, and it does not support any glyphs etc.
Can anyone please provide me with an example how to do this.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From techieinfo at yahoo.co.uk Thu Nov 8 04:58:33 2012
From: techieinfo at yahoo.co.uk (Techie Help)
Date: Thu, 8 Nov 2012 12:58:33 +0000 (GMT)
Subject: [cairo] Cairo and freetype
In-Reply-To: <1352371883.74619.YahooMailNeo@web171605.mail.ir2.yahoo.com>
References: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
<1352371883.74619.YahooMailNeo@web171605.mail.ir2.yahoo.com>
Message-ID: <1352379513.85854.YahooMailNeo@web171601.mail.ir2.yahoo.com>
Hi,
?
The problem was with cairo_font_options_t. They can't be NULL in call : cairo_scaled_font_create().
So, I added default options.
?
It has moved further but still no text as on executing this line of code:
cairo_text_path(), I get
?
_gcm_surface_get_font_options not implemented yet
in my debugger.
Any ideas, how to?get rid of?this.
?
Thanks.
----- Forwarded Message -----
From: Techie Help
To: "cairo at cairographics.org"
Sent: Thursday, 8 November 2012, 10:51
Subject: Re: Cairo and freetype
Hi Jutsin,
?
I did it the way you suggested:
Here's what I did:
?
?
cairo_device_t *? cairo_device=cairo_gcm_device_create(1024*1024*10, 1024*1024*15, 1024*1024*20);
??????? cairo_surface_t * surface = cairo_gcm_surface_create_for_texture(cairo_device, 1500, 1500);
??? ?
?? /* Init freetype */
??int error;
??FT_Library ft_library;
??error = FT_Init_FreeType(&ft_library);
??if (error)
??{
???printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__,
__LINE__);
??}
??//Load our fonts
??FT_Face ft_face = NULL;
??????? error = FT_New_Face(ft_library, "/app_home/FreeMonoBold.ttf", 0, &ft_face);
??if (error)
??{
???printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__, __LINE__);
??}
???
??cairo_font_face_t *myfont_face;
??myfont_face =? cairo_ft_font_face_create_for_ft_face(ft_face,0);
??
??cairo_matrix_t mxSize;
??cairo_matrix_t mxIdent;
??cairo_matrix_init_scale(&mxSize, 16, 16); // sizing..
??cairo_matrix_init_identity(&mxIdent);
??cairo_scaled_font_t* cairoFont = cairo_scaled_font_create(myfont_face, &mxSize, &mxIdent, 0);
??cairo_t *cr = cairo_create (surface);
??
??cairo_set_scaled_font(cr, cairoFont);
??cairo_set_font_size(cr, 16);
??cairo_new_path(cr);
??cairo_move_to(cr, 200, 200);
??
??cairo_text_path(cr, "Print Something");
??cairo_set_source_rgb(cr, 1, 0, 0);
??cairo_fill(cr);
??cairo_set_source_surface(cr, surface, 0, 0);
??cairo_paint(cr);?
sys_timer_usleep(20 *1000000);
?
I added sleep in the end, so that if there is any text I can see it before application exits.
But I still don't see anything.
?
Sorry, I am totally new to all this. You mentioned that it will be better if I use
freetype library and glyph/font rendering already available in the SDK(yes, my platform is PS3)
but I am not sure how to find what is available in SDK and how to use it?
?
Please if you can provide any more guidance it would be of great help.
Thanks
________________________________
From: Techie Help
To: "cairo at cairographics.org"
Sent: Wednesday, 7 November 2012, 21:28
Subject: Cairo and freetype
Hi,
I am new to Graphics, so new to cairo as well.
I am trying to render some text using Cairo and freetype.
The backend that I am using is gcm, and it does not support any glyphs etc.
Can anyone please provide me with an example how to do this.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From techieinfo at yahoo.co.uk Thu Nov 8 09:04:57 2012
From: techieinfo at yahoo.co.uk (Techie Help)
Date: Thu, 8 Nov 2012 17:04:57 +0000 (GMT)
Subject: [cairo] Cairo and freetype
In-Reply-To: <1352379513.85854.YahooMailNeo@web171601.mail.ir2.yahoo.com>
References: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
<1352371883.74619.YahooMailNeo@web171605.mail.ir2.yahoo.com>
<1352379513.85854.YahooMailNeo@web171601.mail.ir2.yahoo.com>
Message-ID: <1352394297.82008.YahooMailNeo@web171604.mail.ir2.yahoo.com>
Hi,
?
I even tried computing glyphs. I am able to do that. But, then I tried to show it using:
cairo_show_glyphs() and I get:
_gcm_surface_get_font_options not implemented yet
_gcm_surface_has_show_text_glyphs not implemented yet
_gcm_surface_show_text_glyphs not implemented yet
_gcm_surface_show_glyphs not implemented yet
_gcm_surface_old_show_glyphs not implemented yet
_gcm_surface_composite,154 not implemented yet
?
So, I am not sure what my options are now.
Can anyone suggest anything.
?
Many Thanks
techie(ttb)
----- Forwarded Message -----
From: Techie Help
To: "cairo at cairographics.org" ?
Sent: Thursday, 8 November 2012, 12:58
Subject: Cairo and freetype
Hi,
?
The problem was with cairo_font_options_t. They can't be NULL in call : cairo_scaled_font_create().
So, I added default options.
?
It has moved further but still no text as on executing this line of code:
cairo_text_path(), I get
?
_gcm_surface_get_font_options not implemented yet
in my debugger.
Any ideas, how to?get rid of?this.
?
Thanks.
----- Forwarded Message -----
From: Techie Help
To: "cairo at cairographics.org"
Sent: Thursday, 8 November 2012, 10:51
Subject: Re: Cairo and freetype
Hi Jutsin,
?
I did it the way you suggested:
Here's what I did:
?
?
cairo_device_t *? cairo_device=cairo_gcm_device_create(1024*1024*10, 1024*1024*15, 1024*1024*20);
??????? cairo_surface_t * surface = cairo_gcm_surface_create_for_texture(cairo_device, 1500, 1500);
??? ?
?? /* Init freetype */
??int error;
??FT_Library ft_library;
??error = FT_Init_FreeType(&ft_library);
??if (error)
??{
???printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__,
__LINE__);
??}
??//Load our fonts
??FT_Face ft_face = NULL;
??????? error = FT_New_Face(ft_library, "/app_home/FreeMonoBold.ttf", 0, &ft_face);
??if (error)
??{
???printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__, __LINE__);
??}
???
??cairo_font_face_t *myfont_face;
??myfont_face =? cairo_ft_font_face_create_for_ft_face(ft_face,0);
??
??cairo_matrix_t mxSize;
??cairo_matrix_t mxIdent;
??cairo_matrix_init_scale(&mxSize, 16, 16); // sizing..
??cairo_matrix_init_identity(&mxIdent);
??cairo_scaled_font_t* cairoFont = cairo_scaled_font_create(myfont_face, &mxSize, &mxIdent, 0);
??cairo_t *cr = cairo_create (surface);
??
??cairo_set_scaled_font(cr, cairoFont);
??cairo_set_font_size(cr, 16);
??cairo_new_path(cr);
??cairo_move_to(cr, 200, 200);
??
??cairo_text_path(cr, "Print Something");
??cairo_set_source_rgb(cr, 1, 0, 0);
??cairo_fill(cr);
??cairo_set_source_surface(cr, surface, 0, 0);
??cairo_paint(cr);?
sys_timer_usleep(20 *1000000);
?
I added sleep in the end, so that if there is any text I can see it before application exits.
But I still don't see anything.
?
Sorry, I am totally new to all this. You mentioned that it will be better if I use
freetype library and glyph/font rendering already available in the SDK(yes, my platform is PS3)
but I am not sure how to find what is available in SDK and how to use it?
?
Please if you can provide any more guidance it would be of great help.
Thanks
________________________________
From: Techie Help
To: "cairo at cairographics.org"
Sent: Wednesday, 7 November 2012, 21:28
Subject: Cairo and freetype
Hi,
I am new to Graphics, so new to cairo as well.
I am trying to render some text using Cairo and freetype.
The backend that I am using is gcm, and it does not support any glyphs etc.
Can anyone please provide me with an example how to do this.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ajax at redhat.com Thu Nov 8 09:19:30 2012
From: ajax at redhat.com (Adam Jackson)
Date: Thu, 08 Nov 2012 12:19:30 -0500
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <1351714426-14768-1-git-send-email-ajax@redhat.com>
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
Message-ID: <509BE9A2.2000209@redhat.com>
On 10/31/12 4:13 PM, Adam Jackson wrote:
> malloc(0) needn't return NULL, and on glibc, doesn't. Then we encounter
> a loop of the form do { ... } while (--c), which doesn't do quite what
> you were hoping for when c is initially 0.
>
> Since there's nothing to swap in this case, just bomb out.
Bump. Anything else I need to add here?
- ajax
From justin at sweaky.com Thu Nov 8 10:46:08 2012
From: justin at sweaky.com (Justin Thomas)
Date: Thu, 8 Nov 2012 10:46:08 -0800
Subject: [cairo] Cairo and freetype
In-Reply-To: <1352394297.82008.YahooMailNeo@web171604.mail.ir2.yahoo.com>
References: <1352323712.37721.YahooMailNeo@web171602.mail.ir2.yahoo.com>
<1352371883.74619.YahooMailNeo@web171605.mail.ir2.yahoo.com>
<1352379513.85854.YahooMailNeo@web171601.mail.ir2.yahoo.com>
<1352394297.82008.YahooMailNeo@web171604.mail.ir2.yahoo.com>
Message-ID: <3D81F734-3065-40CA-8CC0-2CADD63CF466@sweaky.com>
So I think your close, you just need to render the text to an image surface instead of the gcm surface (cairo_image_surface_* functions)
Then take that image surface and render it to your gcm surface.
So context1 (image), render text to image surface.
Then context2 (gcm), render image surface to gcm surface, last 2 lines in your code.
As far as the freetype/gcm font rendering already available in the PS3 SDK, you will need to ask that on devnet, but if you search the docs for freetype you should find it pretty quickly.
-JT
On Nov 8, 2012, at 9:04 AM, Techie Help wrote:
> Hi,
>
> I even tried computing glyphs. I am able to do that. But, then I tried to show it using:
> cairo_show_glyphs() and I get:
> _gcm_surface_get_font_options not implemented yet
> _gcm_surface_has_show_text_glyphs not implemented yet
> _gcm_surface_show_text_glyphs not implemented yet
> _gcm_surface_show_glyphs not implemented yet
> _gcm_surface_old_show_glyphs not implemented yet
> _gcm_surface_composite,154 not implemented yet
>
> So, I am not sure what my options are now.
> Can anyone suggest anything.
>
> Many Thanks
> techie(ttb)
>
> ----- Forwarded Message -----
> From: Techie Help
> To: "cairo at cairographics.org"
> Sent: Thursday, 8 November 2012, 12:58
> Subject: Cairo and freetype
>
> Hi,
>
> The problem was with cairo_font_options_t. They can't be NULL in call : cairo_scaled_font_create().
> So, I added default options.
>
> It has moved further but still no text as on executing this line of code:
> cairo_text_path(), I get
>
> _gcm_surface_get_font_options not implemented yet
> in my debugger.
> Any ideas, how to get rid of this.
>
> Thanks.
>
> ----- Forwarded Message -----
> From: Techie Help
> To: "cairo at cairographics.org"
> Sent: Thursday, 8 November 2012, 10:51
> Subject: Re: Cairo and freetype
>
> Hi Jutsin,
>
> I did it the way you suggested:
> Here's what I did:
>
>
> cairo_device_t * cairo_device=cairo_gcm_device_create(1024*1024*10, 1024*1024*15, 1024*1024*20);
> cairo_surface_t * surface = cairo_gcm_surface_create_for_texture(cairo_device, 1500, 1500);
>
> /* Init freetype */
> int error;
> FT_Library ft_library;
> error = FT_Init_FreeType(&ft_library);
> if (error)
> {
> printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__, __LINE__);
> }
> //Load our fonts
> FT_Face ft_face = NULL;
> error = FT_New_Face(ft_library, "/app_home/FreeMonoBold.ttf", 0, &ft_face);
> if (error)
> {
> printf("ERROR CODE: %d, filename: %s, line no. : %d\n", error, __FILE__, __LINE__);
> }
>
> cairo_font_face_t *myfont_face;
> myfont_face = cairo_ft_font_face_create_for_ft_face(ft_face,0);
>
> cairo_matrix_t mxSize;
> cairo_matrix_t mxIdent;
> cairo_matrix_init_scale(&mxSize, 16, 16); // sizing..
> cairo_matrix_init_identity(&mxIdent);
> cairo_scaled_font_t* cairoFont = cairo_scaled_font_create(myfont_face, &mxSize, &mxIdent, 0);
> cairo_t *cr = cairo_create (surface);
>
> cairo_set_scaled_font(cr, cairoFont);
> cairo_set_font_size(cr, 16);
> cairo_new_path(cr);
> cairo_move_to(cr, 200, 200);
>
> cairo_text_path(cr, "Print Something");
> cairo_set_source_rgb(cr, 1, 0, 0);
> cairo_fill(cr);
> cairo_set_source_surface(cr, surface, 0, 0);
> cairo_paint(cr);
> sys_timer_usleep(20 *1000000);
>
> I added sleep in the end, so that if there is any text I can see it before application exits.
> But I still don't see anything.
>
> Sorry, I am totally new to all this. You mentioned that it will be better if I use
> freetype library and glyph/font rendering already available in the SDK(yes, my platform is PS3)
> but I am not sure how to find what is available in SDK and how to use it?
>
> Please if you can provide any more guidance it would be of great help.
> Thanks
> From: Techie Help
> To: "cairo at cairographics.org"
> Sent: Wednesday, 7 November 2012, 21:28
> Subject: Cairo and freetype
>
> Hi,
>
> I am new to Graphics, so new to cairo as well.
> I am trying to render some text using Cairo and freetype.
> The backend that I am using is gcm, and it does not support any glyphs etc.
> Can anyone please provide me with an example how to do this.
>
> Thanks
>
>
>
>
>
>
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From behdad at behdad.org Thu Nov 8 13:04:30 2012
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 08 Nov 2012 13:04:30 -0800
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <509BE9A2.2000209@redhat.com>
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
<509BE9A2.2000209@redhat.com>
Message-ID: <509C1E5E.2040404@behdad.org>
On 12-11-08 09:19 AM, Adam Jackson wrote:
> malloc(0) needn't return NULL, and on glibc, doesn't.
BTW, is this a recent change? I noticed a bug because of it in harfbuzz also.
behdad
From ajax at redhat.com Thu Nov 8 13:30:54 2012
From: ajax at redhat.com (Adam Jackson)
Date: Thu, 08 Nov 2012 16:30:54 -0500
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <509C1E5E.2040404@behdad.org>
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
<509BE9A2.2000209@redhat.com> <509C1E5E.2040404@behdad.org>
Message-ID: <509C248E.6060807@redhat.com>
On 11/8/12 4:04 PM, Behdad Esfahbod wrote:
> On 12-11-08 09:19 AM, Adam Jackson wrote:
>> malloc(0) needn't return NULL, and on glibc, doesn't.
>
> BTW, is this a recent change? I noticed a bug because of it in harfbuzz also.
I don't believe so. RHEL5's glibc has this property, so it's probably
been this way since at least 2006.
- ajax
From cloos at jhcloos.com Thu Nov 8 16:32:21 2012
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 08 Nov 2012 19:32:21 -0500
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <509C248E.6060807@redhat.com> (Adam Jackson's message of "Thu, 08
Nov 2012 16:30:54 -0500")
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
<509BE9A2.2000209@redhat.com> <509C1E5E.2040404@behdad.org>
<509C248E.6060807@redhat.com>
Message-ID:
AJ> malloc(0) needn't return NULL, and on glibc, doesn't.
BE> BTW, is this a recent change? I noticed a bug because of it in harfbuzz also.
AJ> I don't believe so. RHEL5's glibc has this property, so it's probably
AJ> been this way since at least 2006.
A quick look at the history for the malloc.c file in glibc shows
the comment fragment:
Even a request for zero bytes (i.e., malloc(0)) returns a
pointer to something of the minimum allocatable size.
was included in the first version of malloc/malloc.c committed to glibc
back on 1996/Dec/08.
Glibc may never have returned NULL from malloc(0).
I do not recall what libc5 did, nor what the BSDs or the commercial
unixen did back then.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
From fredbca21 at gmail.com Fri Nov 9 03:01:09 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Fri, 9 Nov 2012 12:01:09 +0100
Subject: [cairo] Cairo crash with a simple stroke (win32) - PATCH
proposal
In-Reply-To:
References:
Message-ID:
bump! Is anyone interested? At least a comment?
I am starting to wonder if my emails are actually received by list
members... :-)
Fred.
2012/11/7 Fred bca21 :
> Hi,
>
> Does the patch below make sense to you? It seems the extent should
> just be offset to the origin when mapping the win32 surface to an
> image, since the image is already created at the right location. I
> have not been able to make extensive tests yet, but can someone review
> this patch?
>
> BTW, is there any way to build and run the tests on windows? Neither
> the configure nor the Makefile.Win32 method work on my system.
>
> Index: src/win32/cairo-win32-display-surface.c
> ===================================================================
> --- src/win32/cairo-win32-display-surface.c
> +++ src/win32/cairo-win32-display-surface.c
> @@ -464,8 +464,16 @@
> surface = to_win32_display_surface (surface->fallback);
> done:
> GdiFlush();
> - return _cairo_image_surface_map_to_image (surface->image, extents);
>
> + // since the image built above is already offset at the right
> position, create the image at 0,0.
> + {
> + cairo_rectangle_int_t r;
> + r.x=0;
> + r.y=0;
> + r.width=extents->width;
> + r.height=extents->height;
> + return _cairo_image_surface_map_to_image (surface->image, &r);
> + }
> err:
> cairo_surface_destroy (surface->fallback);
> surface->fallback = NULL;
>
>
> 2012/11/7 Fred bca21 :
>> Hi Again,
>>
>> It appears that the bug seems to happen because the extents of the
>> fallback image has an offset in its origin.
>> when performing the mapping of the surface to an image, in
>> cairo-win32-display-surface.c, on line 467:
>> return _cairo_image_surface_map_to_image (surface->image, extents);
>>
>> this actually creates a pixman image with an invalid pointer, that is
>> supposed to be compensated by the device transform, as you can see in
>> cairo-image-surface.c on line 805:
>> uint8_t *data;
>>
>> data = other->data;
>> data += extents->y * other->stride; // THIS POINTER IS OUTSIDE OF
>> THE ACTUAL IMAGE (the image is created with the actual extent, not the
>> entire surface extent)
>> data += extents->x * PIXMAN_FORMAT_BPP (other->pixman_format)/ 8;
>>
>> surface =_cairo_image_surface_create_with_pixman_format (data,
>> other->pixman_format,
>> extents->width,
>> extents->height,
>> other->stride);
>>
>> cairo_surface_set_device_offset (surface, -extents->x,
>> -extents->y); /// THIS IS SUPPOSED TO COMPENSATE THE OFFSET ABOVE
>> return surface;
>>
>> But in the end, when reaching the _fill_xrgb32_lerp_opaque_spans
>> function, the data pointer is still the wrong one (as offset in the
>> function above, not compensated by the device transform).
>>
>> So either the device transform should be applied at some point and it
>> is not, or the mapping of the image is wrong and should not use the
>> origin of the extents,
>>
>> That's all I can do for now with my imited knowledge, but I hope it
>> helps a little bit and maybe this will motivate someone to check this
>> out.
>>
>> Regards,
>>
>> Fred.
>>
>> 2012/11/7 Fred bca21 :
>>> Hi,
>>>
>>> No surprise: the issue is still here in 1.12.8. Running the code below
>>> crashes in _fill_xrgb32_lerp_opaque_spans.
>>>
>>> If anyone can give me an idea of how to get started on debugging this,
>>> I'd be glad to help fixing this problem. I have already spent some
>>> time on it, but it's pretty hard to understand where the composite
>>> destination data pointer is changed without not much knowledge of the
>>> cairo code.
>>>
>>> Just wondering: why isn't there much interest for this problem?
>>>
>>> Thanks!
>>>
>>> Fred.
>>>
>>> {
>>> // build a bitmap (same issue with DIB, whatever the bit depth)
>>> HDC dc=::CreateCompatibleDC(NULL);
>>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>>> ::SelectObject(dc,hBmp);
>>>
>>> // set clip region for the DC to one single line in the middle of the bitmap
>>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>>> SelectClipRgn(dc, hrgn);
>>> ::DeleteObject(hrgn);
>>>
>>> // create cairo context
>>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>>> if(surface)
>>> {
>>> cairo_t* context=cairo_create(surface);
>>> if(context)
>>> {
>>> // draw one line
>>> cairo_move_to(context,1, 1);
>>> cairo_line_to(context,10,120);
>>> cairo_set_source_rgb(context,1,1,1);
>>>
>>> // CRASHES HERE:
>>> cairo_stroke(context);
>>>
>>> // cleanup
>>> cairo_destroy(context);
>>> }
>>> cairo_surface_destroy(surface);
>>> }
>>> }
>>>
>>> 2012/11/5 Fred bca21 :
>>>> Hi,
>>>>
>>>> Thank you Martin for your answer. The thing is, it is a feature that a
>>>> surface built on a HDC gets the right clipping region. It is indeed
>>>> possible to manually overwrite, re-compute and apply the clipping
>>>> region to the cairo context, but it is probably better just to fix
>>>> cairo and this feature :-). Also, this problem is also probably
>>>> occuring in other cases (it is a crash in the compositing functions).
>>>>
>>>> Has anyone found a way to fix it properly?
>>>>
>>>> I'll double check with the new 1.12.8 that has just been released
>>>> (there seem to be changes in this area), but it would be great to have
>>>> feedback from the experts.
>>>>
>>>> Regards,
>>>>
>>>> Fred.
>>>>
>>>>
>>>> 2012/10/30 Martin Schlemmer :
>>>>> Hi,
>>>>>
>>>>>> After some additionnal debugging, it appears that the raw data pointer
>>>>>> (unsigned char *data;) in the destination image surface for the
>>>>>> compositor is invalid, hence the crash. I have not been able to find
>>>>>> out where this comes from yet (the multiple casts throughout the code
>>>>>> does not make easy for a newcomer to track this field in the image
>>>>>> surface). All I can say is it is valid when the fallback image for the
>>>>>> surface is created, at the beginning of the cairo_stroke call.
>>>>>
>>>>>> Does anybody have any clue? I feel a bit lonely on this issue :).
>>>>>
>>>>> I am not sure if its a feature or a bug, but if you remove the bits that sets the Clip Region directly on the HDC, it does not crash.
>>>>> I assume that you should rather use:
>>>>>
>>>>> cairo_rectangle ()
>>>>> cairo_clip ()
>>>>>
>>>>> on the created context.
>>>>>
>>>>> I could however be incorrect, and that creating a surface from a HDC which already has a Clip Region set directly on the HDC should not give current results - maybe somebody can verify?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Martin
>>>>>
>>>>>
>>>>>>2012/10/25 Fred bca21 :
>>>>>> Hi,
>>>>>>
>>>>>> I have just tested with the latest cairo release (1.12.6), and it
>>>>>> appears that the issue is still here (crash at the exact same
>>>>>> location). Has anyone an idea of how to fix it? Should I maybe post
>>>>>> this to the bugs mailing list?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Fred.
>>>>>>
>>>>>>
>>>>>> 2012/10/19 Fred bca21 :
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am new to this list but I have been using cairo and monitoring posts
>>>>>>> for a couple of months now. I have a strange issue on windows when the
>>>>>>> intersection between the clipping region and the drawing is very
>>>>>>> small, so I am posting here with the hope that someone can help (I am
>>>>>>> a bit too new to cairo's internals to debug this problem).
>>>>>>>
>>>>>>> Typically, the simple code below crashes (I am using a DDB bitmap for
>>>>>>> the example, but it also crashes with any DC).
>>>>>>>
>>>>>>> #include "cairo.h"
>>>>>>> #include "cairo-win32.h"
>>>>>>> #include
>>>>>>> {
>>>>>>> // build a bitmap (same issue with DIB, whatever the bit depth)
>>>>>>> HDC dc=::CreateCompatibleDC(NULL);
>>>>>>> HBITMAP hBmp=::CreateCompatibleBitmap(dc,100,200);
>>>>>>> ::SelectObject(dc,hBmp);
>>>>>>>
>>>>>>> // set clip region for the DC to one single line in the middle of the bitmap
>>>>>>> HRGN hrgn = CreateRectRgn(0,100,100, 101);
>>>>>>> SelectClipRgn(dc, hrgn);
>>>>>>> ::DeleteObject(hrgn);
>>>>>>>
>>>>>>> // create cairo context
>>>>>>> cairo_surface_t* surface=cairo_win32_surface_create(dc);
>>>>>>> if(surface)
>>>>>>> {
>>>>>>> cairo_t* context=cairo_create(surface);
>>>>>>> if(context)
>>>>>>> {
>>>>>>> // draw one line
>>>>>>> cairo_move_to(context,1, 1);
>>>>>>> cairo_line_to(context,10,120);
>>>>>>> cairo_set_source_rgb(context,1,1,1);
>>>>>>>
>>>>>>> // CRASHES HERE (see below):
>>>>>>> cairo_stroke(context);
>>>>>>>
>>>>>>> // cleanup
>>>>>>> cairo_destroy(context);
>>>>>>> }
>>>>>>> cairo_surface_destroy(surface);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> The crash occurs in cairo-image-compositor.c, on line 2197, in
>>>>>>> _fill_xrgb32_lerp_opaque_spans():
>>>>>>>
>>>>>>> } else while (len--) {
>>>>>>> // On this line below, d has an invalid address
>>>>>>> *d = lerp8x4 (r->u.fill.pixel, a, *d);
>>>>>>> d++;
>>>>>>> }
>>>>>>>
>>>>>>> If it may help, am using the static lib version of the latest release
>>>>>>> (1.12.4 - pixman 26.2), and it crashes in debug or release mode, 32 or
>>>>>>> 64-bit windows. It's too bad because this crash occurs all the time in
>>>>>>> my code that extensively uses clipping regions!
>>>>>>>
>>>>>>> This crash also occurs with the previous version of cairo (1.12.2) and
>>>>>>> pixman 26.0, but at a different stage (in pixman if I remember well),
>>>>>
>>>>>
>>>>> Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html
>>>>>
From hakki at dogusan.net Fri Nov 9 04:16:53 2012
From: hakki at dogusan.net (Hakki Dogusan)
Date: Fri, 09 Nov 2012 14:16:53 +0200
Subject: [cairo] Cairo crash with a simple stroke (win32) - PATCH
proposal
In-Reply-To:
References:
Message-ID: <509CF435.9060807@dogusan.net>
Hi,
09-11-2012 13:01 tarihinde, Fred bca21 yazd?:
> bump! Is anyone interested? At least a comment?
>
I'm very interested!
Applied your patch to 1.12.8. There is no crash, but my graphics are
acummulated to 0,0. My drawings involves scale and translate commands.
(using winxp, mingw)
> I am starting to wonder if my emails are actually received by list
> members... :-)
>
> Fred.
>
> 2012/11/7 Fred bca21 :
>> [snip]
--
Regards,
Hakki Dogusan
From fredbca21 at gmail.com Fri Nov 9 04:40:05 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Fri, 9 Nov 2012 13:40:05 +0100
Subject: [cairo] Cairo crash with a simple stroke (win32) - PATCH
proposal
In-Reply-To: <509CF435.9060807@dogusan.net>
References:
<509CF435.9060807@dogusan.net>
Message-ID:
Great, thank for the feedback!
I am not surprised that it breaks... I have not been able to run tests
on windows yet, and I am currently mainly looking at this issue only
before doing any other development using cairo.
So the fix is probably more complicated than what I proposed, but I
think I may have at least found the root cause.
Still searching and learning cairo, so it might take a while unless we
get some help...
Fred
2012/11/9 Hakki Dogusan :
> Hi,
>
> 09-11-2012 13:01 tarihinde, Fred bca21 yazd?:
>
>> bump! Is anyone interested? At least a comment?
>>
>
> I'm very interested!
>
> Applied your patch to 1.12.8. There is no crash, but my graphics are
> acummulated to 0,0. My drawings involves scale and translate commands.
>
> (using winxp, mingw)
>
>> I am starting to wonder if my emails are actually received by list
>> members... :-)
>>
>> Fred.
>>
>> 2012/11/7 Fred bca21 :
>>>
>>> [snip]
>
>
>
> --
> Regards,
> Hakki Dogusan
>
>
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
From teknos at gmail.com Fri Nov 9 11:44:50 2012
From: teknos at gmail.com (=?UTF-8?Q?Zoz=C3=B3_Teki?=)
Date: Fri, 9 Nov 2012 20:44:50 +0100
Subject: [cairo] A potential issue in cairo-recording-surface.c
Message-ID:
Hi,
I have noticed that some of my objects were lost when drawing them on
a recording surface and playing them back. After doing some debugging
I found that they are not properly added to the bbtree during
playback. (Later elements with the same extents as a prior one tend to
disappear from the chain of headers having similar extents.)
I have prepared the below patch (against 1.12.8), which fixes the
issue for me. (It properly prepends ?header? with its full chain to
?bbt->chain?.)
I am not a regular cairo contributor, this is the first time I am
submitting a patch, so I am not sure this is the proper way or whom to
contact to discuss this issue.
Zoltan
--- src/cairo-recording-surface.c original
+++ src/cairo-recording-surface.c updated
@@ -210,7 +210,10 @@
if (box->p1.x == bbt->extents.p1.x && box->p1.y == bbt->extents.p1.y &&
box->p2.x == bbt->extents.p2.x && box->p2.y == bbt->extents.p2.y)
{
- header->chain = bbt->chain;
+ cairo_command_header_t *last = header;
+ while (last->chain)
+ last = last->chain;
+ last->chain = bbt->chain;
bbt->chain = header;
return CAIRO_STATUS_SUCCESS;
}
From chris at chris-wilson.co.uk Sat Nov 10 00:43:16 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Sat, 10 Nov 2012 08:43:16 +0000
Subject: [cairo] A potential issue in cairo-recording-surface.c
In-Reply-To:
References:
Message-ID: <6c3329$74ob6j@orsmga002.jf.intel.com>
On Fri, 9 Nov 2012 20:44:50 +0100, Zoz?? Teki wrote:
> Hi,
>
> I have noticed that some of my objects were lost when drawing them on
> a recording surface and playing them back. After doing some debugging
> I found that they are not properly added to the bbtree during
> playback. (Later elements with the same extents as a prior one tend to
> disappear from the chain of headers having similar extents.)
>
> I have prepared the below patch (against 1.12.8), which fixes the
> issue for me. (It properly prepends ???header??? with its full chain to
> ???bbt->chain???.)
Thank you, the patch looks correct. Mea culpa.
> I am not a regular cairo contributor, this is the first time I am
> submitting a patch, so I am not sure this is the proper way or whom to
> contact to discuss this issue.
It was fine and you raised the issue ideally. For anything larger, you
may want to invest some time into setting up git for use locally - it
makes patch management much easier.
commit 62b795fe52c73ad58101c101aa77449f4b61a576
Author: Zoz?? Teki
Date: Sat Nov 10 08:35:33 2012 +0000
recording: Append new elements to the end of the bbtree chain
Many thanks, pushed. Have fun using Cairo!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From bbradleyuk at gmail.com Sat Nov 10 03:12:26 2012
From: bbradleyuk at gmail.com (Ben Bradley)
Date: Sat, 10 Nov 2012 11:12:26 +0000
Subject: [cairo] Cairo PDF embedded images not optimizable in Adobe Acrobat
Message-ID:
Hi everyone
I create designed pages in Inkscape then export to PDF. Then I can
further process these PDFs in Acrobat, combine multiple pages and
downsample the images etc.
I believe Inkscape uses Cairo as the back-end for exporting the PDFs.
The problem I've found is that the PDF Optimizer in Acrobat is refusing
to process and downsample the embedded images created by Inkscape/Cairo.
I posted this thread on the Adobe forums and had the following reply...
http://forums.adobe.com/message/4836095#4836095
"The PDF creation software (cairo?) has certainly done something odd. It
has wrapped up the image in a tiling pattern, then painted the pattern
just once. PDF shrinking software isn't likely to mess with the contents
of patterns, they are normally tiny special effect bitmaps not to be
adjusted... maybe there's an option to change this on creation."
Has anyone else encountered this?
Are there any options in Cairo (that aren't exposed by Inkscape) that
can change the way images are embedded in a PDF?
Cheers, B
From ajohnson at redneon.com Sat Nov 10 03:33:33 2012
From: ajohnson at redneon.com (Adrian Johnson)
Date: Sat, 10 Nov 2012 22:03:33 +1030
Subject: [cairo] Cairo PDF embedded images not optimizable in Adobe
Acrobat
In-Reply-To:
References:
Message-ID: <509E3B8D.8010502@redneon.com>
On 10/11/12 21:42, Ben Bradley wrote:
> Hi everyone
>
> I create designed pages in Inkscape then export to PDF. Then I can
> further process these PDFs in Acrobat, combine multiple pages and
> downsample the images etc.
>
> I believe Inkscape uses Cairo as the back-end for exporting the PDFs.
>
> The problem I've found is that the PDF Optimizer in Acrobat is refusing
> to process and downsample the embedded images created by Inkscape/Cairo.
>
> I posted this thread on the Adobe forums and had the following reply...
> http://forums.adobe.com/message/4836095#4836095
> "The PDF creation software (cairo?) has certainly done something odd. It
> has wrapped up the image in a tiling pattern, then painted the pattern
> just once. PDF shrinking software isn't likely to mess with the contents
> of patterns, they are normally tiny special effect bitmaps not to be
> adjusted... maybe there's an option to change this on creation."
>
> Has anyone else encountered this?
> Are there any options in Cairo (that aren't exposed by Inkscape) that
> can change the way images are embedded in a PDF?
>
> Cheers, B
>
This has been fixed in more recent versions. The version you are using
(1.8.8) is very old.
From teknos at gmail.com Sat Nov 10 04:33:40 2012
From: teknos at gmail.com (=?UTF-8?Q?Zoz=C3=B3_Teki?=)
Date: Sat, 10 Nov 2012 13:33:40 +0100
Subject: [cairo] A question regarding text extents
Message-ID:
Hi,
I use cairo_text_extents() to retrieve how much space is needed for a
piece of text to be able to draw a simple box around it. I have
noticed that this function returns a different value depending on the
transformation matrix in effect. Specifically, if I scale the context,
the returned x_advance is somewhat larger (and also the text is drawn
somewhat larger) - but not by the scaling factor.
In the example below, the two runs produce different values for
extents1.x_advance and extents2.x_advance. On Linux (1.10.2), the two
values are 115 and 116.5 (with whatever font "arial" maps to), whereas
on Windows (1.12.8) I got 109 and 117.
Is this the intended behaviour?
cairo_surface_t *surface =
cairo_image_surface_create(CAIRO_FORMAT_RGB24, 0, 0);
cairo_t *cr = cairo_create(surface);
cairo_select_font_face(cr, "arial", CAIRO_FONT_SLANT_NORMAL,
CAIRO_FONT_WEIGHT_NORMAL);
cairo_set_font_size(cr, 16);
cairo_text_extents_t extents1;
cairo_text_extents(cr, "Now I have both", &extents1);
cairo_destroy(cr);
cairo_surface_destroy(surface);
surface = cairo_image_surface_create(CAIRO_FORMAT_RGB24, 0, 0);
cr = cairo_create(surface);
cairo_scale(cr, 4, 4);
cairo_select_font_face(cr, "arial", CAIRO_FONT_SLANT_NORMAL,
CAIRO_FONT_WEIGHT_NORMAL);
cairo_set_font_size(cr, 16);
cairo_text_extents_t extents2;
cairo_text_extents(cr, "Now I have both", &extents2);
cairo_destroy(cr);
cairo_surface_destroy(surface);
Zoltan
From bbradleyuk at gmail.com Sat Nov 10 05:13:41 2012
From: bbradleyuk at gmail.com (Ben Bradley)
Date: Sat, 10 Nov 2012 13:13:41 +0000
Subject: [cairo] Cairo PDF embedded images not optimizable in Adobe
Acrobat
In-Reply-To: <509E3B8D.8010502@redneon.com>
References: <509E3B8D.8010502@redneon.com>
Message-ID:
On 10/11/2012 11:33, Adrian Johnson wrote:
> This has been fixed in more recent versions. The version you are using
> (1.8.8) is very old.
>
That's awesome. Now to try and get a newer version integrated into Inkscape.
Thanks for the info!
Cheers, B
From psychon at znc.in Mon Nov 12 13:11:01 2012
From: psychon at znc.in (Uli Schlachter)
Date: Mon, 12 Nov 2012 22:11:01 +0100
Subject: [cairo] A question regarding text extents
In-Reply-To:
References:
Message-ID: <50A165E5.6050006@znc.in>
Hi,
On 10.11.2012 13:33, Zoz? Teki wrote:
> I use cairo_text_extents() to retrieve how much space is needed for a
> piece of text to be able to draw a simple box around it. I have
> noticed that this function returns a different value depending on the
> transformation matrix in effect. Specifically, if I scale the context,
> the returned x_advance is somewhat larger (and also the text is drawn
> somewhat larger) - but not by the scaling factor.
[...]
Welcome to hinting. It makes fonts look better by making them "stick" to the
pixel grid. This also means that animations which zoom in/out of text look bad,
because the text "stutters".
The API documentation can tell you a little more (especially how to disable
hinting):
http://cairographics.org/manual/cairo-cairo-font-options-t.html#cairo-hint-style-t
Cheers,
Uli
--
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
- Vincent Ebert
From carl at boeckeler.com Mon Nov 12 13:31:26 2012
From: carl at boeckeler.com (Carl D. Blake)
Date: Mon, 12 Nov 2012 14:31:26 -0700
Subject: [cairo] Using cairo with image surface backend results hangs system
Message-ID: <1352755886.4088.1518.camel@vulcan>
I'm trying to use cairo with a DM8168 based system. I want to be able
to use it with the framebuffer so I've set it up to use the image
surface backend. I've mmaped the framebuffer to a memory location and
passed that as the data pointer to cairo_image_surface_create_for_data.
It appears to work for a while, but it always hangs the system at some
point when any drawing is being done (cairo_show_text or cairo_stroke).
I realize that cairo is drawing directly to the framebuffer, but I
didn't think this would be a problem. Am I doing something wrong here?
Carl
From chris at chris-wilson.co.uk Tue Nov 13 01:57:57 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 13 Nov 2012 09:57:57 +0000
Subject: [cairo] Using cairo with image surface backend results hangs
system
In-Reply-To: <1352755886.4088.1518.camel@vulcan>
References: <1352755886.4088.1518.camel@vulcan>
Message-ID: <453bf0$6euri9@azsmga001.ch.intel.com>
On Mon, 12 Nov 2012 14:31:26 -0700, "Carl D. Blake" wrote:
> I'm trying to use cairo with a DM8168 based system. I want to be able
> to use it with the framebuffer so I've set it up to use the image
> surface backend. I've mmaped the framebuffer to a memory location and
> passed that as the data pointer to cairo_image_surface_create_for_data.
> It appears to work for a while, but it always hangs the system at some
> point when any drawing is being done (cairo_show_text or cairo_stroke).
> I realize that cairo is drawing directly to the framebuffer, but I
> didn't think this would be a problem. Am I doing something wrong here?
It should work, Cairo should not generate out-of-bounds write or reads.
So I would suggest something is going wrong at the hardware/driver level
if the machine stops responding.
However, I can not recommend that you use an UC or WC mapping for a
Cairo surface, except for the final blit. Many of the operators that
Cairo performs involve a readback from memory, which from a scanout will
be very slow and may give the appearance of the machine freezing. (The
usual solution is to use a shadow framebuffer for the composition with a
blit (CAIRO_OPERATOR_SOURCE) onto the scanout for display.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From siarhei.siamashka at gmail.com Tue Nov 13 04:24:49 2012
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 13 Nov 2012 14:24:49 +0200
Subject: [cairo] Using cairo with image surface backend results hangs
system
In-Reply-To: <453bf0$6euri9@azsmga001.ch.intel.com>
References: <1352755886.4088.1518.camel@vulcan>
<453bf0$6euri9@azsmga001.ch.intel.com>
Message-ID: <20121113142449.71fafc13@i7>
On Tue, 13 Nov 2012 09:57:57 +0000
Chris Wilson wrote:
> On Mon, 12 Nov 2012 14:31:26 -0700, "Carl D. Blake" wrote:
> > I'm trying to use cairo with a DM8168 based system. I want to be able
> > to use it with the framebuffer so I've set it up to use the image
> > surface backend. I've mmaped the framebuffer to a memory location and
> > passed that as the data pointer to cairo_image_surface_create_for_data.
> > It appears to work for a while, but it always hangs the system at some
> > point when any drawing is being done (cairo_show_text or cairo_stroke).
> > I realize that cairo is drawing directly to the framebuffer, but I
> > didn't think this would be a problem. Am I doing something wrong here?
>
> It should work, Cairo should not generate out-of-bounds write or reads.
> So I would suggest something is going wrong at the hardware/driver level
> if the machine stops responding.
Based on the symptoms, looks like it could be "Advisory 1.1.38 NEON
Instructions Executed on a Non-Cached Memory-Mapped Address Result in
Lockup" described in
http://www.ti.com/lit/er/sprz329c/sprz329c.pdf
> However, I can not recommend that you use an UC or WC mapping for a
> Cairo surface, except for the final blit. Many of the operators that
> Cairo performs involve a readback from memory, which from a scanout will
> be very slow and may give the appearance of the machine freezing. (The
> usual solution is to use a shadow framebuffer for the composition with a
> blit (CAIRO_OPERATOR_SOURCE) onto the scanout for display.)
--
Best regards,
Siarhei Siamashka
From teknos at gmail.com Tue Nov 13 06:56:01 2012
From: teknos at gmail.com (=?UTF-8?Q?Zoz=C3=B3_Teki?=)
Date: Tue, 13 Nov 2012 15:56:01 +0100
Subject: [cairo] Win32 printing surfaces to EMF DCs
Message-ID:
Hi,
I want to use cario to draw to a Windows Enhanced Metafile. In Windows
metafiles have an associated _reference device context_ specific to a
concrete device. Otherwise metafiles are largely generic, in many ways
similar to cairo recording surfaces.
The easiest way to create an EMF file is to use the display as reference
context - it is always available. When cairo creates the printing surface,
it reads the Clip Box of the reference DC and uses that as extent. This way
I can only create EMFs as large as the screen. Is there some way I can
adjust the extent of a win32 printing surface?
Do you think it is a good idea to set the extents of win32 printing
surfaces created for metafiles to unbounded?
Zoltan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From carl at boeckeler.com Tue Nov 13 08:03:02 2012
From: carl at boeckeler.com (Carl D. Blake)
Date: Tue, 13 Nov 2012 09:03:02 -0700
Subject: [cairo] Using cairo with image surface backend results hangs
system
In-Reply-To: <20121113142449.71fafc13@i7>
References: <1352755886.4088.1518.camel@vulcan>
<453bf0$6euri9@azsmga001.ch.intel.com> <20121113142449.71fafc13@i7>
Message-ID: <1352822582.4088.1537.camel@vulcan>
I got it to work by disabling the simd and neon optimizations in the
pixman build, so it looks like Siarhei is correct and the neon
instructions were causing a lockup in non-cached memory.
>From what Chris said it sounds like I should make a shadow framebuffer
which is located in standard memory, perform all draws on that memory,
determine a rectangle which encompasses the draws that have been done,
and then do a final blit using that rectangle into the actual
framebuffer using CAIRO_OPERATOR_SOURCE. Would this actually improve
performance even though I will be duplicating memory writes for every
operation? I can do these blits with memcpy, but I wondered if pixman
would handle this better. Are there any examples available?
Carl
On Tue, 2012-11-13 at 14:24 +0200, Siarhei Siamashka wrote:
> On Tue, 13 Nov 2012 09:57:57 +0000
> Chris Wilson wrote:
>
> > On Mon, 12 Nov 2012 14:31:26 -0700, "Carl D. Blake" wrote:
> > > I'm trying to use cairo with a DM8168 based system. I want to be able
> > > to use it with the framebuffer so I've set it up to use the image
> > > surface backend. I've mmaped the framebuffer to a memory location and
> > > passed that as the data pointer to cairo_image_surface_create_for_data.
> > > It appears to work for a while, but it always hangs the system at some
> > > point when any drawing is being done (cairo_show_text or cairo_stroke).
> > > I realize that cairo is drawing directly to the framebuffer, but I
> > > didn't think this would be a problem. Am I doing something wrong here?
> >
> > It should work, Cairo should not generate out-of-bounds write or reads.
> > So I would suggest something is going wrong at the hardware/driver level
> > if the machine stops responding.
>
> Based on the symptoms, looks like it could be "Advisory 1.1.38 NEON
> Instructions Executed on a Non-Cached Memory-Mapped Address Result in
> Lockup" described in
> http://www.ti.com/lit/er/sprz329c/sprz329c.pdf
>
> > However, I can not recommend that you use an UC or WC mapping for a
> > Cairo surface, except for the final blit. Many of the operators that
> > Cairo performs involve a readback from memory, which from a scanout will
> > be very slow and may give the appearance of the machine freezing. (The
> > usual solution is to use a shadow framebuffer for the composition with a
> > blit (CAIRO_OPERATOR_SOURCE) onto the scanout for display.)
>
From fredbca21 at gmail.com Tue Nov 13 08:27:01 2012
From: fredbca21 at gmail.com (Fred bca21)
Date: Tue, 13 Nov 2012 17:27:01 +0100
Subject: [cairo] _cairo_win32_display_surface_map_to_image issue
Message-ID:
Hi,
while trying to fix a cairo crash on win32 (already posted on this
list), I am trying to understand the function below, and I can't
figure out how it works regarding coordinates (it looks inconsistent
to me):
- The first call to _cairo_win32_display_surface_create_for_dc
creates a surface with the appropriate with and height regarding the
extent rectangle.
- then why does the BitBlt call uses 0.0 as the origin for the source
surface and not the origin of the extent since the newly created
surface is supposed to represent the extent rectangle?
- Also, why does the _cairo_image_surface_map_to_image using our newly
created image does not use (0,0) as the origin, since our newly
created image's origin corresponds to (extents.x,extents.y) in the
original surface?
There is probaby something that I am missing, but this seems to be the
origin of the crash that I am chasing (this functions returns a
pointer outside of the image boundaries due to a wrong offset).
Thanks for your help.
(If it is not the right list to discuss such implementation details,
please forgive me and tell me where I should post)
Fred.
-----------
static cairo_surface_t *
_cairo_win32_display_surface_map_to_image (void
*abstract_surface,
const cairo_rectangle_int_t *extents)
{
cairo_win32_display_surface_t *surface = abstract_surface;
cairo_status_t status;
TRACE ((stderr, "%s (surface=%d)\n",
__FUNCTION__, surface->win32.base.unique_id));
if (surface->image)
goto done;
if (surface->fallback == NULL) {
surface->fallback =
_cairo_win32_display_surface_create_for_dc (surface->win32.dc,
surface->win32.format,
surface->win32.extents.width,
surface->win32.extents.height);
if (unlikely (status = surface->fallback->status))
goto err;
if (!BitBlt (to_win32_surface(surface->fallback)->dc,
0, 0,
surface->win32.extents.width,
surface->win32.extents.height,
surface->win32.dc,
0, 0,
SRCCOPY)) {
status = _cairo_error (CAIRO_STATUS_DEVICE_ERROR);
goto err;
}
}
surface = to_win32_display_surface (surface->fallback);
done:
GdiFlush();
return _cairo_image_surface_map_to_image (surface->image, extents);
From julian.viereck at googlemail.com Tue Nov 13 13:17:00 2012
From: julian.viereck at googlemail.com (Julian Viereck)
Date: Tue, 13 Nov 2012 22:17:00 +0100
Subject: [cairo] Reference counting of cairo free type face
In-Reply-To: <50A01FFA.1030200@gmail.com>
References: <50A01FFA.1030200@gmail.com>
Message-ID: <50A2B8CC.8060808@gmail.com>
Hi there,
I try to add font support to the node-canvas [1] library, which uses
cairo for rendering. I use the freetype2 library to load a font face and
then use it in cairo. The font rendering is working, but I got stuck on
memory management of the cairo font face. In particular, the cairo font
face's reference counter is not reset to 1 at the point I expect it to be.
Here's what I'm doing. I concentrate on the essential parts only. Let
"ref(cr_face)" be "cairo_font_face_get_reference_count(cr_face)" to get
the internal reference counter for the cairo font face.
// Create a free type font face from a font file.
FT_New_Face(library, *filePath, faceIdx, &ft_face);
// Create a cairo font face.
cr_face = cairo_ft_font_face_create_for_ft_face(ft_face, 0);
// At this point ref(cr_face) == 1.
// Set the cairo font face on a cairo rendering context.
cairo_set_font_face(ctx, cr_face);
// At this point ref(cr_face) == 2. I guess that's okay, as the
font is requird for rendering.
cairo_text_path(ctx, str);
// At this point ref(cr_face) == 4.
cairo_destroy(ctx);
// At this point ref(cr_face) == 3.
Shouldn't the reference count after the "cairo_destory" be 1 again and
the cairo font face deleted? Do I need to perform some manually cleanup
first?
Hope someone can help me out here and very best,
Julian
PS: I use cairo 1.12.8 and the freetype 2.4.10 library.
---
[1]: https://github.com/LearnBoost/node-canvas
From bfulgham at gmail.com Tue Nov 13 23:17:48 2012
From: bfulgham at gmail.com (Brent Fulgham)
Date: Tue, 13 Nov 2012 23:17:48 -0800
Subject: [cairo] Cairo WGL Implementation
In-Reply-To: <453bf0$6euri9@azsmga001.ch.intel.com>
References: <1352755886.4088.1518.camel@vulcan>
<453bf0$6euri9@azsmga001.ch.intel.com>
Message-ID:
I recently tried using the WGL support in Cairo and found that a number of changes were needed to get a functioning test running.
Are there any existing examples showing typical use of this target? It seems like this may have bit-rot a bit with the recent work on the GL backed.
Thanks,
-Brent
From chris at chris-wilson.co.uk Wed Nov 14 01:01:47 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Wed, 14 Nov 2012 09:01:47 +0000
Subject: [cairo] Reference counting of cairo free type face
In-Reply-To: <50A2B8CC.8060808@gmail.com>
References: <50A01FFA.1030200@gmail.com> <50A2B8CC.8060808@gmail.com>
Message-ID: <453bf0$6fdsjm@azsmga001.ch.intel.com>
On Tue, 13 Nov 2012 22:17:00 +0100, Julian Viereck wrote:
> Hi there,
>
> I try to add font support to the node-canvas [1] library, which uses
> cairo for rendering. I use the freetype2 library to load a font face and
> then use it in cairo. The font rendering is working, but I got stuck on
> memory management of the cairo font face. In particular, the cairo font
> face's reference counter is not reset to 1 at the point I expect it to be.
>
> Here's what I'm doing. I concentrate on the essential parts only. Let
> "ref(cr_face)" be "cairo_font_face_get_reference_count(cr_face)" to get
> the internal reference counter for the cairo font face.
>
> // Create a free type font face from a font file.
> FT_New_Face(library, *filePath, faceIdx, &ft_face);
> // Create a cairo font face.
> cr_face = cairo_ft_font_face_create_for_ft_face(ft_face, 0);
>
> // At this point ref(cr_face) == 1.
>
> // Set the cairo font face on a cairo rendering context.
> cairo_set_font_face(ctx, cr_face);
>
> // At this point ref(cr_face) == 2. I guess that's okay, as the
> font is requird for rendering.
>
> cairo_text_path(ctx, str);
>
> // At this point ref(cr_face) == 4.
>
> cairo_destroy(ctx);
>
> // At this point ref(cr_face) == 3.
>
> Shouldn't the reference count after the "cairo_destory" be 1 again and
> the cairo font face deleted? Do I need to perform some manually cleanup
> first?
Cairo maintains a holdover cache of the MRU scaled fonts (outside of any
context) which accounts for the extra references. The
cairo_font_face_finish() / cairo_scaled_font_finish() interface has been
proposed to decouple those extra references in a user-controllable way.
However, in order to hook into the destroy notification for when the
font is released you want to use cairo_scaled_font_set_user_data().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From julian.viereck at googlemail.com Wed Nov 14 06:43:02 2012
From: julian.viereck at googlemail.com (Julian Viereck)
Date: Wed, 14 Nov 2012 15:43:02 +0100
Subject: [cairo] Reference counting of cairo free type face
In-Reply-To: <453bf0$6fdsjm@azsmga001.ch.intel.com>
References: <50A01FFA.1030200@gmail.com> <50A2B8CC.8060808@gmail.com>
<453bf0$6fdsjm@azsmga001.ch.intel.com>
Message-ID: <50A3ADF6.6010508@gmail.com>
> Cairo maintains a holdover cache of the MRU scaled fonts (outside of any
> context) which accounts for the extra references. The
> cairo_font_face_finish() / cairo_scaled_font_finish() interface has been
> proposed to decouple those extra references in a user-controllable way.
> However, in order to hook into the destroy notification for when the
> font is released you want to use cairo_scaled_font_set_user_data().
Thanks a lot for this input Chris.
Is there an upper limit for the fonts being cached? If so, I wouldn't
bother to have some constant memory overhead for font faces that are no
longer needed.
Best,
Julian
On Wed Nov 14 10:01:47 2012, Chris Wilson wrote:
> On Tue, 13 Nov 2012 22:17:00 +0100, Julian Viereck wrote:
>> Hi there,
>>
>> I try to add font support to the node-canvas [1] library, which uses
>> cairo for rendering. I use the freetype2 library to load a font face and
>> then use it in cairo. The font rendering is working, but I got stuck on
>> memory management of the cairo font face. In particular, the cairo font
>> face's reference counter is not reset to 1 at the point I expect it to be.
>>
>> Here's what I'm doing. I concentrate on the essential parts only. Let
>> "ref(cr_face)" be "cairo_font_face_get_reference_count(cr_face)" to get
>> the internal reference counter for the cairo font face.
>>
>> // Create a free type font face from a font file.
>> FT_New_Face(library, *filePath, faceIdx, &ft_face);
>> // Create a cairo font face.
>> cr_face = cairo_ft_font_face_create_for_ft_face(ft_face, 0);
>>
>> // At this point ref(cr_face) == 1.
>>
>> // Set the cairo font face on a cairo rendering context.
>> cairo_set_font_face(ctx, cr_face);
>>
>> // At this point ref(cr_face) == 2. I guess that's okay, as the
>> font is requird for rendering.
>>
>> cairo_text_path(ctx, str);
>>
>> // At this point ref(cr_face) == 4.
>>
>> cairo_destroy(ctx);
>>
>> // At this point ref(cr_face) == 3.
>>
>> Shouldn't the reference count after the "cairo_destory" be 1 again and
>> the cairo font face deleted? Do I need to perform some manually cleanup
>> first?
>
> Cairo maintains a holdover cache of the MRU scaled fonts (outside of any
> context) which accounts for the extra references. The
> cairo_font_face_finish() / cairo_scaled_font_finish() interface has been
> proposed to decouple those extra references in a user-controllable way.
> However, in order to hook into the destroy notification for when the
> font is released you want to use cairo_scaled_font_set_user_data().
> -Chris
>
From psychon at znc.in Wed Nov 14 06:47:28 2012
From: psychon at znc.in (Uli Schlachter)
Date: Wed, 14 Nov 2012 15:47:28 +0100
Subject: [cairo] _cairo_win32_display_surface_map_to_image issue
In-Reply-To:
References:
Message-ID: <50A3AF00.2000907@znc.in>
Hi,
On 13.11.2012 17:27, Fred bca21 wrote:
> while trying to fix a cairo crash on win32 (already posted on this
> list), I am trying to understand the function below, and I can't
> figure out how it works regarding coordinates (it looks inconsistent
> to me):
First: We are in _cairo_win32_display_surface_map_to_image(). That wasn't
enirely clear to me from your mail.
> - The first call to _cairo_win32_display_surface_create_for_dc
> creates a surface with the appropriate with and height regarding the
> extent rectangle.
The extent rectangle of the win32 surface that we are looking at. So this
creates a surface of the same size as the already-existing surface that we are
working with.
> - then why does the BitBlt call uses 0.0 as the origin for the source
> surface and not the origin of the extent since the newly created
> surface is supposed to represent the extent rectangle?
A surface doesn't really have any origin which would matter here. This code
looks like it wants to copy the whole win32 surface to the newly created surface
created above. Thus, source and destination offset are both 0, 0.
Nothing touched the 'extents' argument of
_cairo_win32_display_surface_map_to_image() yet.
> - Also, why does the _cairo_image_surface_map_to_image using our newly
> created image does not use (0,0) as the origin, since our newly
> created image's origin corresponds to (extents.x,extents.y) in the
> original surface?
No, see above. The newly creates surface is as large as the original surface.
Nothing touched the "extents" argument yet.
> There is probaby something that I am missing, but this seems to be the
> origin of the crash that I am chasing (this functions returns a
> pointer outside of the image boundaries due to a wrong offset).
Could you give us some examples of the width, height, rowstrides, formats and
arguments for map_to_image used?
I am fairly sure that the image surface's map_to_image() works correctly. So if
this returns bogous pointers, then the image surface must have been fed with
bogous data.
> Thanks for your help.
One last idea: Do any of the involved surfaces have offsets applied? What is
their surface->device_transform? Is it all zero.
Cheers,
Uli
From chris at chris-wilson.co.uk Wed Nov 14 06:49:07 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Wed, 14 Nov 2012 14:49:07 +0000
Subject: [cairo] Reference counting of cairo free type face
In-Reply-To: <50A3ADF6.6010508@gmail.com>
References: <50A01FFA.1030200@gmail.com> <50A2B8CC.8060808@gmail.com>
<453bf0$6fdsjm@azsmga001.ch.intel.com> <50A3ADF6.6010508@gmail.com>
Message-ID: <6c3329$76rt6f@orsmga002.jf.intel.com>
On Wed, 14 Nov 2012 15:43:02 +0100, Julian Viereck wrote:
> Is there an upper limit for the fonts being cached? If so, I wouldn't
> bother to have some constant memory overhead for font faces that are no
> longer needed.
Only the last 16 freed fonts are kept in the holdover cache.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From pentdown at hotmail.com Wed Nov 14 22:17:55 2012
From: pentdown at hotmail.com (Pent Down)
Date: Thu, 15 Nov 2012 01:17:55 -0500
Subject: [cairo] Porting and licence question
Message-ID:
Hello,
I managed to port Cairo to Windows CE 6 and so far works great.
My question is if I am allowed to include it in a commercial application for which I am not allowed to distribute the code?
Yes, I had to make small changes (few files,) nothing major.
Thank You
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From chris at chris-wilson.co.uk Thu Nov 15 01:48:19 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Thu, 15 Nov 2012 09:48:19 +0000
Subject: [cairo] Porting and licence question
In-Reply-To:
References:
Message-ID: <275ffc$7dsp0j@fmsmga002.fm.intel.com>
On Thu, 15 Nov 2012 01:17:55 -0500, Pent Down wrote:
>
>
> Hello,
> I managed to port Cairo to Windows CE 6 and so far works great.
> My question is if I am allowed to include it in a commercial application for which I am not allowed to distribute the code?
> Yes, I had to make small changes (few files,) nothing major.
Yes, you may under the Mozilla Public Licence, which allows you to
combine Cairo into any larger piece of work (without imposing licensing
terms on the larger work). The essential requirement (please do read
COPYING-MPL-1-1) is that any modifications you make to *Cairo* are made
available to everyone you distribute your version to.
Alternatively you may choose to use the GNU Lesser General Public
Licence, which has stricter requirements on how you can combine the
pieces of work into the distributable whole (without making the larger
body of work a derivative) and for making and maintaining modifications
to Cairo. Read COPYING-LGPL-2.1 for the full details.
Have fun using Cairo! Please do let us know how you get on and of any
little changes you make.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From fredbca21 at gmail.com Thu Nov 15 05:16:43 2012
From: fredbca21 at gmail.com (Fred Beca)
Date: Thu, 15 Nov 2012 14:16:43 +0100
Subject: [cairo] _cairo_win32_display_surface_map_to_image issue
In-Reply-To: <50A3AF00.2000907@znc.in>
References:
<50A3AF00.2000907@znc.in>
Message-ID:
Hi Uli,
Thanks for the reply, it's very helpful. I' ll double check the bits
you are talking about asap. Just for the record, a simple code snippet
is available in this post to easily reproduce the problem on windows:
http://lists.cairographics.org/archives/cairo/2012-November/023728.html
The function may indeed be fed by bogus data, and that's exaclty what
I am trying to find out, with my little knowledge of the library:
where and how is the data somehow corrupted?
Regards,
Fred.
On Wed, Nov 14, 2012 at 3:47 PM, Uli Schlachter wrote:
> Hi,
>
>
> On 13.11.2012 17:27, Fred bca21 wrote:
>>
>> while trying to fix a cairo crash on win32 (already posted on this
>> list), I am trying to understand the function below, and I can't
>> figure out how it works regarding coordinates (it looks inconsistent
>> to me):
>
>
> First: We are in _cairo_win32_display_surface_map_to_image(). That wasn't
> enirely clear to me from your mail.
>
>
>> - The first call to _cairo_win32_display_surface_create_for_dc
>> creates a surface with the appropriate with and height regarding the
>> extent rectangle.
>
>
> The extent rectangle of the win32 surface that we are looking at. So this
> creates a surface of the same size as the already-existing surface that we
> are working with.
>
>
>> - then why does the BitBlt call uses 0.0 as the origin for the source
>> surface and not the origin of the extent since the newly created
>> surface is supposed to represent the extent rectangle?
>
>
> A surface doesn't really have any origin which would matter here. This code
> looks like it wants to copy the whole win32 surface to the newly created
> surface created above. Thus, source and destination offset are both 0, 0.
>
> Nothing touched the 'extents' argument of
> _cairo_win32_display_surface_map_to_image() yet.
>
>
>> - Also, why does the _cairo_image_surface_map_to_image using our newly
>> created image does not use (0,0) as the origin, since our newly
>> created image's origin corresponds to (extents.x,extents.y) in the
>> original surface?
>
>
> No, see above. The newly creates surface is as large as the original
> surface. Nothing touched the "extents" argument yet.
>
>
>> There is probaby something that I am missing, but this seems to be the
>> origin of the crash that I am chasing (this functions returns a
>> pointer outside of the image boundaries due to a wrong offset).
>
>
> Could you give us some examples of the width, height, rowstrides, formats
> and arguments for map_to_image used?
>
> I am fairly sure that the image surface's map_to_image() works correctly. So
> if this returns bogous pointers, then the image surface must have been fed
> with bogous data.
>
>> Thanks for your help.
>
>
> One last idea: Do any of the involved surfaces have offsets applied? What is
> their surface->device_transform? Is it all zero.
>
> Cheers,
> Uli
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
From psychon at znc.in Thu Nov 15 07:37:11 2012
From: psychon at znc.in (Uli Schlachter)
Date: Thu, 15 Nov 2012 16:37:11 +0100
Subject: [cairo] _cairo_win32_display_surface_map_to_image issue
In-Reply-To:
References:
<50A3AF00.2000907@znc.in>
Message-ID: <50A50C27.9010104@znc.in>
Hi,
On 15.11.2012 14:16, Fred Beca wrote:
> Thanks for the reply, it's very helpful. I' ll double check the bits
> you are talking about asap. Just for the record, a simple code snippet
> is available in this post to easily reproduce the problem on windows:
> http://lists.cairographics.org/archives/cairo/2012-November/023728.html
Sorr
> The function may indeed be fed by bogus data, and that's exaclty what
> I am trying to find out, with my little knowledge of the library:
> where and how is the data somehow corrupted?
From psychon at znc.in Thu Nov 15 07:40:23 2012
From: psychon at znc.in (Uli Schlachter)
Date: Thu, 15 Nov 2012 16:40:23 +0100
Subject: [cairo] _cairo_win32_display_surface_map_to_image issue
In-Reply-To:
References:
<50A3AF00.2000907@znc.in>
Message-ID: <50A50CE7.1000408@znc.in>
Hi,
first: Sorry for my fat fingers. :-(
On 15.11.2012 14:16, Fred Beca wrote:
> Thanks for the reply, it's very helpful. I' ll double check the bits
> you are talking about asap. Just for the record, a simple code snippet
> is available in this post to easily reproduce the problem on windows:
> http://lists.cairographics.org/archives/cairo/2012-November/023728.html
Sorry, but I don't have access to any windows boxes.
> The function may indeed be fed by bogus data, and that's exaclty what
> I am trying to find out, with my little knowledge of the library:
> where and how is the data somehow corrupted?
I'm not really sure that the data gets corrupted. It seems more likely to me
that some GDI function doesn't behave as expected or has a different
interpretation of some parameter. That could mean that e.g. too few bytes are
allocated for the image surface and things go downhill when cairo/pixman try to
access the bytes near the end of the image surface.
Uli
From fredbca21 at gmail.com Thu Nov 15 08:05:58 2012
From: fredbca21 at gmail.com (Fred Beca)
Date: Thu, 15 Nov 2012 17:05:58 +0100
Subject: [cairo] _cairo_win32_display_surface_map_to_image issue
In-Reply-To: <50A50CE7.1000408@znc.in>
References:
<50A3AF00.2000907@znc.in>
<50A50CE7.1000408@znc.in>
Message-ID:
> I'm not really sure that the data gets corrupted. It seems more likely to me
> that some GDI function doesn't behave as expected or has a different
> interpretation of some parameter. That could mean that e.g. too few bytes
> are allocated for the image surface and things go downhill when cairo/pixman
> try to access the bytes near the end of the image surface.
If you look at the details of my previous report, the crash indeed
occurs in a cairo function: data is not exactly "corrupted", but the
offset in the pixman image used for backing is wrong (the offset seems
to be applied twice. The problem for me is to find where it comes
from). I have not seen (yet) any GDI call in the path.
The problem seems to come from the fact that the backing image is
created with the dimensions of the clipping rectangle, and yet it is
considered as covering the entire original area of the HBITMAP.
Regards,
Fred.
From dy5.kim at samsung.com Thu Nov 15 21:45:18 2012
From: dy5.kim at samsung.com (Dongyeon Kim)
Date: Fri, 16 Nov 2012 05:45:18 +0000 (GMT)
Subject: [cairo] [PATCH] gl: Draw image surface to fbo gl surface using
intermediate texture
Message-ID: <27673201.227161353044717987.JavaMail.weblogic@epv6ml02>
Hello,
When I create an image surface from png, and use this surface as source to paint to cairo gl surface that is created using FBO, the resulting gl surface is just black.
I have spent some time investigating this, and found that cairo was uploading data to the texture that is currently being used as target framebuffer.
To fix this problem, image data should be uploaded to an intermediate texture, and this texture should be rendered into the FBO.
The following patch is a suggested fix for both gl-spans and gl-traps compositors.
Thanks
From cfad0e1ea8e36bc1351c44c2358ef6bb400a0f26 Mon Sep 17 00:00:00 2001
From: Dongyeon Kim
Date: Fri, 16 Nov 2012 14:29:50 +0900
Subject: [PATCH] gl: Draw image surface to fbo gl surface using intermediate texture
When gl surface is created using fbo, you cannot upload image data
directly into framebuffer-attached texture.
Image data should be uploaded to an intermediate texture, and
this texture should be rendered into the fbo.
---
src/cairo-gl-spans-compositor.c | 3 +++
src/cairo-gl-traps-compositor.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/cairo-gl-spans-compositor.c b/src/cairo-gl-spans-compositor.c
index 62da1eb..968bc4c 100644
--- a/src/cairo-gl-spans-compositor.c
+++ b/src/cairo-gl-spans-compositor.c
@@ -291,6 +291,9 @@ draw_image_boxes (void *_dst,
struct _cairo_boxes_chunk *chunk;
int i;
+ if (_cairo_gl_surface_is_texture (dst))
+ return CAIRO_INT_STATUS_UNSUPPORTED;
+
for (chunk = &boxes->chunks; chunk; chunk = chunk->next) {
for (i = 0; i < chunk->count; i++) {
cairo_box_t *b = &chunk->base[i];
diff --git a/src/cairo-gl-traps-compositor.c b/src/cairo-gl-traps-compositor.c
index 4bae0d1..a1ba69b 100644
--- a/src/cairo-gl-traps-compositor.c
+++ b/src/cairo-gl-traps-compositor.c
@@ -84,6 +84,9 @@ draw_image_boxes (void *_dst,
struct _cairo_boxes_chunk *chunk;
int i;
+ if (_cairo_gl_surface_is_texture (dst))
+ return CAIRO_INT_STATUS_UNSUPPORTED;
+
for (chunk = &boxes->chunks; chunk; chunk = chunk->next) {
for (i = 0; i < chunk->count; i++) {
cairo_box_t *b = &chunk->base[i];
--
1.7.5.4
From eric at anholt.net Thu Nov 15 22:42:40 2012
From: eric at anholt.net (Eric Anholt)
Date: Thu, 15 Nov 2012 22:42:40 -0800
Subject: [cairo] [PATCH] gl: Draw image surface to fbo gl surface using
intermediate texture
In-Reply-To: <27673201.227161353044717987.JavaMail.weblogic@epv6ml02>
References: <27673201.227161353044717987.JavaMail.weblogic@epv6ml02>
Message-ID: <87pq3edp5r.fsf@eliezer.anholt.net>
Dongyeon Kim writes:
> Hello,
>
> When I create an image surface from png, and use this surface as
> source to paint to cairo gl surface that is created using FBO, the
> resulting gl surface is just black.
>
> I have spent some time investigating this, and found that cairo was
> uploading data to the texture that is currently being used as target
> framebuffer.
>
> To fix this problem, image data should be uploaded to an intermediate
> texture, and this texture should be rendered into the FBO.
>
> The following patch is a suggested fix for both gl-spans and gl-traps
> compositors.
Huh? Using glTexImage to set the contents of an FBO sounds perfectly
legal and should have expected behavior. This sounds like a driver bug.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From dy5.kim at samsung.com Thu Nov 15 23:51:51 2012
From: dy5.kim at samsung.com (Dongyeon Kim)
Date: Fri, 16 Nov 2012 07:51:51 +0000 (GMT)
Subject: [cairo] [PATCH] gl: Draw image surface to fbo gl surface using
intermediate texture
Message-ID: <2655770.241821353052310922.JavaMail.weblogic@epv6ml02>
It is fine to set the FBO content using glTex(Sub)Image2D before the texture is bound to the framebuffer.
But what the current implementation does is that after the texture has been bound to the framebuffer to be
the rendering target, cairo again binds the same texture as the rendering source and uploads data.
As I know this falls into a rendering feedback loop.
According to the OpenGL ES spec, a feedback loop may exist when a texture object is used as both the source and
destination of a GL operation, and when a feedback loop exists, undefined behavior results.
I will check again whether this is the driver-specific issue.
Thanks
------- Original Message -------
Sender : Eric Anholt
Date : 2012-11-16 15:42 (GMT+09:00)
Title : Re: [cairo] [PATCH] gl: Draw image surface to fbo gl surface using intermediate texture
Dongyeon Kim writes:
> Hello,
>
> When I create an image surface from png, and use this surface as
> source to paint to cairo gl surface that is created using FBO, the
> resulting gl surface is just black.
>
> I have spent some time investigating this, and found that cairo was
> uploading data to the texture that is currently being used as target
> framebuffer.
>
> To fix this problem, image data should be uploaded to an intermediate
> texture, and this texture should be rendered into the FBO.
>
> The following patch is a suggested fix for both gl-spans and gl-traps
> compositors.
Huh? Using glTexImage to set the contents of an FBO sounds perfectly
legal and should have expected behavior. This sounds like a driver bug.
From ajax at redhat.com Fri Nov 16 10:04:48 2012
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 16 Nov 2012 13:04:48 -0500
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <509BE9A2.2000209@redhat.com>
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
<509BE9A2.2000209@redhat.com>
Message-ID: <1353089088.21005.55.camel@atropine>
On Thu, 2012-11-08 at 12:19 -0500, Adam Jackson wrote:
> On 10/31/12 4:13 PM, Adam Jackson wrote:
> > malloc(0) needn't return NULL, and on glibc, doesn't. Then we encounter
> > a loop of the form do { ... } while (--c), which doesn't do quite what
> > you were hoping for when c is initially 0.
> >
> > Since there's nothing to swap in this case, just bomb out.
>
> Bump. Anything else I need to add here?
Another week, another ping.
- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
From eric at anholt.net Fri Nov 16 10:44:44 2012
From: eric at anholt.net (Eric Anholt)
Date: Fri, 16 Nov 2012 10:44:44 -0800
Subject: [cairo] [PATCH] gl: Draw image surface to fbo gl surface using
intermediate texture
In-Reply-To: <2655770.241821353052310922.JavaMail.weblogic@epv6ml02>
References: <2655770.241821353052310922.JavaMail.weblogic@epv6ml02>
Message-ID: <87k3tlcrqb.fsf@eliezer.anholt.net>
Dongyeon Kim writes:
> It is fine to set the FBO content using glTex(Sub)Image2D before the
> texture is bound to the framebuffer. But what the current
> implementation does is that after the texture has been bound to the
> framebuffer to be the rendering target, cairo again binds the same
> texture as the rendering source and uploads data. As I know this
> falls into a rendering feedback loop.
>
> According to the OpenGL ES spec, a feedback loop may exist when a
> texture object is used as both the source and destination of a GL
> operation, and when a feedback loop exists, undefined behavior
> results.
>
> I will check again whether this is the driver-specific issue.
> Thanks
The patch you sent didn't appear to be about avoiding feedback loops (a
feedback loop, to be clear, is having an fbo with a texture and doing a
draw call like glDrawArrays that samples from the same texture), it just
avoided these paths on texture-backed surface entirely.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From psychon at znc.in Fri Nov 16 10:59:52 2012
From: psychon at znc.in (Uli Schlachter)
Date: Fri, 16 Nov 2012 19:59:52 +0100
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <1353089088.21005.55.camel@atropine>
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
<509BE9A2.2000209@redhat.com> <1353089088.21005.55.camel@atropine>
Message-ID: <50A68D28.2030001@znc.in>
On 16.11.2012 19:04, Adam Jackson wrote:
> On Thu, 2012-11-08 at 12:19 -0500, Adam Jackson wrote:
>> On 10/31/12 4:13 PM, Adam Jackson wrote:
>>> malloc(0) needn't return NULL, and on glibc, doesn't. Then we encounter
>>> a loop of the form do { ... } while (--c), which doesn't do quite what
>>> you were hoping for when c is initially 0.
>>>
>>> Since there's nothing to swap in this case, just bomb out.
>>
>> Bump. Anything else I need to add here?
>
> Another week, another ping.
Pong :-P
I haven't forgotten this patch. However, I have no clue what the original
"server crashes on 0x0 glyphs" bug is about nor if we want to keep the
work-around for that. My hope is that the almighty Chris could help us here.
Also, I would like to see a test case for this. Dunno if that would need
user-fonts or if it could be done via drawing " "...
Cheers,
Uli
--
If you have to type the letters "A-E-S" into your source code, you're doing it
wrong.
From ajax at redhat.com Fri Nov 16 13:27:07 2012
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 16 Nov 2012 16:27:07 -0500
Subject: [cairo] [PATCH 1/2] xlib: Don't crash when swapping a 0-sized
glyph
In-Reply-To: <50A68D28.2030001@znc.in>
References: <1351714426-14768-1-git-send-email-ajax@redhat.com>
<509BE9A2.2000209@redhat.com> <1353089088.21005.55.camel@atropine>
<50A68D28.2030001@znc.in>
Message-ID: <1353101227.21005.67.camel@atropine>
On Fri, 2012-11-16 at 19:59 +0100, Uli Schlachter wrote:
> I haven't forgotten this patch. However, I have no clue what the original
> "server crashes on 0x0 glyphs" bug is about nor if we want to keep the
> work-around for that. My hope is that the almighty Chris could help us here.
The original server bug was this, I believe:
http://cgit.freedesktop.org/xorg/xserver/commit/render/render.c?id=622fc98fd08aba98369e6933c3ab8c9ff85385d5
~/xserver% git describe --contains 622fc98fd08aba98369e6933c3ab8c9ff85385d5
xorg-server-1.7.99.1~63
_cairo_xlib_traps_compositor_get() gets called if the render version is
>= 0.4; given that 0.5 was when ARGB cursors were added, that's
somewhere back in the XFree86 era. So presumably this path is indeed
broken for sufficiently old xserver. Naughty, introducing a regression
like that.
I can come up with a testcase I suppose, but it will likely be sometime
after the upcoming holiday as I'll be travelling a bit.
- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
From mellamanjefe at gmail.com Mon Nov 19 11:29:02 2012
From: mellamanjefe at gmail.com (Marco Quezada)
Date: Mon, 19 Nov 2012 14:29:02 -0500
Subject: [cairo] Why would cairo_font/text_extents() return blank?
Message-ID:
I am debuggin some code given to me that is using cairo as its graphics
drawing context with a xlib surface. The code crashed at a line that
divides a number by the font x_advance except that this number is 0.
I have a valid cairo_context instantiated and drawing to it works. I can
also call cairo_get_font_face() passing the same valid cairo context and I
get what looks like valid memory back (my cairo does not have debugging
information built in so I can't look into the cairo_font_face_t pointer).
If I call cairo_font/text_extents() right after the context is instantiated
I get good looking values (non are zero). Then some more initialization of
the application goes on and finally I call cairo_font/text_extents later on
and the values in the returned extents are all zero. Is it possible to
"unset" the font in cairo? What else might cause this behavior? At the
point where the code returns the zeroed extents I tried getting the font
matrix and the application segfaulted. I don't know if that is relevant to
my problem or not, I was using it to try and debug my problem.
Thanks!
-Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jeongjoon.yoo at gmail.com Tue Nov 20 16:55:54 2012
From: jeongjoon.yoo at gmail.com (Jeong-Joon Yoo)
Date: Wed, 21 Nov 2012 09:55:54 +0900
Subject: [cairo] working properly "_cairo_fixed_from_double (double d)" in
single precision
Message-ID:
Dear all,
The following function, shown in cairo-fixed-private.h, does not work
properly because our cpu provides only a single precision.
_cairo_fixed_from_double (double d)
What can I do to fix it?
(our cpu: single precision, little-endian)
Thank you in advance.
- jjyoo
From genetita at gmail.com Wed Nov 21 00:27:23 2012
From: genetita at gmail.com (=?ISO-8859-1?Q?Carlos_L=F3pez_Gonz=E1lez?=)
Date: Wed, 21 Nov 2012 09:27:23 +0100
Subject: [cairo] Cairo Push/Pop and pattern result
Message-ID:
Hi!
I'm very confused with the results of the code that I'm doing and at the
same time the documentation doesn't explain properly the behavior of the
Cairo functions used.
First let me explain what I'm doing (or trying to do):
I need to create a function that composite the primitives with the target
surface using a non native composite operator (I call it BlendMethod).
For that I do this (pseudo code):
Parameters: cairo_t* cr, BlendMethod method, float alpha
Function:
1) Based on method select portions of code with switch.
2) Draw the cairo context to other surface (source)
3) Map the source surface and the target surface to image
4) Do pixel operations based on method. Store the result in source.
5) Unmap source and target back.
6) Composite source over target using the ATOP cairo blend operation and
cairo_paint_with alpha using alpha.
Here is the code section for that (lines 183 to 233):
https://github.com/synfig/synfig/blob/genete_new_cairo_core_2/synfig-core/src/synfig/cairo_operators.cpp#L183
There are some significant things there:
1) I need to calculate the clip extents and then transform them to properly
access the target pixels and combine them with the source pixels. Lines
202-220
2) I need to reset clip and set matrix identity on cr to properly composite
the source on the target lines 224 to 225.
My question are:
1) The surface extracted from the pattern of a push/pop operation does
somehow carry on with the transformations of the cairo context?
2) How it is possible that setting a source surface on the top left corner
(0, 0) it is placed properly on its clipping user to device place?
3) It is possible to use the matrix from pattern to properly calculate the
target pixels that are going to be combined with the source surface?
(instead of the cr clip extents)
Greetings and thanks.
--
Carlos
http://synfig.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From martin at duskware.de Wed Nov 21 00:35:50 2012
From: martin at duskware.de (Martin Husemann)
Date: Wed, 21 Nov 2012 09:35:50 +0100
Subject: [cairo] working properly "_cairo_fixed_from_double (double d)"
in single precision
In-Reply-To:
References:
Message-ID: <20121121083550.GA14056@mail.duskware.de>
On Wed, Nov 21, 2012 at 09:55:54AM +0900, Jeong-Joon Yoo wrote:
> Dear all,
>
> The following function, shown in cairo-fixed-private.h, does not work
> properly because our cpu provides only a single precision.
>
> _cairo_fixed_from_double (double d)
>
> What can I do to fix it?
Your compiler is free to alias double == float.
Martin
From xiaolin.ji at intel.com Wed Nov 21 11:58:41 2012
From: xiaolin.ji at intel.com (xiaolin.ji at intel.com)
Date: Wed, 21 Nov 2012 14:58:41 -0500
Subject: [cairo] [PATCH] BugFix the tighten-bounds with egl backend
Message-ID: <1353527921-2852-1-git-send-email-xiaolin.ji@intel.com>
From: xiaolin.ji
I tested tighten-bounds with egl backend at my sandybridge, it failed. when fill_boxes with the boxes which create from "_cairo_boxes_init_from_rectangle", the boxes->chunks.count is zero, it will do nothing when emit the aligned boxes
---
src/cairo-boxes.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/cairo-boxes.c b/src/cairo-boxes.c
index 63b68dd..b96b4b8 100644
--- a/src/cairo-boxes.c
+++ b/src/cairo-boxes.c
@@ -57,10 +57,18 @@ void
_cairo_boxes_init_from_rectangle (cairo_boxes_t *boxes,
int x, int y, int w, int h)
{
+ cairo_box_t box;
+ cairo_int_status_t status;
+
_cairo_boxes_init (boxes);
+
+ box.p1.x = _cairo_fixed_from_int (x);
+ box.p1.y = _cairo_fixed_from_int (y);
+ box.p2.x = _cairo_fixed_from_int (x + w);
+ box.p2.y = _cairo_fixed_from_int (y + h);
- _cairo_box_from_integers (&boxes->chunks.base[0], x, y, w, h);
- boxes->num_boxes = 1;
+ status = _cairo_boxes_add (boxes, CAIRO_ANTIALIAS_DEFAULT, &box);
+ assert (status == CAIRO_INT_STATUS_SUCCESS);
}
void
--
1.7.10.4
From hanscusco at hotmail.com Wed Nov 21 09:14:19 2012
From: hanscusco at hotmail.com (John)
Date: Wed, 21 Nov 2012 17:14:19 +0000 (UTC)
Subject: [cairo] How to load a BMP/JPG/TGA to a Surface?
References: <913525.50130.qm@web76206.mail.sg1.yahoo.com>
Message-ID:
Jonathan Morton movial.com> writes:
> It looks to me as though BLoad has included the BMP header in the
> block of data it loaded. I would talk to FreeBASIC people about that.
>
> - Jonathan Morton
As a FreeBasic user, I can reply to that. FreeBASIC's BLoad does not include the
BMP header, but it prepends its own header, which is either 4 bytes or 32 bytes
(depending on the version resp. the language option you are using; the newer
versions use 32 bytes). This may explain the offset on your image. So try to
find out if your version uses the 4-byte or the 32-byte header, and then start
to read the pixel data after that header.
From behdad at behdad.org Thu Nov 22 14:13:35 2012
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 22 Nov 2012 17:13:35 -0500
Subject: [cairo] "High-DPI, Subpixel Text Positioning, Hinting"
Message-ID: <50AEA38F.5030605@behdad.org>
[Excuse my cross-lists posting]
A while back I wrote a document about the interactions of high-density
displays and font rendering options. I just went ahead and made it public,
so, enjoy!
http://goo.gl/yf3M7
--
behdad
http://behdad.org/
From sandmann at cs.au.dk Fri Nov 23 19:57:22 2012
From: sandmann at cs.au.dk (=?utf-8?Q?S=C3=B8ren?= Sandmann)
Date: Sat, 24 Nov 2012 04:57:22 +0100
Subject: [cairo] Image resampling [PATCH 0/6]
Message-ID:
Hi,
Reviewing the supersampling patch here:
http://cgit.freedesktop.org/~ajohnson/pixman/log/?h=supersampling
I wasn't happy with either the performance and image quality, and I
realized that the whole supersampling approach just isn't going to
fly. Since I told people to do it that way, I apologize for that. The
approach advocated by Bill Spitzak in the various downsampling threads
of computing a convolution kernel up front, is the much better way to
go. To make up for being misleading, the following patches implement
comprehensive support for high-quality image scaling filters.
Pixman already has a convolution filter, but since it only allows one
sample per pixel of the filter, it is limited in the quality that it can
support, so the following patches (to be applied on top of the three
rounding patches) add a new filter type
PIXMAN_FILTER_SEPARABLE_CONVOLUTION
that supports multiple different convolution matrices that are chosen
between based on the subpixel source location. The matrices are
specified as tensor products of x/y vectors, which makes them
separable by definition.
The patches also add a helper function
pixman_filter_create_separable_convolution()
that will create the parameters for the filter based on scaling
factors, filter kernels and subsampling resolution. Currently the
supported kernels are impulse, box, linear, cubic
(Mitchell-Netravali), lanczos2, lanczos3, lanczos3_stretched
(aka. Blinn's 'Nice' filter), and Gaussian.
There also a new demo program "demos/scale" that shows how
the new API can be used.
For some useful math regarding image transformations, see
http://people.redhat.com/otaylor/gtk/pixbuf-transform-math.ps . For
some informatino about how to compute the convolution matrices, see
the additions to rounding.txt in the second patch.
-=- Adding support to cairo and further work
Once these patches have landed in Pixman, support will have to be
added to cairo to make use of them. How to do that exactly requires
figuring out what new API to offer, and how the tradeoffs between
performance and quality should be made. This is not something that I
personally plan to work on anytime soon, except to make three notes:
- While transformations that are not pure scalings will not
generally result in a separable filter, OK-looking results for
non-scalings can be achieved by using scaling factors based on the
bounding box of a transformation
- For equivalent quality to GdkPixbuf do this: In each direction
compute the scaling factors and then, if the scaling factor is
less than 1 (ie., a downscaling), use PIXMAN_KERNEL_BOX for both
reconstruction and sampling, and if it's greater than one, use
PIXMAN_KERNEL_LINEAR for reconstruction and PIXMAN_KERNEL_IMPULSE
for sampling.
- If PIXMAN_KERNEL_GAUSSIAN is used with large downscaling factors
and the resulting filter is then used with an identity transform,
the result is a Gaussian blur, which is a feature that has
sometimes been requested.
The code in demos/scale.c may be useful as an example.
-=- Further work and examples
There is some additional work that could be done:
- Performance improvements. Low-hanging fruit includes adding new fast
path iterators that assume the source is a8r8g8b8 or r5g6b5. Higher
hanging fruit is SIMD optimziations and implementations that take
advantage of separability. It may also be interesting to speed up
pixman_filter_create_separable_convolution() by tabularizing some of
the trigonometric functions etc.
- A non-separable, but subsampled, convolution filter type could be
interesting to allow correct filters for non-scaling transformations
and non-separable filters in general.
As a reward for reading this entire mail, here are some images:
Original (2.6 MB):
http://www.daimi.au.dk/~sandmann/house.jpg
Scaled down 12.9 times in each dimension:
- With a box filter:
http://www.daimi.au.dk/~sandmann/house-box.png
- With Lanczos3:
http://www.daimi.au.dk/~sandmann/house-lanczos3.png
- With stretched Lanczos3:
http://www.daimi.au.dk/~sandmann/house-nice.png
For more examples, try demos/scale.
The patch series is also available in this repository:
http://cgit.freedesktop.org/~sandmann/pixman/log/?h=separable
Soren
From sandmann at cs.au.dk Fri Nov 23 20:15:26 2012
From: sandmann at cs.au.dk (=?UTF-8?q?S=C3=B8ren=20Sandmann?=)
Date: Fri, 23 Nov 2012 23:15:26 -0500
Subject: [cairo] [PATCH 1/6] Add new filter
PIXMAN_FILTER_SEPARABLE_CONVOLUTION
In-Reply-To:
References:
Message-ID: <1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
From: S?ren Sandmann Pedersen
This filter is a new way to use a convolution matrix for filtering. In
contrast to the existing CONVOLUTION filter, this new variant is
different in two respects:
- It is subsampled: Instead of just one convolution matrix, this
filter chooses between a number of matrices based on the subpixel
sample location, allowing the convolution kernel to be sampled at a
higher resolution.
- It is separable: Each matrix is specified as the tensor product of
two vectors. This has the advantages that many fewer values have to
be stored, and that the filtering can be done separately in the x
and y dimensions (although the initial implementation doesn't
actually do that).
The motivation for this new filter is to improve image downsampling
quality. Currently, the best pixman can do is the regular convolution
filter which is limited to coarsely sampled convolution kernels.
With this new feature, any separable filter can be used at any desired
resolution.
---
pixman/pixman-bits-image.c | 102 ++++++++++++++++++++++++++++++++++++++++++++
pixman/pixman-image.c | 19 +++++++-
pixman/pixman.c | 8 +++
pixman/pixman.h | 23 +++++++++-
4 files changed, 149 insertions(+), 3 deletions(-)
diff --git a/pixman/pixman-bits-image.c b/pixman/pixman-bits-image.c
index 7787ef1..97db108 100644
--- a/pixman/pixman-bits-image.c
+++ b/pixman/pixman-bits-image.c
@@ -426,6 +426,104 @@ bits_image_fetch_pixel_convolution (bits_image_t *image,
return ((satot << 24) | (srtot << 16) | (sgtot << 8) | (sbtot));
}
+static uint32_t
+bits_image_fetch_pixel_convolution_separable (bits_image_t *image,
+ pixman_fixed_t x,
+ pixman_fixed_t y,
+ get_pixel_t get_pixel)
+{
+ pixman_fixed_t *params = image->common.filter_params;
+ pixman_repeat_t repeat_mode = image->common.repeat;
+ int width = image->width;
+ int height = image->height;
+ int cwidth = pixman_fixed_to_int (params[0]);
+ int cheight = pixman_fixed_to_int (params[1]);
+ int x_phase_bits = pixman_fixed_to_int (params[2]);
+ int y_phase_bits = pixman_fixed_to_int (params[3]);
+ int x_phase_shift = 16 - x_phase_bits;
+ int y_phase_shift = 16 - y_phase_bits;
+ int x_off = ((cwidth << 16) - pixman_fixed_1) >> 1;
+ int y_off = ((cheight << 16) - pixman_fixed_1) >> 1;
+ pixman_fixed_t *y_params;
+ int srtot, sgtot, sbtot, satot;
+ int32_t x1, x2, y1, y2;
+ int32_t px, py;
+ int i, j;
+
+ /* Round x and y to the middle of the closest phase before continuing. This
+ * ensures that the convolution matrix is aligned right, since it was
+ * positioned relative to a particular phase (and not relative to whatever
+ * exact fraction we happen to get here).
+ */
+ x = ((x >> x_phase_shift) << x_phase_shift) + ((1 << x_phase_shift) >> 1);
+ y = ((y >> y_phase_shift) << y_phase_shift) + ((1 << y_phase_shift) >> 1);
+
+ px = (x & 0xffff) >> x_phase_shift;
+ py = (y & 0xffff) >> y_phase_shift;
+
+ y_params = params + 4 + (1 << x_phase_bits) * cwidth + py * cheight;
+
+ x1 = pixman_fixed_to_int (x - pixman_fixed_e - x_off);
+ y1 = pixman_fixed_to_int (y - pixman_fixed_e - y_off);
+ x2 = x1 + cwidth;
+ y2 = y1 + cheight;
+
+ srtot = sgtot = sbtot = satot = 0;
+
+ for (i = y1; i < y2; ++i)
+ {
+ pixman_fixed_48_16_t fy = *y_params++;
+ pixman_fixed_t *x_params = params + 4 + px * cwidth;
+
+ if (fy)
+ {
+ for (j = x1; j < x2; ++j)
+ {
+ pixman_fixed_t fx = *x_params++;
+ int rx = j;
+ int ry = i;
+
+ if (fx)
+ {
+ pixman_fixed_t f;
+ uint32_t pixel;
+
+ if (repeat_mode != PIXMAN_REPEAT_NONE)
+ {
+ repeat (repeat_mode, &rx, width);
+ repeat (repeat_mode, &ry, height);
+
+ pixel = get_pixel (image, rx, ry, FALSE);
+ }
+ else
+ {
+ pixel = get_pixel (image, rx, ry, TRUE);
+ }
+
+ f = (fy * fx + 0x8000) >> 16;
+
+ srtot += (int)RED_8 (pixel) * f;
+ sgtot += (int)GREEN_8 (pixel) * f;
+ sbtot += (int)BLUE_8 (pixel) * f;
+ satot += (int)ALPHA_8 (pixel) * f;
+ }
+ }
+ }
+ }
+
+ satot = (satot + 0x8000) >> 16;
+ srtot = (srtot + 0x8000) >> 16;
+ sgtot = (sgtot + 0x8000) >> 16;
+ sbtot = (sbtot + 0x8000) >> 16;
+
+ satot = CLIP (satot, 0, 0xff);
+ srtot = CLIP (srtot, 0, 0xff);
+ sgtot = CLIP (sgtot, 0, 0xff);
+ sbtot = CLIP (sbtot, 0, 0xff);
+
+ return ((satot << 24) | (srtot << 16) | (sgtot << 8) | (sbtot));
+}
+
static force_inline uint32_t
bits_image_fetch_pixel_filtered (bits_image_t *image,
pixman_fixed_t x,
@@ -449,6 +547,10 @@ bits_image_fetch_pixel_filtered (bits_image_t *image,
return bits_image_fetch_pixel_convolution (image, x, y, get_pixel);
break;
+ case PIXMAN_FILTER_SEPARABLE_CONVOLUTION:
+ return bits_image_fetch_pixel_convolution_separable (image, x, y, get_pixel);
+ break;
+
default:
break;
}
diff --git a/pixman/pixman-image.c b/pixman/pixman-image.c
index d9c3034..93ed17e 100644
--- a/pixman/pixman-image.c
+++ b/pixman/pixman-image.c
@@ -371,6 +371,7 @@ compute_image_info (pixman_image_t *image)
break;
case PIXMAN_FILTER_CONVOLUTION:
+ case PIXMAN_FILTER_SEPARABLE_CONVOLUTION:
break;
default:
@@ -515,8 +516,9 @@ compute_image_info (pixman_image_t *image)
* if all channels are opaque, so we simply turn it off
* unconditionally for those images.
*/
- if (image->common.alpha_map ||
- image->common.filter == PIXMAN_FILTER_CONVOLUTION ||
+ if (image->common.alpha_map ||
+ image->common.filter == PIXMAN_FILTER_CONVOLUTION ||
+ image->common.filter == PIXMAN_FILTER_SEPARABLE_CONVOLUTION ||
image->common.component_alpha)
{
flags &= ~(FAST_PATH_IS_OPAQUE | FAST_PATH_SAMPLES_OPAQUE);
@@ -679,6 +681,19 @@ pixman_image_set_filter (pixman_image_t * image,
if (params == common->filter_params && filter == common->filter)
return TRUE;
+ if (filter == PIXMAN_FILTER_SEPARABLE_CONVOLUTION)
+ {
+ int width = pixman_fixed_to_int (params[0]);
+ int height = pixman_fixed_to_int (params[1]);
+ int x_phase_bits = pixman_fixed_to_int (params[2]);
+ int y_phase_bits = pixman_fixed_to_int (params[3]);
+ int n_x_phases = (1 << x_phase_bits);
+ int n_y_phases = (1 << y_phase_bits);
+
+ return_val_if_fail (
+ n_params == 4 + n_x_phases * width + n_y_phases * height, FALSE);
+ }
+
new_params = NULL;
if (params)
{
diff --git a/pixman/pixman.c b/pixman/pixman.c
index e0ccd87..0661f41 100644
--- a/pixman/pixman.c
+++ b/pixman/pixman.c
@@ -455,6 +455,14 @@ analyze_extent (pixman_image_t *image,
height = params[1];
break;
+ case PIXMAN_FILTER_SEPARABLE_CONVOLUTION:
+ params = image->common.filter_params;
+ x_off = - pixman_fixed_e - ((params[0] - pixman_fixed_1) >> 1);
+ y_off = - pixman_fixed_e - ((params[1] - pixman_fixed_1) >> 1);
+ width = params[0];
+ height = params[1];
+ break;
+
case PIXMAN_FILTER_GOOD:
case PIXMAN_FILTER_BEST:
case PIXMAN_FILTER_BILINEAR:
diff --git a/pixman/pixman.h b/pixman/pixman.h
index 33ebf3f..20c95da 100644
--- a/pixman/pixman.h
+++ b/pixman/pixman.h
@@ -292,7 +292,28 @@ typedef enum
PIXMAN_FILTER_BEST,
PIXMAN_FILTER_NEAREST,
PIXMAN_FILTER_BILINEAR,
- PIXMAN_FILTER_CONVOLUTION
+ PIXMAN_FILTER_CONVOLUTION,
+
+ /* The SEPARABLE_CONVOLUTION filter takes the following parameters:
+ *
+ * width: integer given as 16.16 fixpoint number
+ * height: integer given as 16.16 fixpoint number
+ * x_phase_bits: integer given as 16.16 fixpoint
+ * y_phase_bits: integer given as 16.16 fixpoint
+ * xtables: (1 << x_phase_bits) tables of size width
+ * ytables: (1 << y_phase_bits) tables of size height
+ *
+ * When sampling at (x, y), the location is first rounded to one of
+ * n_x_phases * n_y_phases subpixel positions. These subpixel positions
+ * determine an xtable and a ytable to use.
+ *
+ * Conceptually a width x height matrix is then formed in which each entry
+ * is the product of the corresponding entries in the x and y tables.
+ * This matrix is then aligned with the image pixels such that its center
+ * is as close as possible to the subpixel location chosen earlier. Then
+ * the image is convolved with the matrix and the resulting pixel returned.
+ */
+ PIXMAN_FILTER_SEPARABLE_CONVOLUTION
} pixman_filter_t;
typedef enum
--
1.7.4
From sandmann at cs.au.dk Fri Nov 23 20:15:28 2012
From: sandmann at cs.au.dk (=?UTF-8?q?S=C3=B8ren=20Sandmann?=)
Date: Fri, 23 Nov 2012 23:15:28 -0500
Subject: [cairo] [PATCH 3/6] Add new
pixman_filter_create_separable_convolution() API
In-Reply-To: <1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
References:
<1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
Message-ID: <1353730531-5011-3-git-send-email-sandmann@cs.au.dk>
From: S?ren Sandmann Pedersen
This new API is a helper function to create filter parameters suitable
for use with PIXMAN_FILTER_SEPARABLE_CONVOLUTION.
For each dimension, given a scale factor, reconstruction and sample
filter kernels, and a subsampling resolution, this function will
compute a convolution of the two kernels scaled appropriately, then
sample that convolution and return the resulting vectors in a form
suitable for being used as parameters to
PIXMAN_FILTER_SEPARABLE_CONVOLUTION.
The filter kernels offered are the following:
- IMPULSE: Dirac delta function, ie., point sampling
- BOX: Box filter
- LINEAR: Linear filter, aka. "Tent" filter
- CUBIC: Cubic filter, currently Mitchell-Netravali
- GAUSSIAN: Gaussian function, sigma=1, support=3*sigma
- LANCZOS2: Two-lobed Lanczos filter
- LANCZOS3: Three-lobed Lanczos filter
- LANCZOS3_STRETCHED: Three-lobed Lanczos filter, stretched by 4/3.0.
This is the "Nice" filter from Dirty Pixels by
Jim Blinn.
The intended way to use this function is to extract scaling factors
from the transformation and then pass those to this function to get a
filter suitable for compositing with that transformation. The filter
kernels can be chosen according to quality and performance tradeoffs.
To get equivalent quality to GdkPixbuf for downscalings, use BOX for
both reconstruction and sampling. For upscalings, use LINEAR for
reconstruction and IMPULSE for sampling (though note that for
upscaling in both X and Y directions, simply using
PIXMAN_FILTER_BILINEAR will likely be a better choice).
---
pixman/Makefile.sources | 1 +
pixman/pixman-filter.c | 340 +++++++++++++++++++++++++++++++++++++++++++++++
pixman/pixman.h | 27 ++++
3 files changed, 368 insertions(+), 0 deletions(-)
create mode 100644 pixman/pixman-filter.c
diff --git a/pixman/Makefile.sources b/pixman/Makefile.sources
index 5351fb0..c624eb9 100644
--- a/pixman/Makefile.sources
+++ b/pixman/Makefile.sources
@@ -6,6 +6,7 @@ libpixman_sources = \
pixman-combine32.c \
pixman-combine-float.c \
pixman-conical-gradient.c \
+ pixman-filter.c \
pixman-x86.c \
pixman-mips.c \
pixman-arm.c \
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
new file mode 100644
index 0000000..c9d2dc7
--- /dev/null
+++ b/pixman/pixman-filter.c
@@ -0,0 +1,340 @@
+/*
+ * Copyright 2012, Red Hat, Inc.
+ * Copyright 2012, Soren Sandmann
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Soren Sandmann
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pixman-private.h"
+
+typedef double (* kernel_func_t) (double x);
+
+typedef struct
+{
+ pixman_kernel_t kernel;
+ kernel_func_t func;
+ double width;
+} filter_info_t;
+
+static double
+impulse_kernel (double x)
+{
+ return (x == 0.0)? 1.0 : 0.0;
+}
+
+static double
+box_kernel (double x)
+{
+ return 1;
+}
+
+static double
+linear_kernel (double x)
+{
+ return 1 - fabs (x);
+}
+
+static double
+gaussian_kernel (double x)
+{
+#define SQRT2 (1.4142135623730950488016887242096980785696718753769480)
+#define SIGMA (SQRT2 / 2.0)
+
+ return exp (- x * x / (2 * SIGMA * SIGMA)) / (SIGMA * sqrt (2.0 * M_PI));
+}
+
+static double
+sinc (double x)
+{
+ if (x == 0.0)
+ return 1.0;
+ else
+ return sin (M_PI * x) / (M_PI * x);
+}
+
+static double
+lanczos (double x, int n)
+{
+ return sinc (x) * sinc (x * (1.0 / n));
+}
+
+static double
+lanczos2_kernel (double x)
+{
+ return lanczos (x, 2);
+}
+
+static double
+lanczos3_kernel (double x)
+{
+ return lanczos (x, 3);
+}
+
+static double
+nice_kernel (double x)
+{
+ return lanczos3_kernel (x * 0.75);
+}
+
+static double
+general_cubic (double x, double B, double C)
+{
+ double ax = fabs(x);
+
+ if (ax < 1)
+ {
+ return ((12 - 9 * B - 6 * C) * ax * ax * ax +
+ (-18 + 12 * B + 6 * C) * ax * ax + (6 - 2 * B)) / 6;
+ }
+ else if (ax >= 1 && ax < 2)
+ {
+ return ((-B - 6 * C) * ax * ax * ax +
+ (6 * B + 30 * C) * ax * ax + (-12 * B - 48 * C) *
+ ax + (8 * B + 24 * C)) / 6;
+ }
+ else
+ {
+ return 0;
+ }
+}
+
+static double
+cubic_kernel (double x)
+{
+ /* This is the Mitchell-Netravali filter.
+ *
+ * (0.0, 0.5) would give us the Catmull-Rom spline,
+ * but that one seems to be indistinguishable from Lanczos2.
+ */
+ return general_cubic (x, 1/3.0, 1/3.0);
+}
+
+static const filter_info_t filters[] =
+{
+ { PIXMAN_KERNEL_IMPULSE, impulse_kernel, 0.0 },
+ { PIXMAN_KERNEL_BOX, box_kernel, 1.0 },
+ { PIXMAN_KERNEL_LINEAR, linear_kernel, 2.0 },
+ { PIXMAN_KERNEL_CUBIC, cubic_kernel, 4.0 },
+ { PIXMAN_KERNEL_GAUSSIAN, gaussian_kernel, 6 * SIGMA },
+ { PIXMAN_KERNEL_LANCZOS2, lanczos2_kernel, 4.0 },
+ { PIXMAN_KERNEL_LANCZOS3, lanczos3_kernel, 6.0 },
+ { PIXMAN_KERNEL_LANCZOS3_STRETCHED, nice_kernel, 8.0 },
+};
+
+/* This function scales @kernel2 by @scale, then
+ * aligns @x1 in @kernel1 with @x2 in @kernel2 and
+ * and integrates the product of the kernels across @width.
+ *
+ * This function assumes that the intervals are within
+ * the kernels in question. E.g., the caller must not
+ * try to integrate a linear kernel ouside of [-1:1]
+ */
+static double
+integral (pixman_kernel_t kernel1, double x1,
+ pixman_kernel_t kernel2, double scale, double x2,
+ double width)
+{
+ /* If the integration interval crosses zero, break it into
+ * two separate integrals. This ensures that filters such
+ * as LINEAR that are not differentiable at 0 will still
+ * integrate properly.
+ */
+ if (x1 < 0 && x1 + width > 0)
+ {
+ return
+ integral (kernel1, x1, kernel2, scale, x2, - x1) +
+ integral (kernel1, 0, kernel2, scale, x2 - x1, width + x1);
+ }
+ else if (x2 < 0 && x2 + width > 0)
+ {
+ return
+ integral (kernel1, x1, kernel2, scale, x2, - x2) +
+ integral (kernel1, x1 - x2, kernel2, scale, 0, width + x2);
+ }
+ else if (kernel1 == PIXMAN_KERNEL_IMPULSE)
+ {
+ assert (width == 0.0);
+ return filters[kernel2].func (x2 * scale);
+ }
+ else if (kernel2 == PIXMAN_KERNEL_IMPULSE)
+ {
+ assert (width == 0.0);
+ return filters[kernel1].func (x1);
+ }
+ else
+ {
+ /* Integration via Simpson's rule */
+#define N_SEGMENTS 128
+#define SAMPLE(a1, a2) \
+ (filters[kernel1].func ((a1)) * filters[kernel2].func ((a2) * scale))
+
+ double s = 0.0;
+ double h = width / (double)N_SEGMENTS;
+ int i;
+
+ s = SAMPLE (x1, x2);
+
+ for (i = 1; i < N_SEGMENTS; i += 2)
+ {
+ double a1 = x1 + h * i;
+ double a2 = x2 + h * i;
+
+ s += 2 * SAMPLE (a1, a2);
+
+ if (i >= 2 && i < N_SEGMENTS - 1)
+ s += 4 * SAMPLE (a1, a2);
+ }
+
+ s += SAMPLE (x1 + width, x2 + width);
+
+ return h * s * (1.0 / 3.0);
+ }
+}
+
+static pixman_fixed_t *
+create_1d_filter (int *width,
+ pixman_kernel_t reconstruct,
+ pixman_kernel_t sample,
+ double scale,
+ int n_phases)
+{
+ pixman_fixed_t *params, *p;
+ double step;
+ double size;
+ int i;
+
+ size = scale * filters[sample].width + filters[reconstruct].width;
+ *width = ceil (size);
+
+ p = params = malloc (*width * n_phases * sizeof (pixman_fixed_t));
+
+ step = 1.0 / n_phases;
+
+ for (i = 0; i < n_phases; ++i)
+ {
+ double frac = step / 2.0 + i * step;
+ pixman_fixed_t new_total;
+ int x, x1, x2;
+ double total;
+
+ /* Sample convolution of reconstruction and sampling
+ * filter. See rounding.txt regarding the rounding
+ * and sample positions.
+ */
+
+ x1 = ceil (frac - *width / 2.0 - 0.5);
+ x2 = x1 + *width;
+
+ total = 0;
+ for (x = x1; x < x2; ++x)
+ {
+ double pos = x + 0.5 - frac;
+ double rlow = - filters[reconstruct].width / 2.0;
+ double rhigh = rlow + filters[reconstruct].width;
+ double slow = pos - scale * filters[sample].width / 2.0;
+ double shigh = slow + scale * filters[sample].width;
+ double c = 0.0;
+ double ilow, ihigh;
+
+ if (rhigh >= slow && rlow <= shigh)
+ {
+ ilow = MAX (slow, rlow);
+ ihigh = MIN (shigh, rhigh);
+
+ c = integral (reconstruct, ilow,
+ sample, 1.0 / scale, ilow - pos,
+ ihigh - ilow);
+ }
+
+ total += c;
+ *p++ = (pixman_fixed_t)(c * 65535.0 + 0.5);
+ }
+
+ /* Normalize */
+ p -= *width;
+ total = 1 / total;
+ new_total = 0;
+ for (x = x1; x < x2; ++x)
+ {
+ pixman_fixed_t t = (*p) * total + 0.5;
+
+ new_total += t;
+ *p++ = t;
+ }
+
+ if (new_total != pixman_fixed_1)
+ *(p - *width / 2) += (pixman_fixed_1 - new_total);
+ }
+
+ return params;
+}
+
+/* Create the parameter list for a SEPARABLE_CONVOLUTION filter
+ * with the given kernels and scale parameters
+ */
+PIXMAN_EXPORT pixman_fixed_t *
+pixman_filter_create_separable_convolution (int *n_values,
+ pixman_fixed_t scale_x,
+ pixman_fixed_t scale_y,
+ pixman_kernel_t reconstruct_x,
+ pixman_kernel_t reconstruct_y,
+ pixman_kernel_t sample_x,
+ pixman_kernel_t sample_y,
+ int subsample_bits_x,
+ int subsample_bits_y)
+{
+ double sx = fabs (pixman_fixed_to_double (scale_x));
+ double sy = fabs (pixman_fixed_to_double (scale_y));
+ pixman_fixed_t *horz, *vert, *params;
+ int subsample_x, subsample_y;
+ int width, height;
+
+ subsample_x = (1 << subsample_bits_x);
+ subsample_y = (1 << subsample_bits_y);
+
+ horz = create_1d_filter (&width, reconstruct_x, sample_x, sx, subsample_x);
+ vert = create_1d_filter (&height, reconstruct_y, sample_y, sy, subsample_y);
+
+ *n_values = 4 + width * subsample_x + height * subsample_y;
+
+ params = malloc (*n_values * sizeof (pixman_fixed_t));
+
+ params[0] = pixman_int_to_fixed (width);
+ params[1] = pixman_int_to_fixed (height);
+ params[2] = pixman_int_to_fixed (subsample_bits_x);
+ params[3] = pixman_int_to_fixed (subsample_bits_y);
+
+ memcpy (params + 4, horz,
+ width * subsample_x * sizeof (pixman_fixed_t));
+ memcpy (params + 4 + width * subsample_x, vert,
+ height * subsample_y * sizeof (pixman_fixed_t));
+
+ free (horz);
+ free (vert);
+
+ return params;
+}
diff --git a/pixman/pixman.h b/pixman/pixman.h
index 20c95da..7ff9fb5 100644
--- a/pixman/pixman.h
+++ b/pixman/pixman.h
@@ -831,6 +831,33 @@ int pixman_image_get_height (pixman_image_t
int pixman_image_get_stride (pixman_image_t *image); /* in bytes */
int pixman_image_get_depth (pixman_image_t *image);
pixman_format_code_t pixman_image_get_format (pixman_image_t *image);
+
+typedef enum
+{
+ PIXMAN_KERNEL_IMPULSE,
+ PIXMAN_KERNEL_BOX,
+ PIXMAN_KERNEL_LINEAR,
+ PIXMAN_KERNEL_CUBIC,
+ PIXMAN_KERNEL_GAUSSIAN,
+ PIXMAN_KERNEL_LANCZOS2,
+ PIXMAN_KERNEL_LANCZOS3,
+ PIXMAN_KERNEL_LANCZOS3_STRETCHED /* Jim Blinn's 'nice' filter */
+} pixman_kernel_t;
+
+/* Create the parameter list for a SEPARABLE_CONVOLUTION filter
+ * with the given kernels and scale parameters.
+ */
+pixman_fixed_t *
+pixman_filter_create_separable_convolution (int *n_values,
+ pixman_fixed_t scale_x,
+ pixman_fixed_t scale_y,
+ pixman_kernel_t reconstruct_x,
+ pixman_kernel_t reconstruct_y,
+ pixman_kernel_t sample_x,
+ pixman_kernel_t sample_y,
+ int subsample_bits_x,
+ int subsample_bits_y);
+
pixman_bool_t pixman_image_fill_rectangles (pixman_op_t op,
pixman_image_t *image,
const pixman_color_t *color,
--
1.7.4
From sandmann at cs.au.dk Fri Nov 23 20:15:29 2012
From: sandmann at cs.au.dk (=?UTF-8?q?S=C3=B8ren=20Sandmann?=)
Date: Fri, 23 Nov 2012 23:15:29 -0500
Subject: [cairo] [PATCH 4/6] demos/gtk-utils.[ch]: Add
pixman_image_from_file()
In-Reply-To: <1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
References:
<1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
Message-ID: <1353730531-5011-4-git-send-email-sandmann@cs.au.dk>
From: S?ren Sandmann Pedersen
This function uses GdkPixbuf to load various common formats such as
.png and .jpg into a pixman image.
---
demos/gtk-utils.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++
demos/gtk-utils.h | 3 ++
2 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/demos/gtk-utils.c b/demos/gtk-utils.c
index 8291a1e..d7e946d 100644
--- a/demos/gtk-utils.c
+++ b/demos/gtk-utils.c
@@ -3,6 +3,72 @@
#include "../test/utils.h"
#include "gtk-utils.h"
+pixman_image_t *
+pixman_image_from_file (const char *filename, pixman_format_code_t format)
+{
+ GdkPixbuf *pixbuf;
+ pixman_image_t *image;
+ int width, height;
+ uint32_t *data, *d;
+ uint8_t *gdk_data;
+ int n_channels;
+ int j, i;
+ int stride;
+
+ if (!(pixbuf = gdk_pixbuf_new_from_file (filename, NULL)))
+ return NULL;
+
+ image = NULL;
+
+ width = gdk_pixbuf_get_width (pixbuf);
+ height = gdk_pixbuf_get_height (pixbuf);
+ n_channels = gdk_pixbuf_get_n_channels (pixbuf);
+ gdk_data = gdk_pixbuf_get_pixels (pixbuf);
+ stride = gdk_pixbuf_get_rowstride (pixbuf);
+
+ if (!(data = malloc (width * height * sizeof (uint32_t))))
+ goto out;
+
+ d = data;
+ for (j = 0; j < height; ++j)
+ {
+ uint8_t *gdk_line = gdk_data;
+
+ for (i = 0; i < width; ++i)
+ {
+ int r, g, b, a;
+ uint32_t pixel;
+
+ r = gdk_line[0];
+ g = gdk_line[1];
+ b = gdk_line[2];
+
+ if (n_channels == 4)
+ a = gdk_line[3];
+ else
+ a = 0xff;
+
+ r = (r * a + 127) / 255;
+ g = (g * a + 127) / 255;
+ b = (b * a + 127) / 255;
+
+ pixel = (a << 24) | (r << 16) | (g << 8) | b;
+
+ *d++ = pixel;
+ gdk_line += n_channels;
+ }
+
+ gdk_data += stride;
+ }
+
+ image = pixman_image_create_bits (
+ format, width, height, data, width * 4);
+
+out:
+ g_object_unref (pixbuf);
+ return image;
+}
+
GdkPixbuf *
pixbuf_from_argb32 (uint32_t *bits,
int width,
diff --git a/demos/gtk-utils.h b/demos/gtk-utils.h
index 55cb701..36be4de 100644
--- a/demos/gtk-utils.h
+++ b/demos/gtk-utils.h
@@ -6,6 +6,9 @@
void show_image (pixman_image_t *image);
+pixman_image_t *
+pixman_image_from_file (const char *filename, pixman_format_code_t format);
+
GdkPixbuf *pixbuf_from_argb32 (uint32_t *bits,
int width,
int height,
--
1.7.4
From sandmann at cs.au.dk Fri Nov 23 20:15:30 2012
From: sandmann at cs.au.dk (=?UTF-8?q?S=C3=B8ren=20Sandmann?=)
Date: Fri, 23 Nov 2012 23:15:30 -0500
Subject: [cairo] [PATCH 5/6] demos: Add new demo program, "scale"
In-Reply-To: <1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
References:
<1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
Message-ID: <1353730531-5011-5-git-send-email-sandmann@cs.au.dk>
From: S?ren Sandmann Pedersen
This program allows interactively scaling and rotating images with
using various filters and repeat modes. It uses
pixman_filter_create_separate_convolution() to generate the filters.
---
demos/Makefile.am | 6 +-
demos/scale.c | 431 +++++++++++++++++++++++++++++++++++++++++++++++++++++
demos/scale.ui | 302 +++++++++++++++++++++++++++++++++++++
3 files changed, 737 insertions(+), 2 deletions(-)
create mode 100644 demos/scale.c
create mode 100644 demos/scale.ui
diff --git a/demos/Makefile.am b/demos/Makefile.am
index f324f5f..ffb7a6b 100644
--- a/demos/Makefile.am
+++ b/demos/Makefile.am
@@ -22,9 +22,10 @@ DEMOS = \
quad2quad \
checkerboard \
srgb-trap-test \
- srgb-test
+ srgb-test \
+ scale
-EXTRA_DIST = parrot.c parrot.jpg
+EXTRA_DIST = parrot.c parrot.jpg scale.ui
gradient_test_SOURCES = gradient-test.c $(GTK_UTILS)
alpha_test_SOURCES = alpha-test.c $(GTK_UTILS)
@@ -39,6 +40,7 @@ tri_test_SOURCES = tri-test.c $(GTK_UTILS)
checkerboard_SOURCES = checkerboard.c $(GTK_UTILS)
srgb_test_SOURCES = srgb-test.c $(GTK_UTILS)
srgb_trap_test_SOURCES = srgb-trap-test.c $(GTK_UTILS)
+scale_SOURCES = scale.c $(GTK_UTILS)
noinst_PROGRAMS = $(DEMOS)
diff --git a/demos/scale.c b/demos/scale.c
new file mode 100644
index 0000000..9100ff7
--- /dev/null
+++ b/demos/scale.c
@@ -0,0 +1,431 @@
+/*
+ * Copyright 2012, Red Hat, Inc.
+ * Copyright 2012, Soren Sandmann
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Soren Sandmann
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+#include
+#include
+#include
+#include
+#include "gtk-utils.h"
+
+typedef struct
+{
+ GtkBuilder * builder;
+ pixman_image_t * original;
+ GtkAdjustment * scale_x_adjustment;
+ GtkAdjustment * scale_y_adjustment;
+ GtkAdjustment * rotate_adjustment;
+ int scaled_width;
+ int scaled_height;
+} app_t;
+
+static GtkWidget *
+get_widget (app_t *app, const char *name)
+{
+ GtkWidget *widget = GTK_WIDGET (gtk_builder_get_object (app->builder, name));
+
+ if (!widget)
+ g_error ("Widget %s not found\n", name);
+
+ return widget;
+}
+
+static double
+min4 (double a, double b, double c, double d)
+{
+ double m1, m2;
+
+ m1 = MIN (a, b);
+ m2 = MIN (c, d);
+ return MIN (m1, m2);
+}
+
+static double
+max4 (double a, double b, double c, double d)
+{
+ double m1, m2;
+
+ m1 = MAX (a, b);
+ m2 = MAX (c, d);
+ return MAX (m1, m2);
+}
+
+static void
+compute_extents (pixman_f_transform_t *trans, double *sx, double *sy)
+{
+ double min_x, max_x, min_y, max_y;
+ pixman_f_vector_t v[4] =
+ {
+ { { 1, 1, 1 } },
+ { { -1, 1, 1 } },
+ { { -1, -1, 1 } },
+ { { 1, -1, 1 } },
+ };
+
+ pixman_f_transform_point (trans, &v[0]);
+ pixman_f_transform_point (trans, &v[1]);
+ pixman_f_transform_point (trans, &v[2]);
+ pixman_f_transform_point (trans, &v[3]);
+
+ min_x = min4 (v[0].v[0], v[1].v[0], v[2].v[0], v[3].v[0]);
+ max_x = max4 (v[0].v[0], v[1].v[0], v[2].v[0], v[3].v[0]);
+ min_y = min4 (v[0].v[1], v[1].v[1], v[2].v[1], v[3].v[1]);
+ max_y = max4 (v[0].v[1], v[1].v[1], v[2].v[1], v[3].v[1]);
+
+ *sx = (max_x - min_x) / 2.0;
+ *sy = (max_y - min_y) / 2.0;
+}
+
+typedef struct
+{
+ char name [20];
+ pixman_kernel_t value;
+} named_int_t;
+
+static const named_int_t filters[] =
+{
+ { "Box", PIXMAN_KERNEL_BOX },
+ { "Impulse", PIXMAN_KERNEL_IMPULSE },
+ { "Linear", PIXMAN_KERNEL_LINEAR },
+ { "Cubic", PIXMAN_KERNEL_CUBIC },
+ { "Lanczos2", PIXMAN_KERNEL_LANCZOS2 },
+ { "Lanczos3", PIXMAN_KERNEL_LANCZOS3 },
+ { "Lanczos3 Stretched", PIXMAN_KERNEL_LANCZOS3_STRETCHED },
+ { "Gaussian", PIXMAN_KERNEL_GAUSSIAN },
+};
+
+static const named_int_t repeats[] =
+{
+ { "None", PIXMAN_REPEAT_NONE },
+ { "Normal", PIXMAN_REPEAT_NORMAL },
+ { "Reflect", PIXMAN_REPEAT_REFLECT },
+ { "Pad", PIXMAN_REPEAT_PAD },
+};
+
+static pixman_kernel_t
+get_value (app_t *app, const named_int_t table[], const char *box_name)
+{
+ GtkComboBox *box = GTK_COMBO_BOX (get_widget (app, box_name));
+
+ return table[gtk_combo_box_get_active (box)].value;
+}
+
+static void
+copy_to_counterpart (app_t *app, GObject *object)
+{
+ static const char *xy_map[] =
+ {
+ "reconstruct_x_combo_box", "reconstruct_y_combo_box",
+ "sample_x_combo_box", "sample_y_combo_box",
+ "scale_x_adjustment", "scale_y_adjustment",
+ };
+ GObject *counterpart = NULL;
+ int i;
+
+ for (i = 0; i < G_N_ELEMENTS (xy_map); i += 2)
+ {
+ GObject *x = gtk_builder_get_object (app->builder, xy_map[i]);
+ GObject *y = gtk_builder_get_object (app->builder, xy_map[i + 1]);
+
+ if (object == x)
+ counterpart = y;
+ if (object == y)
+ counterpart = x;
+ }
+
+ if (!counterpart)
+ return;
+
+ if (GTK_IS_COMBO_BOX (counterpart))
+ {
+ gtk_combo_box_set_active (
+ GTK_COMBO_BOX (counterpart),
+ gtk_combo_box_get_active (
+ GTK_COMBO_BOX (object)));
+ }
+ else if (GTK_IS_ADJUSTMENT (counterpart))
+ {
+ gtk_adjustment_set_value (
+ GTK_ADJUSTMENT (counterpart),
+ gtk_adjustment_get_value (
+ GTK_ADJUSTMENT (object)));
+ }
+}
+
+static double
+to_scale (double v)
+{
+ return pow (1.15, v);
+}
+
+static void
+rescale (GtkWidget *may_be_null, app_t *app)
+{
+ pixman_f_transform_t ftransform;
+ pixman_transform_t transform;
+ double new_width, new_height;
+ double fscale_x, fscale_y;
+ double rotation;
+ pixman_fixed_t *params;
+ int n_params;
+ double sx, sy;
+
+ pixman_f_transform_init_identity (&ftransform);
+
+ if (may_be_null && gtk_toggle_button_get_active (
+ GTK_TOGGLE_BUTTON (get_widget (app, "lock_checkbutton"))))
+ {
+ copy_to_counterpart (app, G_OBJECT (may_be_null));
+ }
+
+ fscale_x = gtk_adjustment_get_value (app->scale_x_adjustment);
+ fscale_y = gtk_adjustment_get_value (app->scale_y_adjustment);
+ rotation = gtk_adjustment_get_value (app->rotate_adjustment);
+
+ fscale_x = to_scale (fscale_x);
+ fscale_y = to_scale (fscale_y);
+
+ new_width = pixman_image_get_width (app->original) * fscale_x;
+ new_height = pixman_image_get_height (app->original) * fscale_y;
+
+ pixman_f_transform_scale (&ftransform, NULL, fscale_x, fscale_y);
+
+ pixman_f_transform_translate (&ftransform, NULL, - new_width / 2.0, - new_height / 2.0);
+
+ rotation = (rotation / 360.0) * 2 * M_PI;
+ pixman_f_transform_rotate (&ftransform, NULL, cos (rotation), sin (rotation));
+
+ pixman_f_transform_translate (&ftransform, NULL, new_width / 2.0, new_height / 2.0);
+
+ pixman_f_transform_invert (&ftransform, &ftransform);
+
+ compute_extents (&ftransform, &sx, &sy);
+
+ pixman_transform_from_pixman_f_transform (&transform, &ftransform);
+ pixman_image_set_transform (app->original, &transform);
+
+ params = pixman_filter_create_separable_convolution (
+ &n_params,
+ sx * 65536.0 + 0.5,
+ sy * 65536.0 + 0.5,
+ get_value (app, filters, "reconstruct_x_combo_box"),
+ get_value (app, filters, "reconstruct_y_combo_box"),
+ get_value (app, filters, "sample_x_combo_box"),
+ get_value (app, filters, "sample_y_combo_box"),
+ 4, 4);
+
+ pixman_image_set_filter (app->original, PIXMAN_FILTER_SEPARABLE_CONVOLUTION, params, n_params);
+
+ pixman_image_set_repeat (
+ app->original, get_value (app, repeats, "repeat_combo_box"));
+
+ free (params);
+
+ app->scaled_width = ceil (new_width);
+ app->scaled_height = ceil (new_height);
+
+ gtk_widget_set_size_request (
+ get_widget (app, "drawing_area"), new_width + 0.5, new_height + 0.5);
+
+ gtk_widget_queue_draw (
+ get_widget (app, "drawing_area"));
+}
+
+static gboolean
+on_expose (GtkWidget *da, GdkEvent *event, gpointer data)
+{
+ app_t *app = data;
+ GdkRectangle *area = &event->expose.area;
+ cairo_surface_t *surface;
+ pixman_image_t *tmp;
+ cairo_t *cr;
+ uint32_t *pixels;
+
+ pixels = calloc (1, area->width * area->height * 4);
+ tmp = pixman_image_create_bits (
+ PIXMAN_a8r8g8b8, area->width, area->height, pixels, area->width * 4);
+
+ if (area->x < app->scaled_width && area->y < app->scaled_height)
+ {
+ pixman_image_composite (
+ PIXMAN_OP_SRC,
+ app->original, NULL, tmp,
+ area->x, area->y, 0, 0, 0, 0,
+ app->scaled_width - area->x, app->scaled_height - area->y);
+ }
+
+ surface = cairo_image_surface_create_for_data (
+ (uint8_t *)pixels, CAIRO_FORMAT_ARGB32,
+ area->width, area->height, area->width * 4);
+
+ cr = gdk_cairo_create (da->window);
+
+ cairo_set_source_surface (cr, surface, area->x, area->y);
+
+ cairo_paint (cr);
+
+ cairo_destroy (cr);
+ cairo_surface_destroy (surface);
+ free (pixels);
+ pixman_image_unref (tmp);
+
+ return TRUE;
+}
+
+static void
+set_up_combo_box (app_t *app, const char *box_name,
+ int n_entries, const named_int_t table[])
+{
+ GtkWidget *widget = get_widget (app, box_name);
+ GtkListStore *model;
+ GtkCellRenderer *cell;
+ int i;
+
+ model = gtk_list_store_new (1, G_TYPE_STRING);
+
+ cell = gtk_cell_renderer_text_new ();
+ gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (widget), cell, TRUE);
+ gtk_cell_layout_set_attributes (GTK_CELL_LAYOUT (widget), cell,
+ "text", 0,
+ NULL);
+
+ gtk_combo_box_set_model (GTK_COMBO_BOX (widget), GTK_TREE_MODEL (model));
+
+ for (i = 0; i < n_entries; ++i)
+ {
+ const named_int_t *info = &(table[i]);
+ GtkTreeIter iter;
+
+ gtk_list_store_append (model, &iter);
+ gtk_list_store_set (model, &iter, 0, info->name, -1);
+ }
+
+ gtk_combo_box_set_active (GTK_COMBO_BOX (widget), 0);
+
+ g_signal_connect (widget, "changed", G_CALLBACK (rescale), app);
+}
+
+static void
+set_up_filter_box (app_t *app, const char *box_name)
+{
+ set_up_combo_box (app, box_name, G_N_ELEMENTS (filters), filters);
+}
+
+static char *
+format_value (GtkWidget *widget, double value)
+{
+ return g_strdup_printf ("%.4f", to_scale (value));
+}
+
+static app_t *
+app_new (pixman_image_t *original)
+{
+ GtkWidget *widget;
+ app_t *app = g_malloc (sizeof *app);
+ GError *err = NULL;
+
+ app->builder = gtk_builder_new ();
+ app->original = original;
+
+ if (!gtk_builder_add_from_file (app->builder, "scale.ui", &err))
+ g_error ("Could not read file scale.ui: %s", err->message);
+
+ app->scale_x_adjustment =
+ GTK_ADJUSTMENT (gtk_builder_get_object (app->builder, "scale_x_adjustment"));
+ app->scale_y_adjustment =
+ GTK_ADJUSTMENT (gtk_builder_get_object (app->builder, "scale_y_adjustment"));
+ app->rotate_adjustment =
+ GTK_ADJUSTMENT (gtk_builder_get_object (app->builder, "rotate_adjustment"));
+
+ g_signal_connect (app->scale_x_adjustment, "value_changed", G_CALLBACK (rescale), app);
+ g_signal_connect (app->scale_y_adjustment, "value_changed", G_CALLBACK (rescale), app);
+ g_signal_connect (app->rotate_adjustment, "value_changed", G_CALLBACK (rescale), app);
+
+ widget = get_widget (app, "scale_x_scale");
+ gtk_scale_add_mark (GTK_SCALE (widget), 0.0, GTK_POS_LEFT, NULL);
+ g_signal_connect (widget, "format_value", G_CALLBACK (format_value), app);
+ widget = get_widget (app, "scale_y_scale");
+ gtk_scale_add_mark (GTK_SCALE (widget), 0.0, GTK_POS_LEFT, NULL);
+ g_signal_connect (widget, "format_value", G_CALLBACK (format_value), app);
+ widget = get_widget (app, "rotate_scale");
+ gtk_scale_add_mark (GTK_SCALE (widget), 0.0, GTK_POS_LEFT, NULL);
+
+ widget = get_widget (app, "drawing_area");
+ g_signal_connect (widget, "expose_event", G_CALLBACK (on_expose), app);
+
+ set_up_filter_box (app, "reconstruct_x_combo_box");
+ set_up_filter_box (app, "reconstruct_y_combo_box");
+ set_up_filter_box (app, "sample_x_combo_box");
+ set_up_filter_box (app, "sample_y_combo_box");
+
+ set_up_combo_box (
+ app, "repeat_combo_box", G_N_ELEMENTS (repeats), repeats);
+
+ g_signal_connect (
+ gtk_builder_get_object (app->builder, "lock_checkbutton"),
+ "toggled", G_CALLBACK (rescale), app);
+
+ rescale (NULL, app);
+
+ return app;
+}
+
+int
+main (int argc, char **argv)
+{
+ GtkWidget *window;
+ pixman_image_t *image;
+ app_t *app;
+
+ gtk_init (&argc, &argv);
+
+ if (argc < 2)
+ {
+ printf ("%s \n", argv[0]);
+ return -1;
+ }
+
+ if (!(image = pixman_image_from_file (argv[1], PIXMAN_a8r8g8b8)))
+ {
+ printf ("Could not load image \"%s\"\n", argv[1]);
+ return -1;
+ }
+
+ app = app_new (image);
+
+ window = get_widget (app, "main");
+
+ g_signal_connect (window, "delete_event", G_CALLBACK (gtk_main_quit), NULL);
+
+ gtk_window_set_default_size (GTK_WINDOW (window), 1024, 768);
+
+ gtk_widget_show_all (window);
+
+ gtk_main ();
+
+ return 0;
+}
diff --git a/demos/scale.ui b/demos/scale.ui
new file mode 100644
index 0000000..f7c0c80
--- /dev/null
+++ b/demos/scale.ui
@@ -0,0 +1,302 @@
+
+
+
+
+
+
+
+
+
--
1.7.4
From sandmann at cs.au.dk Fri Nov 23 20:15:27 2012
From: sandmann at cs.au.dk (=?UTF-8?q?S=C3=B8ren=20Sandmann?=)
Date: Fri, 23 Nov 2012 23:15:27 -0500
Subject: [cairo] [PATCH 2/6] rounding.txt: Describe how
SEPARABLE_CONVOLUTION filter works
In-Reply-To: <1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
References:
<1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
Message-ID: <1353730531-5011-2-git-send-email-sandmann@cs.au.dk>
From: S?ren Sandmann Pedersen
Add some notes on how to compute the convolution matrices to be used
with the SEPARABLE_CONVOLUTION filter.
---
pixman/rounding.txt | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/pixman/rounding.txt b/pixman/rounding.txt
index 1a19f45..b52b084 100644
--- a/pixman/rounding.txt
+++ b/pixman/rounding.txt
@@ -132,3 +132,36 @@ And so the final formula for the index k of x0 in the image is:
Computing the result is then simply a matter of convolving all the
pixels starting at k with all the samples in the matrix.
+
+
+--- SEPARABLE_CONVOLUTION
+
+For this filter, x is first rounded to one of n regularly spaced
+subpixel positions. This subpixel position determines which of n
+convolution matrices is being used.
+
+Then, as in a regular convolution filter, the first pixel to be used
+is determined:
+
+ k = floor (x - (width - 1) / 2.0 - e)
+
+and then the image pixels starting there are convolved with the chosen
+matrix. If we write x = xi + frac, where xi is an integer, we get
+
+ k = xi + floor (frac - (width - 1) / 2.0 - e)
+
+so the location of k relative to x is given by:
+
+ (k + 0.5 - x) = xi + floor (frac - (width - 1) / 2.0 - e) + 0.5 - x
+
+ = floor (frac - (width - 1) / 2.0 - e) + 0.5 - frac
+
+which means the contents of the matrix corresponding to (frac) should
+contain width samplings of the function, with the first sample at:
+
+ floor (frac - (width - 1) / 2.0 - e) + 0.5 - frac
+
+This filter is called separable because each of the k x k convolution
+matrices is specified with two k-wide vectors, one for each dimension,
+where each entry in the matrix is computed as the product of the
+corresponding entries in the vectors.
--
1.7.4
From behdad at behdad.org Fri Nov 23 22:01:13 2012
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sat, 24 Nov 2012 01:01:13 -0500
Subject: [cairo] [Pixman] Image resampling [PATCH 0/6]
In-Reply-To:
References:
Message-ID: <50B062A9.5060305@behdad.org>
Hi S?ren,
This is a very well done patchset with great commentary. Great job!
Cheers,
behdad
On 12-11-23 10:57 PM, S?ren Sandmann wrote:
> Hi,
>
> Reviewing the supersampling patch here:
>
> http://cgit.freedesktop.org/~ajohnson/pixman/log/?h=supersampling
>
> I wasn't happy with either the performance and image quality, and I
> realized that the whole supersampling approach just isn't going to
> fly. Since I told people to do it that way, I apologize for that. The
> approach advocated by Bill Spitzak in the various downsampling threads
> of computing a convolution kernel up front, is the much better way to
> go. To make up for being misleading, the following patches implement
> comprehensive support for high-quality image scaling filters.
>
> Pixman already has a convolution filter, but since it only allows one
> sample per pixel of the filter, it is limited in the quality that it can
> support, so the following patches (to be applied on top of the three
> rounding patches) add a new filter type
>
> PIXMAN_FILTER_SEPARABLE_CONVOLUTION
>
> that supports multiple different convolution matrices that are chosen
> between based on the subpixel source location. The matrices are
> specified as tensor products of x/y vectors, which makes them
> separable by definition.
>
> The patches also add a helper function
>
> pixman_filter_create_separable_convolution()
>
> that will create the parameters for the filter based on scaling
> factors, filter kernels and subsampling resolution. Currently the
> supported kernels are impulse, box, linear, cubic
> (Mitchell-Netravali), lanczos2, lanczos3, lanczos3_stretched
> (aka. Blinn's 'Nice' filter), and Gaussian.
>
> There also a new demo program "demos/scale" that shows how
> the new API can be used.
>
> For some useful math regarding image transformations, see
> http://people.redhat.com/otaylor/gtk/pixbuf-transform-math.ps . For
> some informatino about how to compute the convolution matrices, see
> the additions to rounding.txt in the second patch.
>
>
> -=- Adding support to cairo and further work
>
> Once these patches have landed in Pixman, support will have to be
> added to cairo to make use of them. How to do that exactly requires
> figuring out what new API to offer, and how the tradeoffs between
> performance and quality should be made. This is not something that I
> personally plan to work on anytime soon, except to make three notes:
>
> - While transformations that are not pure scalings will not
> generally result in a separable filter, OK-looking results for
> non-scalings can be achieved by using scaling factors based on the
> bounding box of a transformation
>
> - For equivalent quality to GdkPixbuf do this: In each direction
> compute the scaling factors and then, if the scaling factor is
> less than 1 (ie., a downscaling), use PIXMAN_KERNEL_BOX for both
> reconstruction and sampling, and if it's greater than one, use
> PIXMAN_KERNEL_LINEAR for reconstruction and PIXMAN_KERNEL_IMPULSE
> for sampling.
>
> - If PIXMAN_KERNEL_GAUSSIAN is used with large downscaling factors
> and the resulting filter is then used with an identity transform,
> the result is a Gaussian blur, which is a feature that has
> sometimes been requested.
>
> The code in demos/scale.c may be useful as an example.
>
>
> -=- Further work and examples
>
> There is some additional work that could be done:
>
> - Performance improvements. Low-hanging fruit includes adding new fast
> path iterators that assume the source is a8r8g8b8 or r5g6b5. Higher
> hanging fruit is SIMD optimziations and implementations that take
> advantage of separability. It may also be interesting to speed up
> pixman_filter_create_separable_convolution() by tabularizing some of
> the trigonometric functions etc.
>
> - A non-separable, but subsampled, convolution filter type could be
> interesting to allow correct filters for non-scaling transformations
> and non-separable filters in general.
>
>
> As a reward for reading this entire mail, here are some images:
>
> Original (2.6 MB):
>
> http://www.daimi.au.dk/~sandmann/house.jpg
>
> Scaled down 12.9 times in each dimension:
>
> - With a box filter:
>
> http://www.daimi.au.dk/~sandmann/house-box.png
>
> - With Lanczos3:
>
> http://www.daimi.au.dk/~sandmann/house-lanczos3.png
>
> - With stretched Lanczos3:
>
> http://www.daimi.au.dk/~sandmann/house-nice.png
>
> For more examples, try demos/scale.
>
> The patch series is also available in this repository:
>
> http://cgit.freedesktop.org/~sandmann/pixman/log/?h=separable
>
>
> Soren
> _______________________________________________
> Pixman mailing list
> Pixman at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pixman
>
--
behdad
http://behdad.org/
From ajohnson at redneon.com Fri Nov 23 22:11:47 2012
From: ajohnson at redneon.com (Adrian Johnson)
Date: Sat, 24 Nov 2012 16:41:47 +1030
Subject: [cairo] Image resampling [PATCH 0/6]
In-Reply-To:
References:
Message-ID: <50B06523.6050505@redneon.com>
On 24/11/12 14:27, S?ren Sandmann wrote:
> -=- Adding support to cairo and further work
>
> Once these patches have landed in Pixman, support will have to be
> added to cairo to make use of them. How to do that exactly requires
> figuring out what new API to offer, and how the tradeoffs between
> performance and quality should be made. This is not something that I
> personally plan to work on anytime soon, except to make three notes:
It would be useful to have an API for downscaling that does not require
the entire source image to be loaded into memory. I've recently updated
the downscaling box filter code in the cairo backend of poppler to read
the source image one line at a time as it is uncompressed from the pdf
file. This was to fix a bug where rendering a PDF containing a
21,590 x 161,385 1 bit/pixel image failed due to the 32,767 x 32,767
image limit.
From siarhei.siamashka at gmail.com Sun Nov 25 23:27:59 2012
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Mon, 26 Nov 2012 09:27:59 +0200
Subject: [cairo] [Pixman] [PATCH 6/6] Add demos/zone_plate.png
In-Reply-To: <1353730531-5011-6-git-send-email-sandmann@cs.au.dk>
References:
<1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
<1353730531-5011-6-git-send-email-sandmann@cs.au.dk>
Message-ID: <20121126092759.2c881d12@i7>
On Fri, 23 Nov 2012 23:15:31 -0500
S?ren Sandmann wrote:
> From: S?ren Sandmann Pedersen
>
> The zone plate image is a useful test case for image scalers because
> it contains all representable frequencies, so any imperfection in
> resampling filters will show up as Moire patterns.
>
> This version is symmetric around the midpoint of the image, so since
> rotating it is supposed to be a noop, it can also be used to verify
> that the resampling filters don't shift the image.
> ---
> demos/zone_plate.png | Bin 0 -> 522879 bytes
> 1 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 demos/zone_plate.png
Hi, the size of this PNG file can be cut in half:
$ optipng -o7 zone_plate.png
** Processing: zone_plate.png
512x512 pixels, 3x8 bits/pixel, RGB
Reducing image to 8 bits/pixel, grayscale
Input IDAT size = 522048 bytes
Input file size = 522879 bytes
Trying:
zc = 9 zm = 9 zs = 0 f = 0 IDAT size = 231093
zc = 8 zm = 9 zs = 0 f = 0 IDAT size = 231093
zc = 7 zm = 9 zs = 0 f = 0 IDAT size = 231093
zc = 6 zm = 9 zs = 0 f = 0 IDAT size = 231093
zc = 5 zm = 9 zs = 0 f = 0 IDAT size = 231093
zc = 3 zm = 9 zs = 0 f = 0 IDAT size = 228661
zc = 3 zm = 9 zs = 1 f = 0 IDAT size = 228661
Selecting parameters:
zc = 3 zm = 9 zs = 1 f = 0 IDAT size = 228661
Output IDAT size = 228661 bytes (293387 bytes decrease)
Output file size = 228732 bytes (294147 bytes = 56.26% decrease)
--
Best regards,
Siarhei Siamashka
From sandmann at cs.au.dk Mon Nov 26 03:37:37 2012
From: sandmann at cs.au.dk (=?utf-8?Q?S=C3=B8ren?= Sandmann)
Date: Mon, 26 Nov 2012 12:37:37 +0100
Subject: [cairo] [Pixman] [PATCH 6/6] Add demos/zone_plate.png
In-Reply-To: <20121126092759.2c881d12@i7> (Siarhei Siamashka's message of
"Mon, 26 Nov 2012 09:27:59 +0200")
References:
<1353730531-5011-1-git-send-email-sandmann@cs.au.dk>
<1353730531-5011-6-git-send-email-sandmann@cs.au.dk>
<20121126092759.2c881d12@i7>
Message-ID:
Siarhei Siamashka writes:
> Hi, the size of this PNG file can be cut in half:
>
> $ optipng -o7 zone_plate.png
> ** Processing: zone_plate.png
> 512x512 pixels, 3x8 bits/pixel, RGB
> Reducing image to 8 bits/pixel, grayscale
> Input IDAT size = 522048 bytes
> Input file size = 522879 bytes
Good point. I'll run it through optipng before pushing.
Soren
From ckling at upcmail.nl Mon Nov 26 06:51:29 2012
From: ckling at upcmail.nl (Kees Kling)
Date: Mon, 26 Nov 2012 15:51:29 +0100
Subject: [cairo] Missing transparency in ImageSurface
Message-ID: <50B381F1.6000404@upcmail.nl>
Hi,
I have an in memory dataset which I want to overlay over a background
Here is the part I'm doing the overlay
Cairo::RefPtr radarModule::composeProduct() {
Cairo::RefPtr sfc =
Cairo::ImageSurface::create(Cairo::FORMAT_ARGB32, 800, 800);
Cairo::RefPtr cr = Cairo::Context::create(sfc);
cr->set_source(background->getLayers(),0,0);
cr->paint();
if (dataset != NULL) {
cr->save();
cr->set_operator(Cairo::OPERATOR_ATOP);
cr->set_source(radarSfc,0,0);
cr->paint();
cr->restore();
}
return sfc;
}
And here is the part where I create a surface from a unsigned char buffer
void radarModule::drawImage() {
// storing GdalDataset in an buffer;
// this will be a one byte per pixel data
int bufferSize = dataset->GetRasterXSize() *
dataset->GetRasterYSize();
unsigned char* buffer = (unsigned char*) CPLMalloc(sizeof(char) *
bufferSize);
// convert this data with colortable to ARGB 4 bytes per pixel data
unsigned char* colorbuffer = (unsigned char*)
CPLMalloc(sizeof(char) * bufferSize * 4 );
try {
dataset->getPixelData(buffer);
} catch ( string &e) {
ctrl->getLogger()->errorStream()<getColor(buffer[i]).getColor(r,g,b,a);
colorbuffer[ i * 4 ] = b;//b
colorbuffer[ (i * 4) + 1 ] = g;//g
colorbuffer[ (i * 4) + 2 ] = r;//r
colorbuffer[ (i * 4) + 3 ] = a;//a
}
int stride =
Cairo::ImageSurface::format_stride_for_width(Cairo::FORMAT_ARGB32,dataset->GetRasterXSize());
// Here creating the image surface and draw the pixels on
radarSfc =
Cairo::ImageSurface::create(colorbuffer,Cairo::FORMAT_ARGB32,
dataset->GetRasterXSize(), dataset->GetRasterYSize(), stride);
CPLFree(buffer);
//CPLFree(colorbuffer);
//radarSfc = Cairo::ImageSurface::create_from_png("r.png");
radarSfc->write_to_png("r.png");
}
before I construct the image I'm adding a colortable, bcause the dataset
is an index array
If I run this code al parts which are fully transparent turns out white,
but in the l;ast line I save the surface as
png.file and that image is correct according to gimp.
I also tried to create the surface of the png file from disk and then
the alpha blending is ok.
What am I doing wrong??
regards
Kees Kling
From hsong at sisa.samsung.com Mon Nov 26 11:02:16 2012
From: hsong at sisa.samsung.com (Henry (Yu) Song - SISA)
Date: Mon, 26 Nov 2012 19:02:16 +0000
Subject: [cairo] [patch] gl: flush drawing before gradient is destroyed
Message-ID: <3955FA337689574EB32F94B12A7E6E9E2483A30D@sisaex01sj>
>From 2bca0ff7652925ae47ac76a4c1a1d04739ae3a4c Mon Sep 17 00:00:00 2001
From: Henry Song
Date: Mon, 26 Nov 2012 10:58:15 -0800
Subject: [PATCH] random remove gradient can possibly remove a gradient that
has not been flushed. Force previous drawing to flush when
a gradient is destroyed
---
src/cairo-gl-gradient.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/cairo-gl-gradient.c b/src/cairo-gl-gradient.c
index 1c1f972..3e4f499 100644
--- a/src/cairo-gl-gradient.c
+++ b/src/cairo-gl-gradient.c
@@ -328,6 +328,7 @@ _cairo_gl_gradient_destroy (cairo_gl_gradient_t *gradient)
return;
if (_cairo_gl_context_acquire (gradient->device, &ctx) == CAIRO_STATUS_SUCCESS) {
+ _cairo_gl_composite_flush (ctx);
glDeleteTextures (1, &gradient->tex);
ignore = _cairo_gl_context_release (ctx, CAIRO_STATUS_SUCCESS);
}
--
1.7.10.4
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From spitzak at gmail.com Mon Nov 26 18:44:21 2012
From: spitzak at gmail.com (Bill Spitzak)
Date: Mon, 26 Nov 2012 18:44:21 -0800
Subject: [cairo] Image resampling [PATCH 0/6]
In-Reply-To:
References:
Message-ID: <50B42905.6000102@gmail.com>
S?ren Sandmann wrote:
> Hi,
>
> Reviewing the supersampling patch here:
>
> http://cgit.freedesktop.org/~ajohnson/pixman/log/?h=supersampling
>
> I wasn't happy with either the performance and image quality, and I
> realized that the whole supersampling approach just isn't going to
> fly. Since I told people to do it that way, I apologize for that. The
> approach advocated by Bill Spitzak in the various downsampling threads
> of computing a convolution kernel up front, is the much better way to
> go. To make up for being misleading, the following patches implement
> comprehensive support for high-quality image scaling filters.
This is great news!
> -=- Adding support to cairo and further work
>
> Once these patches have landed in Pixman, support will have to be
> added to cairo to make use of them. How to do that exactly requires
> figuring out what new API to offer, and how the tradeoffs between
> performance and quality should be made. This is not something that I
> personally plan to work on anytime soon, except to make three notes:
Cairo may want to pre-scale the source surface by an integer factor
using a box filter so that the sampling filters are not so large. It
would then have to keep this scaled image around until either the source
image is dirtied or a transform requiring a different scale is used. I
would think this could speed up repeated drawing of a much-scaled-down
image considerably. It does seem to me that such a step should be done
by cairo rather than pixman. The alternative is for client programs to
do this with extra Cairo surfaces for the scaled images, but that seems
to not be keeping with the easy-to-use api intentions of Cairo.
The scale would be chosen so the intermediate image is no smaller than
2x the final result. This seems to hide any problems with the box
filter. It kind of makes sense because we are reusing the sampling
filter at intervals that are less than 1/2 which is below the nyquist
frequency for the sync.
> - While transformations that are not pure scalings will not
> generally result in a separable filter, OK-looking results for
> non-scalings can be achieved by using scaling factors based on the
> bounding box of a transformation
Having recently wasted some time on this, I discovered that in fact
these sampling filters *rely* on the separable property. The lancos and
sync filters do not work if when they are centered on a pixel the
neighboring pixels are not at the zeros in the filter. The only way to
do this is for the filter to be a product of 2 1-D filters that are
aligned with the source pixel grid. If they were at an angle, the zeros
would be at an angle and thus could not all hit pixel centers. Trying to
make it circular (as I was doing) also fails for the same reason. An
obvious error is that the identity transformation results in ringing and
sharpening being added to the picture. With aligned separable filters
and a filter that is zero at all integers other than 0 the result is an
identity, which is much more likely what users want.
Therefore it looks like you have already gotten most of what is needed.
The two sizes are fairly easy to figure out from the inverse
transformation matrix (ie the inverse of the matrix a Cairo user sets,
but the one needed to find the source image pixel given an output
position) (WARNING: I may have b/c swapped from what Cairo/pixman code
uses):
[ a b 0 ] [ X ]
inxy= [ c d 0 ] * [ Y ]
[ x y 1 ] [ 1 ]
The horizontal size is hypot(a,b) and the vertical size is hypot(c,d).
This is the width/height of the bounding box of the ellipse you get if a
.5-radius circle is transformed by this matrix.
From spitzak at gmail.com Mon Nov 26 18:53:01 2012
From: spitzak at gmail.com (Bill Spitzak)
Date: Mon, 26 Nov 2012 18:53:01 -0800
Subject: [cairo] Image resampling [PATCH 0/6]
In-Reply-To: <50B06523.6050505@redneon.com>
References: <50B06523.6050505@redneon.com>
Message-ID: <50B42B0D.70207@gmail.com>
Adrian Johnson wrote:
> On 24/11/12 14:27, S?ren Sandmann wrote:
>> -=- Adding support to cairo and further work
>>
>> Once these patches have landed in Pixman, support will have to be
>> added to cairo to make use of them. How to do that exactly requires
>> figuring out what new API to offer, and how the tradeoffs between
>> performance and quality should be made. This is not something that I
>> personally plan to work on anytime soon, except to make three notes:
>
> It would be useful to have an API for downscaling that does not require
> the entire source image to be loaded into memory. I've recently updated
> the downscaling box filter code in the cairo backend of poppler to read
> the source image one line at a time as it is uncompressed from the pdf
> file. This was to fix a bug where rendering a PDF containing a
> 21,590 x 161,385 1 bit/pixel image failed due to the 32,767 x 32,767
> image limit.
Yes I think Cairo will have to downrez an image before applying this
filtering. It could keep the downrez image around until a different
downrez is needed or the source image is damaged. I now think this down
rez could be restricted to powers of 2 and a box filter, allowing it to
be run very quickly with a recursive version that never needs more than
2 source lines at a time.
Unless the filter is box, the downrez has to make the image no smaller
than 2x the final size, to avoid hiding the nice aspects of the filters.
There is also a problem where a huge image is not scaled down, so this
source image is not any smaller. But in that case it would be clipped,
so a temporary source image that is clipped to only the area that
projects to the output clip is needed. This clipped image can be
produced by code that only looks at 1 source line at a time.
Combining them and assuming the worst possible case (a scale of
1/3.9999... and a rotation by 45 degrees) it looks like the maximum
texture size would be the size of the output surface multiplied by
4*sqrt(2). That may still be a problem if the maximum texture size is
equal to the maximum output size. Perhaps it could just produce a blurry
picture in that case by downrezing excessively.
From siarhei.siamashka at gmail.com Tue Nov 27 01:51:29 2012
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 27 Nov 2012 11:51:29 +0200
Subject: [cairo] [Pixman] Image resampling [PATCH 0/6]
In-Reply-To:
References:
Message-ID: <20121127115129.25e69acc@i7>
On Sat, 24 Nov 2012 04:57:22 +0100
sandmann at cs.au.dk (S?ren Sandmann) wrote:
> Hi,
>
> Reviewing the supersampling patch here:
>
> http://cgit.freedesktop.org/~ajohnson/pixman/log/?h=supersampling
>
> I wasn't happy with either the performance and image quality, and I
> realized that the whole supersampling approach just isn't going to
> fly. Since I told people to do it that way, I apologize for that. The
> approach advocated by Bill Spitzak in the various downsampling threads
> of computing a convolution kernel up front, is the much better way to
> go. To make up for being misleading, the following patches implement
> comprehensive support for high-quality image scaling filters.
>
> Pixman already has a convolution filter, but since it only allows one
> sample per pixel of the filter, it is limited in the quality that it can
> support, so the following patches (to be applied on top of the three
> rounding patches) add a new filter type
>
> PIXMAN_FILTER_SEPARABLE_CONVOLUTION
>
> that supports multiple different convolution matrices that are chosen
> between based on the subpixel source location. The matrices are
> specified as tensor products of x/y vectors, which makes them
> separable by definition.
I like this approach. This is a clean design, which look simple enough
to optimize for better performance with SIMD.
> -=- Further work and examples
>
> There is some additional work that could be done:
>
> - Performance improvements. Low-hanging fruit includes adding new fast
> path iterators that assume the source is a8r8g8b8 or r5g6b5. Higher
> hanging fruit is SIMD optimziations and implementations that take
> advantage of separability. It may also be interesting to speed up
> pixman_filter_create_separable_convolution() by tabularizing some of
> the trigonometric functions etc.
From what I see, the separable convolution filter shares a lot of
similarities with the existing pixman SIMD code for bilinear scaling,
which could be extended with relatively little effort.
Bilinear scaling uses weighted average of 2 pixels (in one direction),
with weights calculated on the go. Separable convolution uses weighted
average of N pixels, with weights obtained by table lookups. Both use
subpixel positions (7 phase bits or 128 phases for current bilinear
implementation) to lookup or calculate weights. Bilinear filter is
naturally a subset of separable convolution.
The biggest challenge for optimized bilinear scaling (compared to
nearest) had been properly implementing different types of repeat on
image edges due to sampling of some pixels outside of the image
boundaries. But "many" pixels from the separable convolution filter is
not much different from just "two" from the (bi)linear filter in this
respect, so this should already work fine also for separable
convolution with just minor tweaks.
Regarding SIMD optimized iterators (for both bilinear and separable
convolution), they are rather simple to implement as well. Just have a
look at my old OpenMP proof of concept patch:
http://lists.freedesktop.org/archives/pixman/2012-June/002071.html
The OMP_BILINEAR_PARALLEL_FOR define lists all the variables which
fully represent the state of the iterator, needed to walk over the
source image and scale it (only the loop counter 'i' is different for
each scanline). This state can be calculated when creating an
iterator, and then we can simply pull one scaled scanline at a time.
The fact that the current bilinear code is not separable is a minor
implementation detail, we could as well have 2x1 sized filter instead
of 2x2 and then do vertical scaling separately with the help of a
temporary buffer in L1 cache like you tried before in the
"separable-bilinear" branch:
http://lists.freedesktop.org/archives/pixman/2012-June/002140.html
And I tried a similar "two-passes in L1 cache" approach for YUV->RGB
scaling code prototype much earlier, with reasonably good results:
https://bugzilla.mozilla.org/show_bug.cgi?id=634557#c53
So this is expected to provide good performance.
Affine transformations (still to be implemented with SIMD) are a bit
different and iterators are not a very good choice for them due to less
than perfect memory access pattern.
--
Best regards,
Siarhei Siamashka
From dy5.kim at samsung.com Tue Nov 27 03:42:53 2012
From: dy5.kim at samsung.com (Dongyeon Kim)
Date: Tue, 27 Nov 2012 11:42:53 +0000 (GMT)
Subject: [cairo] Question regarding cairo-trace for map-to-image and
unmap-image
Message-ID: <19656184.119341354016573454.JavaMail.weblogic@epml01>
Hello,
I have a working cairo sample that uses map-to-image to map gl surface to image surface, and unmaps afterwards.
I have created a trace file for the sample using cairo-trace, but when I try to run the trace file using cairo-perf-trace, I get the following error.
[ 0] egl cairo_gl_map_to_image.5695 Error during replay, line 30: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
[ # ] image: pixman 0.26.0
[ 0] image cairo_gl_map_to_image.5695 Error during replay, line 30: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
[ # ] image16: pixman 0.26.0
[ 0] image16 cairo_gl_map_to_image.5695 Error during replay, line 30: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
It seems that when trying to run unmap-image from script it is not getting the right parameters.
Here is the full trace file: http://pastebin.com/eKCGquiG
Can anyone tell me how to resolve this problem?
Dongyeon
From chris at chris-wilson.co.uk Tue Nov 27 04:29:20 2012
From: chris at chris-wilson.co.uk (Chris Wilson)
Date: Tue, 27 Nov 2012 12:29:20 +0000
Subject: [cairo] Question regarding cairo-trace for map-to-image and
unmap-image
In-Reply-To: <19656184.119341354016573454.JavaMail.weblogic@epml01>
References: <19656184.119341354016573454.JavaMail.weblogic@epml01>
Message-ID: <84c8a8$6mit26@orsmga001.jf.intel.com>
On Tue, 27 Nov 2012 11:42:53 +0000 (GMT), Dongyeon Kim wrote:
> Hello,
>
> I have a working cairo sample that uses map-to-image to map gl surface to image surface, and unmaps afterwards.
> I have created a trace file for the sample using cairo-trace, but when I try to run the trace file using cairo-perf-trace, I get the following error.
>
> [ 0] egl cairo_gl_map_to_image.5695 Error during replay, line 30: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
> [ # ] image: pixman 0.26.0
> [ 0] image cairo_gl_map_to_image.5695 Error during replay, line 30: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
> [ # ] image16: pixman 0.26.0
> [ 0] image16 cairo_gl_map_to_image.5695 Error during replay, line 30: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
>
> It seems that when trying to run unmap-image from script it is not getting the right parameters.
Whoops, the operand emission for map-to-image and unmap-image was plain
broken. Please try again with:
commit 376d39121c0d4eba8f0a22be71f782ce18e50923
Author: Chris Wilson
Date: Tue Nov 27 12:25:56 2012 +0000
trace: Fix operand emission for map-to-image and unmap-image
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From gpslocator at gmail.com Tue Nov 27 07:04:56 2012
From: gpslocator at gmail.com (gps locator)
Date: Tue, 27 Nov 2012 23:04:56 +0800
Subject: [cairo] Build cairo-1.12.6 failed
In-Reply-To:
References:
Message-ID:
Build error log:
CC cairo-xlib-display.lo
In file included from cairo-xlib-private.h:41,
from cairo-xlib-display.c:40:
cairo-xlib-xrender-private.h:102: error: redefinition of 'struct
_XLinearGradient'
cairo-xlib-xrender-private.h:105: error: conflicting types for
'XLinearGradient'
/usr/include/X11/extensions/Xrender.h:189: note: previous declaration of
'XLinearGradient' was here
cairo-xlib-xrender-private.h:111: error: redefinition of 'struct _XCircle'
cairo-xlib-xrender-private.h:115: error: conflicting types for 'XCircle'
/usr/include/X11/extensions/Xrender.h:150: note: previous declaration of
'XCircle' was here
cairo-xlib-xrender-private.h:116: error: redefinition of 'struct
_XRadialGradient'
cairo-xlib-xrender-private.h:119: error: conflicting types for
'XRadialGradient'
/usr/include/X11/extensions/Xrender.h:194: note: previous declaration of
'XRadialGradient' was here
cairo-xlib-xrender-private.h:125: error: redefinition of 'struct
_XConicalGradient'
cairo-xlib-xrender-private.h:128: error: conflicting types for
'XConicalGradient'
/usr/include/X11/extensions/Xrender.h:199: note: previous declaration of
'XConicalGradient' was here
make[3]: *** [cairo-xlib-display.lo] Error 1
Here is a similar issue:
http://lists.cairographics.org/archives/cairo/2011-March/021822.html
I wondered that no one met this issue now and what's the best solution for
that?
Thanks,
L.J
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From spitzak at gmail.com Tue Nov 27 12:09:14 2012
From: spitzak at gmail.com (Bill Spitzak)
Date: Tue, 27 Nov 2012 12:09:14 -0800
Subject: [cairo] [Pixman] Image resampling [PATCH 0/6]
In-Reply-To: <20121127115129.25e69acc@i7>
References: <20121127115129.25e69acc@i7>
Message-ID: <50B51DEA.2060808@gmail.com>
Siarhei Siamashka wrote:
> Bilinear scaling uses weighted average of 2 pixels (in one direction),
> with weights calculated on the go. Separable convolution uses weighted
> average of N pixels, with weights obtained by table lookups. Both use
> subpixel positions (7 phase bits or 128 phases for current bilinear
> implementation) to lookup or calculate weights. Bilinear filter is
> naturally a subset of separable convolution.
Also note that the separable filters need different "widths" as well as
different phases. This is the distance from the center to the first 0
crossing in a sync filter, note that the non-zero part of the filter is
several times the width (3 for a triangle, 5 for most, and 7 for
lancos3). If the image is being scaled by 1/N the width is max(1,N).
There probably should be a pre-calculated table of all combinations of
width and phase. The minimum width is 1, but there will have to be a
maximum chosen. Pixman would use the maximum if a larger size is wanted,
which would mean that scales smaller than a certain value would be
noisy. However if Cairo prescales by a power of 2 then the maximum scale
may be 4.
In Nuke the pre-calculated table is just a very wide filter (I think the
width is 64) and that is the maximum filter size. Smaller filters and
different offsets are chosen by subsampling this large filter at even
intervals (Nuke chose the closest sample, but bilinear sampling would be
better). The table was "normalized" so that the width of 1 produced
samples that sum to 1, all larger filters needed to a normalization
factor calculated by doing 1/sum of the samples.
From tweenk.pl at gmail.com Tue Nov 27 16:51:09 2012
From: tweenk.pl at gmail.com (=?UTF-8?Q?Krzysztof_Kosi=C5=84ski?=)
Date: Wed, 28 Nov 2012 01:51:09 +0100
Subject: [cairo] Image resampling [PATCH 0/6]
In-Reply-To: <50B42905.6000102@gmail.com>
References:
<50B42905.6000102@gmail.com>
Message-ID: