From simon at ctsn.co.uk Wed Jun 3 20:02:10 2020 From: simon at ctsn.co.uk (Simon Elliott) Date: Wed, 3 Jun 2020 21:02:10 +0100 Subject: [cairo] cairo_gl_surface_swapbuffers() Message-ID: <86dc1e0b-7ae2-7f9b-e9d5-d3e81311494d@ctsn.co.uk> Hi all We're developing an embedded system which shows graphics using cairo, opengles and wayland. Basically we have some vector graphics we've drawn into several surfaces that we blit onto a device surface and then display the device surface with cairo_gl_surface_swapbuffers(). We've run into a problem under certain circumstances. Our blit code for copying the drawn surfaces to the device surface looks like this: cairo_t* cr = cairo_create(surface_); cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE); cairo_set_source_surface(cr, source_surface_, x, y); cairo_rectangle(cr, x,y, w, h); cairo_fill(cr); cairo_destroy(cr); The device surface is created like this cairo_surface_t* surface = cairo_gl_surface_create_for_egl(cairo_device, egl_surface, width, height); We display the device surface like this: cairo_gl_surface_swapbuffers(surface); This all works flawlessly if at least one of the surfaces we've blitted onto the device surface is the same size as the device surface. If we just blit a single surface that's smaller than the device surface, then call cairo_gl_surface_swapbuffers(), we see an older image on the screen with the smaller surface on top of it. The older image is the surface that was shown via cairo_gl_surface_swapbuffers() two iterations ago. We've checked with cairo_surface_status() and there are no errors on any of the surfaces at any time. Does anyone have any suggestions for resolving this? I can't find any documentation for cairo_gl_surface_swapbuffers(). Can anyone point me at this? I'd like to look at the contents of the surfaces, but e.g. cairo-image-surface-get-width() returns zero. How can I show the width and height of the surfaces? Thanks in advance for any suggestions! From joechecht at gmail.com Mon Jun 8 06:05:04 2020 From: joechecht at gmail.com (Joe Hecht) Date: Mon, 8 Jun 2020 01:05:04 -0500 Subject: [cairo] CAIRO_HAS_FILEIO_FUNCTIONS Message-ID: Not all operating system platforms allow standard file IO functions and types. To solve: Add the following define for cairo-features.h: #define CAIRO_HAS_FILEIO_FUNCTIONS Affecting the following public interfaces: cairo_surface_write_to_png cairo_image_surface_create_from_png cairo_pdf_surface_create cairo_ps_surface_create cairo_script_create cairo_svg_surface_create cairo_xml_create It would be very nice to place the appropriate #ifdefs in the Cairo code, allowing the code to compile under these [silly] platform API's. I believe there is only one or two areas in Cairo's internal code that would require the #ifdef. No functionality would be reduced by this addition, since equivalent stream functionally exists. While the requirement disallowing standard File IO currently affects only a small number of operating system API's, it is expected to be a growing concern, so a little forethought in this area should pay off in the long run. Thanking you in advance for your consideration. Joe C. Hecht From tobias.fleischer at reduxfx.com Thu Jun 11 05:18:07 2020 From: tobias.fleischer at reduxfx.com (Tobias Fleischer (reduxFX)) Date: Thu, 11 Jun 2020 07:18:07 +0200 Subject: [cairo] Memory leak with font variations Message-ID: I think I found a bug concerning non-released memory when using font variations. I tested against cairo-1.17.2. The internal function _cairo_gstate_init_copy() is supposed to make a deep copy of the fields from one instance/state to another, used for example by cairo_save(). It does however call _cairo_font_options_init_copy(), which has this line in it: options->variations = other->variations ? strdup (other->variations) : NULL; This means that if a font variation string has been set, instead of a copy, it will always allocate and use a copy of the string (via strdup), which will then never be freed. This leads to memory leaks as for example just by calling cairo_save(), with each call an additional pointer is created that is never released. Simple sample code to reproduce: cairo_surface_t* surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1920, 1080); cairo_t* cr = cairo_create(surface); cairo_font_options_t* t = cairo_font_options_create(); cairo_get_font_options(cr, t); cairo_font_options_set_variations(t, "wght=400"); cairo_set_font_options(cr, t); cairo_font_options_destroy(t); cairo_save(cr); cairo_restore(cr); cairo_destroy(cr); cairo_surface_destroy(surface); I think what is missing is a matching free-and-null call in _cairo_gstate_fini(). If I add the following two lines at the beginning of_cairo_gstate_fini(), it seems to fix this issue, as every allocated copy gets freed again: _cairo_font_options_fini (&gstate->font_options); gstate->font_options.variations = NULL; Let me know if this makes sense. Cheers, Toby -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Thu Jun 11 05:30:15 2020 From: behdad at behdad.org (Behdad Esfahbod) Date: Wed, 10 Jun 2020 22:30:15 -0700 Subject: [cairo] Memory leak with font variations In-Reply-To: References: Message-ID: Thanks Tobias. This definitely makes sense. Thanks for debugging. I'll try to take a look on computer and fix. Unless, I hope, someone beats me to that. On Wed, Jun 10, 2020, 10:25 PM Tobias Fleischer (reduxFX) < tobias.fleischer at reduxfx.com> wrote: > I think I found a bug concerning non-released memory when using font > variations. > I tested against cairo-1.17.2. > > The internal function _cairo_gstate_init_copy() is supposed to make a deep > copy of the fields from one instance/state to another, used for example by > cairo_save(). It does however call _cairo_font_options_init_copy(), which > has this line in it: > options->variations = other->variations ? strdup (other->variations) : > NULL; > > This means that if a font variation string has been set, instead of a > copy, it will always allocate and use a copy of the string (via strdup), > which will then never be freed. > This leads to memory leaks as for example just by calling cairo_save(), > with each call an additional pointer is created that is never released. > > Simple sample code to reproduce: > cairo_surface_t* surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, > 1920, 1080); > cairo_t* cr = cairo_create(surface); > cairo_font_options_t* t = cairo_font_options_create(); > cairo_get_font_options(cr, t); > cairo_font_options_set_variations(t, "wght=400"); > cairo_set_font_options(cr, t); > cairo_font_options_destroy(t); > cairo_save(cr); > cairo_restore(cr); > cairo_destroy(cr); > cairo_surface_destroy(surface); > > I think what is missing is a matching free-and-null call in > _cairo_gstate_fini(). > If I add the following two lines at the beginning of_cairo_gstate_fini(), > it seems to fix this issue, as every allocated copy gets freed again: > _cairo_font_options_fini (&gstate->font_options); > gstate->font_options.variations = NULL; > > Let me know if this makes sense. > Cheers, > Toby > -- > cairo mailing list > cairo at cairographics.org > https://lists.cairographics.org/mailman/listinfo/cairo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.fleischer at reduxfx.com Thu Jun 11 05:38:42 2020 From: tobias.fleischer at reduxfx.com (Tobias Fleischer (reduxFX)) Date: Thu, 11 Jun 2020 07:38:42 +0200 Subject: [cairo] Memory leak with font variations In-Reply-To: References: Message-ID: Unfortunately, I just found out it is not the only location where this is happening :( For example cairo_scaled_font_create() also calls _cairo_font_options_init_copy(), which then leads to a leak. I tried to add these lines to _cairo_scaled_font_fini_internal(): _cairo_font_options_fini (&scaled_font->options); scaled_font->options.variations = NULL; But that didn't help, I still get leaks because of unmatched malloc/free blocks. Maybe it has to do with the fontmap caching/release count here? Or maybe we shouldn't try to duplicate the variation option string at all, but just copy the pointer and say it is up to the calling application to guarantee its existence? A fixed char array could also be an option but that does sound very hacky. On Thu, Jun 11, 2020 at 7:30 AM Behdad Esfahbod wrote: > Thanks Tobias. This definitely makes sense. Thanks for debugging. I'll try > to take a look on computer and fix. Unless, I hope, someone beats me to > that. > > On Wed, Jun 10, 2020, 10:25 PM Tobias Fleischer (reduxFX) < > tobias.fleischer at reduxfx.com> wrote: > >> I think I found a bug concerning non-released memory when using font >> variations. >> I tested against cairo-1.17.2. >> >> The internal function _cairo_gstate_init_copy() is supposed to make a >> deep copy of the fields from one instance/state to another, used for >> example by cairo_save(). It does however call >> _cairo_font_options_init_copy(), which has this line in it: >> options->variations = other->variations ? strdup (other->variations) : >> NULL; >> >> This means that if a font variation string has been set, instead of a >> copy, it will always allocate and use a copy of the string (via strdup), >> which will then never be freed. >> This leads to memory leaks as for example just by calling cairo_save(), >> with each call an additional pointer is created that is never released. >> >> Simple sample code to reproduce: >> cairo_surface_t* surface = >> cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1920, 1080); >> cairo_t* cr = cairo_create(surface); >> cairo_font_options_t* t = cairo_font_options_create(); >> cairo_get_font_options(cr, t); >> cairo_font_options_set_variations(t, "wght=400"); >> cairo_set_font_options(cr, t); >> cairo_font_options_destroy(t); >> cairo_save(cr); >> cairo_restore(cr); >> cairo_destroy(cr); >> cairo_surface_destroy(surface); >> >> I think what is missing is a matching free-and-null call in >> _cairo_gstate_fini(). >> If I add the following two lines at the beginning of_cairo_gstate_fini(), >> it seems to fix this issue, as every allocated copy gets freed again: >> _cairo_font_options_fini (&gstate->font_options); >> gstate->font_options.variations = NULL; >> >> Let me know if this makes sense. >> Cheers, >> Toby >> -- >> cairo mailing list >> cairo at cairographics.org >> https://lists.cairographics.org/mailman/listinfo/cairo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Sat Jun 13 20:44:15 2020 From: behdad at behdad.org (Behdad Esfahbod) Date: Sat, 13 Jun 2020 13:44:15 -0700 Subject: [cairo] Memory leak with font variations In-Reply-To: References: Message-ID: You are absolutely right. It's a mess. cairo_font_options_t used to be a plain old struct that didn't own anything. The ->get_font_options() unfortunately was designed to take a *options that it assumed didn't need cleanup and just plain wrote to it. When we added variations, all those assumptions broke. I've given it a try to clean up: https://github.com/behdad/cairo/commit/53cffff1578e4bbd1fa4d8f730c6a963617572bb I think I got it all right but am not completely sure. I think what I did is the best approach given the mess we are in. Please review and test. It compiles but I haven't tested at all. I also wrote the patch on a very old checkout of mine then rebase on master. I missed any code in between that would need the same treatment but can't do another review right now. Hope someone can take it from there. Thanks, behdad PS. I also found this mirror is stalled and confusing: https://github.com/freedesktop/cairo/commits/master On Wed, Jun 10, 2020 at 10:39 PM Tobias Fleischer (reduxFX) < tobias.fleischer at reduxfx.com> wrote: > Unfortunately, I just found out it is not the only location where this is > happening :( > For example cairo_scaled_font_create() also calls > _cairo_font_options_init_copy(), which then leads to a leak. > I tried to add these lines to _cairo_scaled_font_fini_internal(): > _cairo_font_options_fini (&scaled_font->options); > scaled_font->options.variations = NULL; > > But that didn't help, I still get leaks because of unmatched malloc/free > blocks. Maybe it has to do with the fontmap caching/release count here? > > Or maybe we shouldn't try to duplicate the variation option string at all, > but just copy the pointer and say it is up to the calling application to > guarantee its existence? > A fixed char array could also be an option but that does sound very hacky. > > On Thu, Jun 11, 2020 at 7:30 AM Behdad Esfahbod wrote: > >> Thanks Tobias. This definitely makes sense. Thanks for debugging. I'll >> try to take a look on computer and fix. Unless, I hope, someone beats me to >> that. >> >> On Wed, Jun 10, 2020, 10:25 PM Tobias Fleischer (reduxFX) < >> tobias.fleischer at reduxfx.com> wrote: >> >>> I think I found a bug concerning non-released memory when using font >>> variations. >>> I tested against cairo-1.17.2. >>> >>> The internal function _cairo_gstate_init_copy() is supposed to make a >>> deep copy of the fields from one instance/state to another, used for >>> example by cairo_save(). It does however call >>> _cairo_font_options_init_copy(), which has this line in it: >>> options->variations = other->variations ? strdup (other->variations) : >>> NULL; >>> >>> This means that if a font variation string has been set, instead of a >>> copy, it will always allocate and use a copy of the string (via strdup), >>> which will then never be freed. >>> This leads to memory leaks as for example just by calling cairo_save(), >>> with each call an additional pointer is created that is never released. >>> >>> Simple sample code to reproduce: >>> cairo_surface_t* surface = >>> cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1920, 1080); >>> cairo_t* cr = cairo_create(surface); >>> cairo_font_options_t* t = cairo_font_options_create(); >>> cairo_get_font_options(cr, t); >>> cairo_font_options_set_variations(t, "wght=400"); >>> cairo_set_font_options(cr, t); >>> cairo_font_options_destroy(t); >>> cairo_save(cr); >>> cairo_restore(cr); >>> cairo_destroy(cr); >>> cairo_surface_destroy(surface); >>> >>> I think what is missing is a matching free-and-null call in >>> _cairo_gstate_fini(). >>> If I add the following two lines at the beginning >>> of_cairo_gstate_fini(), it seems to fix this issue, as every allocated copy >>> gets freed again: >>> _cairo_font_options_fini (&gstate->font_options); >>> gstate->font_options.variations = NULL; >>> >>> Let me know if this makes sense. >>> Cheers, >>> Toby >>> -- >>> cairo mailing list >>> cairo at cairographics.org >>> https://lists.cairographics.org/mailman/listinfo/cairo >>> >> -- > cairo mailing list > cairo at cairographics.org > https://lists.cairographics.org/mailman/listinfo/cairo > -- behdad http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.fleischer at reduxfx.com Sat Jun 13 21:03:07 2020 From: tobias.fleischer at reduxfx.com (Tobias Fleischer (reduxFX)) Date: Sat, 13 Jun 2020 23:03:07 +0200 Subject: [cairo] Memory leak with font variations In-Reply-To: References: Message-ID: Thanks! I will try to test it soon. As I needed a quick and working solution for a bigger project I am working on, for now I simply replaced in my personal Cairo branch all re-assignments of the font variation string with a direct copy of the pointer variable, as the pointer to the string will always exist in my program. But I will check if your patch solves the problem also for the dynamic assignment case. Thanks again, Toby On Sat, Jun 13, 2020 at 10:44 PM Behdad Esfahbod wrote: > You are absolutely right. It's a mess. > > cairo_font_options_t used to be a plain old struct that didn't own > anything. The ->get_font_options() unfortunately was designed to take a > *options that it assumed didn't need cleanup and just plain wrote to it. > > When we added variations, all those assumptions broke. I've given it a > try to clean up: > > > https://github.com/behdad/cairo/commit/53cffff1578e4bbd1fa4d8f730c6a963617572bb > > I think I got it all right but am not completely sure. I think what I did > is the best approach given the mess we are in. > > Please review and test. It compiles but I haven't tested at all. I also > wrote the patch on a very old checkout of mine then rebase on master. I > missed any code in between that would need the same treatment but can't do > another review right now. > > Hope someone can take it from there. > > Thanks, > behdad > > PS. I also found this mirror is stalled and confusing: > > https://github.com/freedesktop/cairo/commits/master > > On Wed, Jun 10, 2020 at 10:39 PM Tobias Fleischer (reduxFX) < > tobias.fleischer at reduxfx.com> wrote: > >> Unfortunately, I just found out it is not the only location where this is >> happening :( >> For example cairo_scaled_font_create() also calls >> _cairo_font_options_init_copy(), which then leads to a leak. >> I tried to add these lines to _cairo_scaled_font_fini_internal(): >> _cairo_font_options_fini (&scaled_font->options); >> scaled_font->options.variations = NULL; >> >> But that didn't help, I still get leaks because of unmatched malloc/free >> blocks. Maybe it has to do with the fontmap caching/release count here? >> >> Or maybe we shouldn't try to duplicate the variation option string at >> all, but just copy the pointer and say it is up to the calling application >> to guarantee its existence? >> A fixed char array could also be an option but that does sound very hacky. >> >> On Thu, Jun 11, 2020 at 7:30 AM Behdad Esfahbod >> wrote: >> >>> Thanks Tobias. This definitely makes sense. Thanks for debugging. I'll >>> try to take a look on computer and fix. Unless, I hope, someone beats me to >>> that. >>> >>> On Wed, Jun 10, 2020, 10:25 PM Tobias Fleischer (reduxFX) < >>> tobias.fleischer at reduxfx.com> wrote: >>> >>>> I think I found a bug concerning non-released memory when using font >>>> variations. >>>> I tested against cairo-1.17.2. >>>> >>>> The internal function _cairo_gstate_init_copy() is supposed to make a >>>> deep copy of the fields from one instance/state to another, used for >>>> example by cairo_save(). It does however call >>>> _cairo_font_options_init_copy(), which has this line in it: >>>> options->variations = other->variations ? strdup (other->variations) : >>>> NULL; >>>> >>>> This means that if a font variation string has been set, instead of a >>>> copy, it will always allocate and use a copy of the string (via strdup), >>>> which will then never be freed. >>>> This leads to memory leaks as for example just by calling cairo_save(), >>>> with each call an additional pointer is created that is never released. >>>> >>>> Simple sample code to reproduce: >>>> cairo_surface_t* surface = >>>> cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1920, 1080); >>>> cairo_t* cr = cairo_create(surface); >>>> cairo_font_options_t* t = cairo_font_options_create(); >>>> cairo_get_font_options(cr, t); >>>> cairo_font_options_set_variations(t, "wght=400"); >>>> cairo_set_font_options(cr, t); >>>> cairo_font_options_destroy(t); >>>> cairo_save(cr); >>>> cairo_restore(cr); >>>> cairo_destroy(cr); >>>> cairo_surface_destroy(surface); >>>> >>>> I think what is missing is a matching free-and-null call in >>>> _cairo_gstate_fini(). >>>> If I add the following two lines at the beginning >>>> of_cairo_gstate_fini(), it seems to fix this issue, as every allocated copy >>>> gets freed again: >>>> _cairo_font_options_fini (&gstate->font_options); >>>> gstate->font_options.variations = NULL; >>>> >>>> Let me know if this makes sense. >>>> Cheers, >>>> Toby >>>> -- >>>> cairo mailing list >>>> cairo at cairographics.org >>>> https://lists.cairographics.org/mailman/listinfo/cairo >>>> >>> -- >> cairo mailing list >> cairo at cairographics.org >> https://lists.cairographics.org/mailman/listinfo/cairo >> > > > -- > behdad > http://behdad.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.fleischer at reduxfx.com Sun Jun 14 20:34:05 2020 From: tobias.fleischer at reduxfx.com (Tobias Fleischer (reduxFX)) Date: Sun, 14 Jun 2020 22:34:05 +0200 Subject: [cairo] Memory leak with font variations In-Reply-To: References: Message-ID: If the new smoothing parameter is set to "Color", it should apply roughly the same anti-aliasing technique as AE itself, at least it looked really similar when putting a text layer next to the plugins rendered output. On Sat, Jun 13, 2020 at 11:03 PM Tobias Fleischer (reduxFX) < tobias.fleischer at reduxfx.com> wrote: > Thanks! > I will try to test it soon. > As I needed a quick and working solution for a bigger project I am working > on, for now I simply replaced in my personal Cairo branch all > re-assignments of the font variation string with a direct copy of the > pointer variable, as the pointer to the string will always exist in my > program. But I will check if your patch solves the problem also for the > dynamic assignment case. > Thanks again, > Toby > > > On Sat, Jun 13, 2020 at 10:44 PM Behdad Esfahbod > wrote: > >> You are absolutely right. It's a mess. >> >> cairo_font_options_t used to be a plain old struct that didn't own >> anything. The ->get_font_options() unfortunately was designed to take a >> *options that it assumed didn't need cleanup and just plain wrote to it. >> >> When we added variations, all those assumptions broke. I've given it a >> try to clean up: >> >> >> https://github.com/behdad/cairo/commit/53cffff1578e4bbd1fa4d8f730c6a963617572bb >> >> I think I got it all right but am not completely sure. I think what I >> did is the best approach given the mess we are in. >> >> Please review and test. It compiles but I haven't tested at all. I also >> wrote the patch on a very old checkout of mine then rebase on master. I >> missed any code in between that would need the same treatment but can't do >> another review right now. >> >> Hope someone can take it from there. >> >> Thanks, >> behdad >> >> PS. I also found this mirror is stalled and confusing: >> >> https://github.com/freedesktop/cairo/commits/master >> >> On Wed, Jun 10, 2020 at 10:39 PM Tobias Fleischer (reduxFX) < >> tobias.fleischer at reduxfx.com> wrote: >> >>> Unfortunately, I just found out it is not the only location where this >>> is happening :( >>> For example cairo_scaled_font_create() also calls >>> _cairo_font_options_init_copy(), which then leads to a leak. >>> I tried to add these lines to _cairo_scaled_font_fini_internal(): >>> _cairo_font_options_fini (&scaled_font->options); >>> scaled_font->options.variations = NULL; >>> >>> But that didn't help, I still get leaks because of unmatched malloc/free >>> blocks. Maybe it has to do with the fontmap caching/release count here? >>> >>> Or maybe we shouldn't try to duplicate the variation option string at >>> all, but just copy the pointer and say it is up to the calling application >>> to guarantee its existence? >>> A fixed char array could also be an option but that does sound very >>> hacky. >>> >>> On Thu, Jun 11, 2020 at 7:30 AM Behdad Esfahbod >>> wrote: >>> >>>> Thanks Tobias. This definitely makes sense. Thanks for debugging. I'll >>>> try to take a look on computer and fix. Unless, I hope, someone beats me to >>>> that. >>>> >>>> On Wed, Jun 10, 2020, 10:25 PM Tobias Fleischer (reduxFX) < >>>> tobias.fleischer at reduxfx.com> wrote: >>>> >>>>> I think I found a bug concerning non-released memory when using font >>>>> variations. >>>>> I tested against cairo-1.17.2. >>>>> >>>>> The internal function _cairo_gstate_init_copy() is supposed to make a >>>>> deep copy of the fields from one instance/state to another, used for >>>>> example by cairo_save(). It does however call >>>>> _cairo_font_options_init_copy(), which has this line in it: >>>>> options->variations = other->variations ? strdup (other->variations) : >>>>> NULL; >>>>> >>>>> This means that if a font variation string has been set, instead of a >>>>> copy, it will always allocate and use a copy of the string (via strdup), >>>>> which will then never be freed. >>>>> This leads to memory leaks as for example just by calling >>>>> cairo_save(), with each call an additional pointer is created that is never >>>>> released. >>>>> >>>>> Simple sample code to reproduce: >>>>> cairo_surface_t* surface = >>>>> cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1920, 1080); >>>>> cairo_t* cr = cairo_create(surface); >>>>> cairo_font_options_t* t = cairo_font_options_create(); >>>>> cairo_get_font_options(cr, t); >>>>> cairo_font_options_set_variations(t, "wght=400"); >>>>> cairo_set_font_options(cr, t); >>>>> cairo_font_options_destroy(t); >>>>> cairo_save(cr); >>>>> cairo_restore(cr); >>>>> cairo_destroy(cr); >>>>> cairo_surface_destroy(surface); >>>>> >>>>> I think what is missing is a matching free-and-null call in >>>>> _cairo_gstate_fini(). >>>>> If I add the following two lines at the beginning >>>>> of_cairo_gstate_fini(), it seems to fix this issue, as every allocated copy >>>>> gets freed again: >>>>> _cairo_font_options_fini (&gstate->font_options); >>>>> gstate->font_options.variations = NULL; >>>>> >>>>> Let me know if this makes sense. >>>>> Cheers, >>>>> Toby >>>>> -- >>>>> cairo mailing list >>>>> cairo at cairographics.org >>>>> https://lists.cairographics.org/mailman/listinfo/cairo >>>>> >>>> -- >>> cairo mailing list >>> cairo at cairographics.org >>> https://lists.cairographics.org/mailman/listinfo/cairo >>> >> >> >> -- >> behdad >> http://behdad.org/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.fleischer at reduxfx.com Sun Jun 14 20:34:39 2020 From: tobias.fleischer at reduxfx.com (Tobias Fleischer (reduxFX)) Date: Sun, 14 Jun 2020 22:34:39 +0200 Subject: [cairo] Memory leak with font variations In-Reply-To: References: Message-ID: Oops, sorry, wrong thread. :) On Sun, Jun 14, 2020 at 10:34 PM Tobias Fleischer (reduxFX) < tobias.fleischer at reduxfx.com> wrote: > If the new smoothing parameter is set to "Color", it should apply roughly > the same anti-aliasing technique as AE itself, at least it looked really > similar when putting a text layer next to the plugins rendered output. > > On Sat, Jun 13, 2020 at 11:03 PM Tobias Fleischer (reduxFX) < > tobias.fleischer at reduxfx.com> wrote: > >> Thanks! >> I will try to test it soon. >> As I needed a quick and working solution for a bigger project I am >> working on, for now I simply replaced in my personal Cairo branch all >> re-assignments of the font variation string with a direct copy of the >> pointer variable, as the pointer to the string will always exist in my >> program. But I will check if your patch solves the problem also for the >> dynamic assignment case. >> Thanks again, >> Toby >> >> >> On Sat, Jun 13, 2020 at 10:44 PM Behdad Esfahbod >> wrote: >> >>> You are absolutely right. It's a mess. >>> >>> cairo_font_options_t used to be a plain old struct that didn't own >>> anything. The ->get_font_options() unfortunately was designed to take a >>> *options that it assumed didn't need cleanup and just plain wrote to it. >>> >>> When we added variations, all those assumptions broke. I've given it a >>> try to clean up: >>> >>> >>> https://github.com/behdad/cairo/commit/53cffff1578e4bbd1fa4d8f730c6a963617572bb >>> >>> I think I got it all right but am not completely sure. I think what I >>> did is the best approach given the mess we are in. >>> >>> Please review and test. It compiles but I haven't tested at all. I >>> also wrote the patch on a very old checkout of mine then rebase on master. >>> I missed any code in between that would need the same treatment but can't >>> do another review right now. >>> >>> Hope someone can take it from there. >>> >>> Thanks, >>> behdad >>> >>> PS. I also found this mirror is stalled and confusing: >>> >>> https://github.com/freedesktop/cairo/commits/master >>> >>> On Wed, Jun 10, 2020 at 10:39 PM Tobias Fleischer (reduxFX) < >>> tobias.fleischer at reduxfx.com> wrote: >>> >>>> Unfortunately, I just found out it is not the only location where this >>>> is happening :( >>>> For example cairo_scaled_font_create() also calls >>>> _cairo_font_options_init_copy(), which then leads to a leak. >>>> I tried to add these lines to _cairo_scaled_font_fini_internal(): >>>> _cairo_font_options_fini (&scaled_font->options); >>>> scaled_font->options.variations = NULL; >>>> >>>> But that didn't help, I still get leaks because of unmatched >>>> malloc/free blocks. Maybe it has to do with the fontmap caching/release >>>> count here? >>>> >>>> Or maybe we shouldn't try to duplicate the variation option string at >>>> all, but just copy the pointer and say it is up to the calling application >>>> to guarantee its existence? >>>> A fixed char array could also be an option but that does sound very >>>> hacky. >>>> >>>> On Thu, Jun 11, 2020 at 7:30 AM Behdad Esfahbod >>>> wrote: >>>> >>>>> Thanks Tobias. This definitely makes sense. Thanks for debugging. I'll >>>>> try to take a look on computer and fix. Unless, I hope, someone beats me to >>>>> that. >>>>> >>>>> On Wed, Jun 10, 2020, 10:25 PM Tobias Fleischer (reduxFX) < >>>>> tobias.fleischer at reduxfx.com> wrote: >>>>> >>>>>> I think I found a bug concerning non-released memory when using font >>>>>> variations. >>>>>> I tested against cairo-1.17.2. >>>>>> >>>>>> The internal function _cairo_gstate_init_copy() is supposed to make a >>>>>> deep copy of the fields from one instance/state to another, used for >>>>>> example by cairo_save(). It does however call >>>>>> _cairo_font_options_init_copy(), which has this line in it: >>>>>> options->variations = other->variations ? strdup (other->variations) >>>>>> : NULL; >>>>>> >>>>>> This means that if a font variation string has been set, instead of a >>>>>> copy, it will always allocate and use a copy of the string (via strdup), >>>>>> which will then never be freed. >>>>>> This leads to memory leaks as for example just by calling >>>>>> cairo_save(), with each call an additional pointer is created that is never >>>>>> released. >>>>>> >>>>>> Simple sample code to reproduce: >>>>>> cairo_surface_t* surface = >>>>>> cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1920, 1080); >>>>>> cairo_t* cr = cairo_create(surface); >>>>>> cairo_font_options_t* t = cairo_font_options_create(); >>>>>> cairo_get_font_options(cr, t); >>>>>> cairo_font_options_set_variations(t, "wght=400"); >>>>>> cairo_set_font_options(cr, t); >>>>>> cairo_font_options_destroy(t); >>>>>> cairo_save(cr); >>>>>> cairo_restore(cr); >>>>>> cairo_destroy(cr); >>>>>> cairo_surface_destroy(surface); >>>>>> >>>>>> I think what is missing is a matching free-and-null call in >>>>>> _cairo_gstate_fini(). >>>>>> If I add the following two lines at the beginning >>>>>> of_cairo_gstate_fini(), it seems to fix this issue, as every allocated copy >>>>>> gets freed again: >>>>>> _cairo_font_options_fini (&gstate->font_options); >>>>>> gstate->font_options.variations = NULL; >>>>>> >>>>>> Let me know if this makes sense. >>>>>> Cheers, >>>>>> Toby >>>>>> -- >>>>>> cairo mailing list >>>>>> cairo at cairographics.org >>>>>> https://lists.cairographics.org/mailman/listinfo/cairo >>>>>> >>>>> -- >>>> cairo mailing list >>>> cairo at cairographics.org >>>> https://lists.cairographics.org/mailman/listinfo/cairo >>>> >>> >>> >>> -- >>> behdad >>> http://behdad.org/ >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernst at pleiszenburg.de Mon Jun 15 06:44:36 2020 From: ernst at pleiszenburg.de (Sebastian M. Ernst) Date: Mon, 15 Jun 2020 08:44:36 +0200 Subject: [cairo] =?utf-8?b?4oCcc3Ryb2tl4oCdIHJlcXVpcmVkIGFmdGVyIOKAnHNo?= =?utf-8?q?owing=E2=80=9D_Pango_layout=3F?= Message-ID: <62d50cd6-1738-9245-f2d5-ac7486b7da61@pleiszenburg.de> Hi all, I have been chasing a problem between PyCairo and PangoCairo. The following code illustrates it: ```python import math import cairo import gi gi.require_version('Pango', '1.0') gi.require_version('PangoCairo', '1.0') from gi.repository import Pango, PangoCairo surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 400, 400) ctx = cairo.Context(surface) # TOP LEFT CIRCLE ctx.save() ctx.arc(100.0, 100.0, 50, 0, 2 * math.pi) ctx.set_source_rgba(0.0, 0.0, 1.0, 1.0) ctx.set_line_width(2.0) ctx.stroke() ctx.restore() # CENTER TEXT ctx.save() layout = PangoCairo.create_layout(ctx) layout.set_font_description(Pango.font_description_from_string('Arial 10.0')) layout.set_markup('Foo Bar', -1) ctx.set_source_rgba(0.0, 1.0, 0.0, 1.0) _, text_extents = layout.get_pixel_extents() text_width, text_height = text_extents.width, text_extents.height ctx.translate(200.0, 200.0) ctx.translate(-text_width / 2, -text_height / 2) ctx.move_to(0.0, 0.0) PangoCairo.show_layout(ctx, layout) # ctx.stroke() # WHY? ctx.restore() # BOTTOM RIGHT CIRCLE ctx.save() ctx.arc(300.0, 300.0, 50, 0, 2 * math.pi) ctx.set_source_rgba(1.0, 0.0, 0.0, 1.0) ctx.set_line_width(2.0) ctx.stroke() ctx.restore() surface.write_to_png('test.png') ``` It results in the attached picture, also see here: https://i.stack.imgur.com/damCs.png My intention is to draw two circles and text. The line between the text and the bottom right circle is not intended to exist. I can make the line disappear by adding / uncommenting the ctx.stroke() call directly underneath PangoCairo.show_layout in the center text code block. It works, but it does not feel right. The text does not require a line stroke. What is going wrong? Is the stroke actually required or have I made another mistake? Full disclosure: I have also posted this question on SO [1]. Best regards, Sebastian 1: https://stackoverflow.com/q/62376532/1672565 -------------- next part -------------- A non-text attachment was scrubbed... Name: test.png Type: image/png Size: 7138 bytes Desc: not available URL: From nick87720z at gmail.com Mon Jun 15 06:56:13 2020 From: nick87720z at gmail.com (Nikita Zlobin) Date: Mon, 15 Jun 2020 11:56:13 +0500 Subject: [cairo] =?utf-8?b?4oCcc3Ryb2tl4oCdIHJlcXVpcmVkIGFmdGVyIOKAnHNo?= =?utf-8?q?owing=E2=80=9D_Pango_layout=3F?= In-Reply-To: <62d50cd6-1738-9245-f2d5-ac7486b7da61@pleiszenburg.de> References: <62d50cd6-1738-9245-f2d5-ac7486b7da61@pleiszenburg.de> Message-ID: <20200615115613.736cd0aa@calculate.local> In Mon, 15 Jun 2020 08:44:36 +0200 "Sebastian M. Ernst" wrote: > Hi all, > > I have been chasing a problem between PyCairo and PangoCairo. The > following code illustrates it: > > ```python > import math > import cairo > import gi > gi.require_version('Pango', '1.0') > gi.require_version('PangoCairo', '1.0') > from gi.repository import Pango, PangoCairo > > surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 400, 400) > ctx = cairo.Context(surface) > > # TOP LEFT CIRCLE > ctx.save() > ctx.arc(100.0, 100.0, 50, 0, 2 * math.pi) > ctx.set_source_rgba(0.0, 0.0, 1.0, 1.0) > ctx.set_line_width(2.0) > ctx.stroke() > ctx.restore() > > # CENTER TEXT > ctx.save() > layout = PangoCairo.create_layout(ctx) > layout.set_font_description(Pango.font_description_from_string('Arial > 10.0')) > layout.set_markup('Foo Bar', -1) > ctx.set_source_rgba(0.0, 1.0, 0.0, 1.0) > _, text_extents = layout.get_pixel_extents() > text_width, text_height = text_extents.width, text_extents.height > ctx.translate(200.0, 200.0) > ctx.translate(-text_width / 2, -text_height / 2) > ctx.move_to(0.0, 0.0) > PangoCairo.show_layout(ctx, layout) > # ctx.stroke() # WHY? > ctx.restore() > > # BOTTOM RIGHT CIRCLE > ctx.save() > ctx.arc(300.0, 300.0, 50, 0, 2 * math.pi) > ctx.set_source_rgba(1.0, 0.0, 0.0, 1.0) > ctx.set_line_width(2.0) > ctx.stroke() > ctx.restore() > > surface.write_to_png('test.png') > ``` > > It results in the attached picture, also see here: > https://i.stack.imgur.com/damCs.png > > My intention is to draw two circles and text. The line between the > text and the bottom right circle is not intended to exist. I can make > the line disappear by adding / uncommenting the ctx.stroke() call > directly underneath PangoCairo.show_layout in the center text code > block. > > It works, but it does not feel right. The text does not require a line > stroke. What is going wrong? Is the stroke actually required or have I > made another mistake? > > Full disclosure: I have also posted this question on SO [1]. > > Best regards, > Sebastian > > > 1: https://stackoverflow.com/q/62376532/1672565 There is already current point set after pango layout draw, so you have to move to new shape. Or you could try new path or sub_path. From lobingera at gmail.com Mon Jun 15 17:04:57 2020 From: lobingera at gmail.com (Andreas Lobinger) Date: Mon, 15 Jun 2020 19:04:57 +0200 Subject: [cairo] multicolor Emoji example? Message-ID: Hello, i'm looking for a working multicolor Emoji example and i ran the https://gitlab.freedesktop.org/cairo/cairo/-/issues/404 code, downloaded the font and get only single color smile emoji in the result png. From hlewin at gmx.de Mon Jun 15 23:35:28 2020 From: hlewin at gmx.de (Heiko Lewin) Date: Tue, 16 Jun 2020 01:35:28 +0200 Subject: [cairo] multicolor Emoji example? In-Reply-To: References: Message-ID: <5df678d8-122c-3149-ca24-433e65a7f6cc@gmx.de> This post on stackoverflow has a good link: https://stackoverflow.com/questions/50720755/emoji-modifiers-zwj-sequences-using-harfbuzz-freetype-in-apple-color-emoji https://github.com/rozaxe/ex-harfbuzz-sdl2-cairo-freetype-emoji On 6/15/20 7:04 PM, Andreas Lobinger wrote: > Hello, > > i'm looking for a working multicolor Emoji example and i ran the > https://gitlab.freedesktop.org/cairo/cairo/-/issues/404 code, > downloaded the font and get only single color smile emoji in the > result png. From behdad at behdad.org Tue Jun 16 02:53:55 2020 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 15 Jun 2020 19:53:55 -0700 Subject: [cairo] multicolor Emoji example? In-Reply-To: References: Message-ID: Hi Andreas, That does seem like a bug in cairo-ft-font.c. Unfortunately I won't be able to debug it. behdad On Mon, Jun 15, 2020 at 10:05 AM Andreas Lobinger wrote: > Hello, > > i'm looking for a working multicolor Emoji example and i ran the > https://gitlab.freedesktop.org/cairo/cairo/-/issues/404 code, > downloaded the font and get only single color smile emoji in the > result png. > -- > cairo mailing list > cairo at cairographics.org > https://lists.cairographics.org/mailman/listinfo/cairo > -- behdad http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From czh_0611 at 163.com Sat Jun 20 03:43:58 2020 From: czh_0611 at 163.com (czh_0611 at 163.com) Date: Sat, 20 Jun 2020 11:43:58 +0800 Subject: [cairo] pdf question Message-ID: <202006201143582159193@163.com> Hello : Please ask us, we need to write vector PDF, one page contains more than 100000 points. At present, we draw rectangle filling, but the file is too large. It's not convenient to print. Do you have a good way to set the file size. Thanks? czh_0611 at 163.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From czh_0611 at 163.com Mon Jun 22 02:44:18 2020 From: czh_0611 at 163.com (czh_0611 at 163.com) Date: Mon, 22 Jun 2020 10:44:18 +0800 Subject: [cairo] vector pdf write Message-ID: <202006221044180214354@163.com> Hello: we use Cairo to generate vector PDF files. We write a lot of content and can't print it. The attached PDF file is generated by us, please help to see what problem? Please , we need to write vector PDF, one page contains more than 100000 points. At present, we draw rectangle filling, but the file is too large. It's not convenient to print. Do you have a good way to set the file size. Thanks? czh_0611 at 163.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From czh_0611 at 163.com Sat Jun 20 03:42:59 2020 From: czh_0611 at 163.com (czh_0611 at 163.com) Date: Sat, 20 Jun 2020 03:42:59 -0000 Subject: Cairo Vector PDF Message-ID: <202006201142473093202@163.com> Hello: we use Cairo to generate vector PDF files. We write a lot of content and can't print it. The attached PDF file is generated by us, please help to see what problem, thank you! czh_0611 at 163.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test42.pdf Type: application/octet-stream Size: 236472 bytes Desc: not available URL: From czh_0611 at 163.com Mon Jun 22 01:53:47 2020 From: czh_0611 at 163.com (czh_0611 at 163.com) Date: Mon, 22 Jun 2020 01:53:47 -0000 Subject: vector pdf write Message-ID: <202006220953404238443@163.com> Hello: we use Cairo to generate vector PDF files. We write a lot of content and can't print it. The attached PDF file is generated by us, please help to see what problem? Please , we need to write vector PDF, one page contains more than 100000 points. At present, we draw rectangle filling, but the file is too large. It's not convenient to print. Do you have a good way to set the file size. Thanks? czh_0611 at 163.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test42.zip Type: application/octet-stream Size: 179745 bytes Desc: not available URL: