http://permalink.gmane.org/gmane.comp.lib.cairo hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.cairo/22729 <pre> You can implement a rwlock using two mutexes and a counter... behdad -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Behdad Esfahbod 2012-05-25T23:01:49 http://permalink.gmane.org/gmane.comp.lib.cairo/22728 <pre>Hi! I'm Synfig developer and I am working on incorporate Cairo graphics on current Synfig render method. Synfig is a 2D vector animation application but it has some particularities. It does support layers that act like raster filters (blur, distortions, etc.) apart of the typical geometry layers (circle, rectangle, polygon, bezier shape. etc). Synfig has its own Surface system that uses float ARGB color and HDR support. Each geometry layer renders its content using the Synfig surface primitives (very simple ones). The filter layers does its filter job by asking the the layers below it for the color result on a given user space point (x,y). Doing a subsampling of the returned value around the pixel position allows to render properly the filter layer. So all the geometry layers should define a function to return the color that it renders based on a give x,y position. When Cairo were implemented, floating point color and HDR will be lost. But that's not the problem. My plan to implement Cairo libraries is re</pre> Carlos López González 2012-05-25T13:16:16 http://permalink.gmane.org/gmane.comp.lib.cairo/22727 <pre>If a _finishing is set then the snapshot can stealing the target's buffer. After the first snapshot get the target's buffer, it should clear this bit then the Following snapshots will not try to get it again. It's not related to the cairo_surface_finish(). Will fix it. Correct, will change to use bool. *surface_extents, &amp;command-&gt;paint.source.base, No, no deadlock here. We use rdlock here, not wrlock. Rdlock will not block each other. Oh, wait, for those platforms doesn't have a rwlock implementation and use a mutex instead, we do have a deadlock condition here.... emm any comments for that situation? &amp;command-&gt;mask.source.base, &amp;command-&gt;stroke.source.base, command-&gt;stroke.tolerance, command-&gt;stroke.antialias, command-&gt;fill.antialias, command-&gt;header.op, command-&gt;header.clip); Will fix it. &amp;command-&gt;stroke.source.base, command-&gt;header.op, command-&gt;header.clip); (On The recording surface replaying will only use rdlock thus will not cause deadlock. And the COW will only hold one lock and also will not cause</pre> Zhigang Gong 2012-05-25T11:10:52 http://permalink.gmane.org/gmane.comp.lib.cairo/22726 <pre>Hi, On 25.05.2012 11:13, Zhigang Gong wrote: [...] Whoa? Why? This smells quite fishy to me. Just changing a boolean won't stop cairo_surface_finish() from doing its job, right? Minor nitpicking: That "*/" looks misplaced. This function should return cairo_bool_t, not int. Couldn't this deadlock? Thread A uses mask 1 and source 2, thread B uses mask 2 and source 1. If both first lock their source, they'd deadlock on the mask. Does anyone have a good idea how the locking could be simplified here? That looks quite complex. This is used as a boolean, so cairo_bool_t here, too, please. I'd like to simplify this, too, but I don't have any good idea on how. :-( (On and the MASK version has the same possible-deadlock) [...] That looks quite random. Why is it in this patch? Before, this code made sure that it held a reference to the snapshot while reading its status. Why? Could that cause problems here (=use after free)? [...] How about adding an assert? assert (! CAIRO_REFERENCE_COUNT_HAS_REFER</pre> Uli Schlachter 2012-05-25T10:13:13 http://permalink.gmane.org/gmane.comp.lib.cairo/22725 <pre>Hi, On 25.05.2012 11:13, Zhigang Gong wrote: Could you also write a test case for the test suite? That would make sure that this actually fixes what it wants to fix (and makes it easier to see what that is). [...] Why is "a normal lock" not a cairo_mutex_t? It looks like this patch just copied all the non-pthread code from cairo mutex. [...] [...] All of the above should be replaceable with: #if CAIRO_HAS_PTHREAD [the pthread stuff as-is above] #else typedef cairo_mutex_t cairo_rwlock_impl_t # define CAIRO_RWLOCK_IMPL_INIT(rwlock) CAIRO_MUTEX_INIT(rwlock) # define CAIRO_RWLOCK_IMPL_RDLOCK(rwlock) CAIRO_MUTEX_LOCK(rwlock) [etc] #endif Do I miss a point which makes this not possible? [...] [...] Who is Mathias? Is this copy&amp;paste from cairo-mutex.c? What the heck? Just remove all of this (including the stuff for this in the headers) and done? This doesn't do anything at all and it's not even called from anywhere, is it? Uli </pre> Uli Schlachter 2012-05-25T09:56:51 http://permalink.gmane.org/gmane.comp.lib.cairo/22724 <pre>Simply protect the whole replaying stage here, we may fine tune the protect region in the future. This commit also break the "self-copy" bug. Here self-copy means, replay a recording surface to a surface which is some of the snapshot's target surface. Then it may cause a "race" condition even with single thread. As now the accessing from the snapshot side must hold a rdlock, then the surface's handling side is easier than before. We do not need the snapshot side to touch the surface's reference counter now, the wrlock at the COW function is enough to avoid race. Slightly change the surface's pointer stealing. We set the _finishing before call the cairo_surface_flush, then latter the first snapshot will steal its pointer and then clear the bit, and the other snapshots will have to create new buffer. Signed-off-by: Zhigang Gong &lt;zhigang.gong&lt; at &gt;linux.intel.com&gt; --- src/cairo-image-source.c | 33 ++--------- src/cairo-image-surface.c | 1 + src/cairo-pdf-surface.c | 13 +</pre> Zhigang Gong 2012-05-25T09:13:49 http://permalink.gmane.org/gmane.comp.lib.cairo/22723 <pre>As we will use rwlock to fix the COW/replaying race condition, we prefer to use one lock rather than two locks for one snapshot. Signed-off-by: Zhigang Gong &lt;zhigang.gong&lt; at &gt;linux.intel.com&gt; --- src/cairo-surface-snapshot-inline.h | 4 ++-- src/cairo-surface-snapshot-private.h | 4 ++-- src/cairo-surface-snapshot.c | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/cairo-surface-snapshot-inline.h b/src/cairo-surface-snapshot-inline.h index bf89c77..48b24a4 100644 --- a/src/cairo-surface-snapshot-inline.h +++ b/src/cairo-surface-snapshot-inline.h &lt; at &gt;&lt; at &gt; -51,9 +51,9 &lt; at &gt;&lt; at &gt; _cairo_surface_snapshot_get_target (cairo_surface_t *surface) cairo_surface_snapshot_t *snapshot = (cairo_surface_snapshot_t *) surface; cairo_surface_t *target; - CAIRO_MUTEX_LOCK (snapshot-&gt;mutex); + CAIRO_RWLOCK_WRLOCK (snapshot-&gt;rwlock); target = _cairo_surface_reference (snapshot-&gt;target); - CAIRO_MUTEX_UNLOCK (snapshot-&gt;mutex); + CAIRO_RWLOCK_UNLOCK (snapshot-&gt;rwlock);</pre> Zhigang Gong 2012-05-25T09:13:48 http://permalink.gmane.org/gmane.comp.lib.cairo/22722 <pre>Here is a scenario which make us to introduce rwlock. 1. One thread(A) is rendering to a surface which has a snapshot attached. 2. Some other threads(B...) are replaying recording surfaces which has the snapshot of the surface which is being rendered in thread 1. If thread B already started the replaying, and already get the source by using _cairo_surface_snapshot_source, then before the thread B finish its accessing to the source surface, the thread A start to rendering to the source surface. Although thread A will trigger a COW, but it's too late, as thread B already got the original surface pointer, thus the race ocurrs here, both B is reading and A is writing to the same area concurrently. To fix this issue, we need to use write lock at thread B, and use read lock at thread B to avoid the possible race condtion. Currently, we only implement pthread_rw_lock if the system supports pthread. Otherwise, we degrade the rw_lock to a normal lock. Signed-off-by: Zhigang Gong &lt;zhigang.gong&lt; at &gt;linux.intel.com&gt; ---</pre> Zhigang Gong 2012-05-25T09:13:47 http://permalink.gmane.org/gmane.comp.lib.cairo/22721 <pre>If we do something like following: cr1 = cairo_create(surf1); cr2 = cairo_create(surf2); ... draw something to surf1 ... cairo_set_source_surface(cr2, surf1); cairo_rectangle(cr2, ..... ); cairo_fill(cr2); You will find the current code will reference a texture in cr1 gl context while drawing cr2. Thus it references a null texture and results to wrong rendering. This patch severs as fixing this issue(like gl-surface-source test case) by copying out the texture from cr1, then regenerating a new one to cr2. Signed-off-by: Yuanhan Liu &lt;yuanhan.liu&lt; at &gt;linux.intel.com&gt; --- src/cairo-gl-composite.c | 77 +++++++++++++++++++++++++++++++++++++-- src/cairo-gl-glyphs.c | 3 +- src/cairo-gl-private.h | 4 ++- src/cairo-gl-spans-compositor.c | 5 +-- src/cairo-gl-surface.c | 7 ++++ src/cairo-gl-traps-compositor.c | 12 ++---- 6 files changed, 91 insertions(+), 17 deletions(-) diff --git a/src/cairo-gl-composite.c b/src/cairo-gl-composite.c index bcf41ec..97c</pre> Yuanhan Liu 2012-05-24T11:37:49 http://permalink.gmane.org/gmane.comp.lib.cairo/22720 <pre> The FAQ explains this pretty well: http://www.cairographics.org/FAQ/ (See 'How do I paint from one surface to another?') -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Roger Davis 2012-05-23T19:15:24 http://permalink.gmane.org/gmane.comp.lib.cairo/22719 <pre>Hello everyone, i would like to know how to create two surfaces. On the first surface i want to draw circle and ellipse... On the second surdace i want to draw rectangle. I would like to copy portion of the second surface to the first surface? Could someone help me, please, posting a little example of this? Thank you very much. -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo</pre> Davide Calaminici 2012-05-23T18:29:24 http://permalink.gmane.org/gmane.comp.lib.cairo/22718 <pre> Ouch, definitely! Amended, thank you! Andrea -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Andrea Canciani 2012-05-23T08:52:37 http://permalink.gmane.org/gmane.comp.lib.cairo/22717 <pre>The commit message is incorrect: ...should *NOT* cause cairo builds... -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Maarten Bosmans 2012-05-23T08:31:47 http://permalink.gmane.org/gmane.comp.lib.cairo/22716 <pre> The code in cairo_egl_device_create() is not related to any surface that you will be using for rendering. Its only purpose is to allow us to make a valid surface current in order to perform the device initialization. It shouldn't make a difference in this case: cairo surfaces that are created by cairo_gl_surface_create() are backed by textures, not by any type of EGL surface. I don't know what you are trying to achieve, so this may be way off base, but is CAIRO_CONTENT_ALPHA what you want here? Perhaps you need CAIRO_CONTENT_COLOR_ALPHA? Even if you actually need CAIRO_CONTENT_ALPHA, it's worth trying out a simpler example first to get a better feeling of what may be wrong. Also are you sure you are actually painting correctly to the gl surface? What happens if instead of a gl surface you use, e.g., an image surface? Do you get any output then? Thanks, Alexandros -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Alexandros Frantzis 2012-05-21T09:26:03 http://permalink.gmane.org/gmane.comp.lib.cairo/22715 <pre>Hi,Henry i found the implementation of the method cairo_egl_device_create(display, context) is very strange,as below: 1. init attribs with EGL_WIDTH=1and EGL_HEIGHT=1 2. init config use eglChooseConfig method 3. create EGLSurface use eglCreatePbufferSurface method 4. then use eglMakeCurrent to release 5. last, return as &amp;ctx-&gt;base.base problems: 1.EGLSurface's width and height both were set to 1 but the method cairo_gl_surface_create supply two parameters for setting width and height another thing, the code i send before should set EGL_SURFACE_TYPE=EGL_PUBUFFER_BIT not EGL_SURFACE_TYPE=EGL_WINDOW_BIT but still nothing display in my phone. 2012/5/18 Jihe Wei &lt;jihe.wei&lt; at &gt;gmail.com&gt; -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo</pre> Jihe Wei 2012-05-21T08:20:17 http://permalink.gmane.org/gmane.comp.lib.cairo/22714 <pre>Hi, how can I load a TrueType Font in cairo? I need to render some test on a surface (DirectFB backend, but I think that is not relevant), using a monospaced font. I tried Pango libraries, but it takes the font from FontConfig and I can't properly configure the width an height of the font, I can't resize the font to fit in a precise logical extent. Cairo scaled font seems to be useful for my purpose, but I don't understand how to load a *ttf. Thank you in advance Carlo -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Carlo 2012-05-20T14:01:58 http://permalink.gmane.org/gmane.comp.lib.cairo/22713 <pre>Hi, 19-05-2012 14:16 tarihinde, Chris Wilson wrote: (Thanks for responding) I prepared a minimal win32 sample using my compilation of Cairo-1.12.2; uploaded here: http://www.dynaset.org/dogusanh/download/cairotest.zip (1.8MiB) I've put Code::Blocks project files, configuration files of Cairo and pixman in it. When you resize the frame, program gets SIGSEGV. PS. To compile 1.12.2 I've added HAVE_UINT64_T compile flag to project; otherwise getting compile error in cairo-wideint-private.h around line 58. There uint64_t used in #if !HAVE UINT64_T block. If one changes them to cairo_uint64_t than compilation stops at cairo-time.c around line 113; "return t.QuadPart;". -- Regards, Hakki Dogusan -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo </pre> Hakki Dogusan 2012-05-20T09:15:40 http://permalink.gmane.org/gmane.comp.lib.cairo/22712 <pre> Is there any chance you can produce a small bit of code to reproduce the error? The on-stack values are within reason, so we need to dig further into the structures to find where the error occurs. A "bt full" would be a first step, followed by a p *surface on all the images and surfaces at various frames. -Chris </pre> Chris Wilson 2012-05-19T11:16:55 http://permalink.gmane.org/gmane.comp.lib.cairo/22711 <pre>Hi, (WinXP, MinGW (gcc-4.6.2), Cairo-1.12.2, Pixman-0.25.2) My program runs successfully with Cairo-1.10.2, but getting SIGSEGV with 1.12.2. Back trace is as follows: Debugger name and version: GNU gdb (GDB) 7.4 Program received signal SIGSEGV, Segmentation fault. At .sdk\pixman\pixman\pixman-fast-path.c:619 &gt; bt #0 0x6ea7f29f in fast_composite_over_8888_8888 (imp=0x21c5308, info=0x22d608) at .sdk\pixman\pixman\pixman-fast-path.c:619 #1 0x6e9c6ded in pixman_image_composite32 (op=PIXMAN_OP_OVER, src=0x21f12b8, mask=0x0, dest=0x21f0d78, src_x=0, src_y=0, mask_x=0, mask_y=0, dest_x=0, dest_y=0, width=919, height=10) at .sdk\pixman\pixman\pixman.c:712 #2 0x6e93ff68 in composite_boxes (_dst=0x21f0e40, op=CAIRO_OPERATOR_IN, abstract_src=0x21f0f88, abstract_mask=0x0, src_x=0, src_y=0, mask_x=0, mask_y=0, dst_x=0, dst_y=0, boxes=0x22df90, extents=0x22e240) at .sdk\cairo\src\cairo-image-compositor.c:523 #3 0x6e99e608 in composite_aligned_boxes (compositor=0x6ebde060, extents=0x22e208, boxes=0x22df90</pre> Hakki Dogusan 2012-05-19T10:46:37 http://permalink.gmane.org/gmane.comp.lib.cairo/22710 <pre>Henry, I try swap buffer before draw and also after, both not work. notice:my display surface is created by cairo_image_surface_create_for_data, and the data comes from androidbitmap Thanks, Wei 2012/5/18 Henry (Yu) Song - SISA &lt;hsong&lt; at &gt;sisa.samsung.com&gt; -- cairo mailing list cairo&lt; at &gt;cairographics.org http://lists.cairographics.org/mailman/listinfo/cairo</pre> Jihe Wei 2012-05-19T01:05:26 http://permalink.gmane.org/gmane.comp.lib.cairo/22709 <pre>Hi, Jihe Since you have the gl surface as a window surface, you can swap buffer on the surface directly - cairo_gl_surface_swapbuffers (surface). Henry ________________________________________ From: cairo-bounces+henry.song=samsung.com&lt; at &gt;cairographics.org [cairo-bounces+henry.song=samsung.com&lt; at &gt;cairographics.org] on behalf of Jihe Wei [jihe.wei&lt; at &gt;gmail.com] Sent: Friday, May 18, 2012 2:54 AM To: cairo&lt; at &gt;cairographics.org Subject: [cairo] Could I use cairo with opengles in android? Hi , I wonder where can find some samples show use cairo in android device. rarely found ,so i try it myself, but seems can't render anything details as below, cairo_surface_t *surface = NULL; const EGLint attribs[] = { EGL_SURFACE_TYPE, EGL_WINDOW_BIT, EGL_BLUE_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_RED_SIZE, 8, EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT, EGL_NONE }; const EGLint ctx_attribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE }; EGLint format; EGLint numConfigs; EGLConfig config; </pre> Henry (Yu) Song - SISA 2012-05-18T15:40:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.cairo