On Mon, 18 Sep 2017 03:19:13 -0700
Yuri wrote:
> On 09/18/17 03:07, Emil Velikov wrote:
> > Yes there's libraries that do all sorts of things to help lazy
> > users... I think pixman is not one of them.
>
> pixman allocates and maintains the object, so it should ensure that it
On 09/18/17 03:07, Emil Velikov wrote:
Failure to call a destructor in C code could be interpreted as a used error,
or as a library error. I prefer to call it a library error, because it's
easier to just destroy it in the library, and not depend on users.
One can call it spaceship if they want
On 17 September 2017 at 22:25, Yuri wrote:
>> What you reported seems like an user error. Although without a proper
>> log nobody can tell you for sure.
>> The leak I've spotted is a genuine leak in pixman.
>
>
> Failure to call a destructor in C code could be interpreted as a
On 09/17/17 14:08, Emil Velikov wrote:
I don't think it's pixman's job to hold the user's hand. If the user
does not clear what it creates, then the user should be fixed. As
mentioned - pixman emits lovely BUG notations when that happens.
No, I don't see any such BUG messages in my app.
Yuri, please don't use HTML emails. It completely messes up the quotation.
On 17 September 2017 at 21:17, Yuri wrote:
> On 09/17/17 13:07, Emil Velikov wrote:
>
>> Having the opposite - a destructor [1] should provide symmetry and
>> consistency.
>> Furthermore using atexit is
On 09/17/17 13:07, Emil Velikov wrote:
Having the opposite - a destructor [1] should provide symmetry and consistency.
Furthermore using atexit is not as portable/reliable as one would think.
It should be the destructor that handles this. Either the user clears
it, or destructor clears it.
On 17 September 2017 at 17:46, Yuri wrote:
>> Maybe the right solution is to add explicit pixman_init() and
>> pixman_destroy() functions. But we need to support existing
>> applications too and we can't expect them to start using these
>> new functions without enforcing some
On 09/17/17 06:10, Siarhei Siamashka wrote:
Can Yuri tell us more about his dynamic load/reload use case? So far
I'm not aware of anyone doing this in practice.
I instantiate LV2 (audio) plugin UIs, which are mostly gtk in the
non-gtk app. I dynamically load libgtkmm/libglib libraries in
On Sun, 17 Sep 2017 13:18:01 +0100
Emil Velikov wrote:
> Hi Yuri,
>
> On 15 September 2017 at 22:41, Yuri wrote:
> > google-perftools memory profile on a gtkmm-based app shows that there is
> > 0.3MB of memory left by pixman_glyph_cache_create.
> >
> >
Hi Yuri,
On 15 September 2017 at 22:41, Yuri wrote:
> google-perftools memory profile on a gtkmm-based app shows that there is
> 0.3MB of memory left by pixman_glyph_cache_create.
>
>
> pixman should free all memory that it allocates. For example, if the app
> will load the gtkmm
10 matches
Mail list logo