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
> is also prope
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 t
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 used error,
> or as
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.
Al
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 not as portable/rel
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 changes. That's a ki
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 order
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.
> >
> >
> > pixman should free all memory that it
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 UI dynamically,
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 UI dynamically, this memory will be permanently lost
every time, resulting i
11 matches
Mail list logo