Thread shift - SVG memory consumption under Win7 - was RE: [fltk.general] "Pretty" FLTK apps [General Use]

[MacArthur, Ian (Leonardo, UK)]

> On 12/11/17 11:49, Ian MacArthur wrote:
> > svg-rotate.cxx:58:5: warning: 'delete' applied to a pointer that was
> allocated with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-
> delete]
> > delete svg_logo;
> > ^
> > svg-rotate.cxx:51:22: note: allocated with 'new[]' here
> > char *svg_logo = new char [strlen(G_svg_logo_fmt)+10];
> > ^
>
> Yuck, that's such an easy mistake to make.
> I noticed the newer clang compilers are catching these now.
>
> Could easily be the problem; I'm not sure what the C++ spec says
> the behavior is if you 'delete' instead of 'delete []'. >:^/

I applied the fix to my Win7 build, but the aberrant behaviour remains, FWIW.

I've attached a screenshot of Task Manager showing the memory use during the run - I ran the test twice; can you spot where they are in the trace! ;-)

It seems odd, though.
In my testing now, it seems like OSX and Linux show fairly high CPU load with this (might even be pinning a core) but the memory use is OK. On Win7, the CPU load is minimal, but we seem to be consuming RAM... Odd.


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Stephan Effelsberg]

I'm on Win7 and observe the memory consumption as well (about 50 MB per second). So far, I rooted it down to Fl_GDI_Graphics_Driver::draw_unscaled and within there the call to build_id. If I remove this call there is no extra memory consumption (and of course no image). The demo creates a new image 60 times per second, so build_id is called 60 times per second as well and it seems that it doesn't forget deleted images. The image destructors are called properly, I don't know how this is communicated to any kind of cache if it needs to be.

Fun fact (if this affects some caching strategy): if the image is destroyed and created again in the next line, then the object is placed at the very same address. I also added a method to Fl_SVG_Image that parses data without creating a new image but some essential data (especially the image's id) is reset.

The only way to have no rise in memory consumption is to not update the image. If the image is not updated, its id will be the id that what assigned during the build_id process and everything's fine.

That's it so far,

    Stephan

[Ian MacArthur]

> On 18 Dec 2017, at 19:01, 'Stephan Effelsberg' wrote:
>
> I'm on Win7 and observe the memory consumption as well (about 50 MB per second). So far, I rooted it down to Fl_GDI_Graphics_Driver::draw_unscaled and within there the call to build_id. If I remove this call there is no extra memory consumption (and of course no image). The demo creates a new image 60 times per second, so build_id is called 60 times per second as well and it seems that it doesn't forget deleted images. The image destructors are called properly, I don't know how this is communicated to any kind of cache if it needs to be.

OK, interesting observations... Though I do not know what is going.

I wonder if the use of:

Fl_Offscreen offs = surface->get_offscreen_before_delete();

is causing us to leak offscreen buffers here? We delete the “surface” after this, but I don’t see where we delete the offscreen “offs” that we keep...

Or (more likely) I’m missing the point!

[Manolo]

Great! Yes, that's  the error: the cached offscreen of the RGB image is not deleted properly by

Fl_GDI_Graphics_Driver::uncache(Fl_RGB_Image*,...) which is in charge of deleting it.

I will try to fix that.

[Manolo]

The bug should be repaired with r.12600 of the svn repository.

[imm]

FWIW, I tested this and it seems to be much better now!

Thanks Manolo.

--
Ian
From my Fairphone FP2