marc wrote:
Hi Marc

Yes I started from V4 and then upgrade to V5.0

Eduardo

Hi Claes,

I'm anxious waiting for the responses that Marc performed

Seeking a temporary solution, I loaded an image. "png" as backgroundImage with BackgroundTiled = 0 and I found a bag in the rt_xtt_gtk.
Each time I load a graph or resize of it, the rt_xtt_gtk starts incrementing memory consumption "% MEM" and finally monopolize the whole resource of RAM, at the end the operating system collapses.

Do you know something about this failure?

Now I'm testing the patch that You sent, any inconvenience I will let you know.

Eduardo

Hi Marc,

Here is the answer to your questions.
No, I set a breakpoint in exit() in the debugger to catch the exception and looked at the backtrace and the current clip rectangle.In xtt/lib/glow/gtk/glow_draw_gtk.cpp. This is the interface to gtk where all the low level drawing of lines, arcs, polygons are performed.The redrawing mechanism is the the same for all releases since V3.9.When for example an indicator changes color and is redrawn, you don't want to redraw the whole graph, so you set a clip rectangle around it that ensures that only pixels inside the clip are modified. As you don't know the shape of the indicator you also have to redraw the background and actually every component that is visible inside the clip rectangle. The extension of a component is defined by a rectangle, and for a connection this can be very large although the real area of the connection is quite small, So even if the real area of the connection doesn't cover the clip, the extension rectangle might do so, and the connection will be redrawn. Especially long connections and value fields that are updated every scan is in a bad combination as this will lead to lots of redrawing of connections. What I did was to not only look at the extension rectangle of the whole connection, but also of the extension of the individual lines and arcs that the connection is built of to see if they cover the clip rectangle and should be redrawn or not.
Usually graphs are both backward and forward compatible, although you will get some error messages if you open a graphs created in a later versions. There where some versions when major revisions where made, 3.9 and 4.5 I think, that are not compatible.

/Claes

Hi Claes,

Thanks a lot for clearing this out and the time you used for answering my questions.

/Marc

Hi Claes,

I would like to mention that I have been testing with the patch that you sent, with two graphics (Intermedio and Liviano) with BitmapFont = 0, both with scantime at 10mS. After 19hs failed the rt_xtt giving the same message Fatal IO No. 11 .... (Xorg 19.3% CPU - 9.3% Mem and rt_xtt_gtk 35.2% CPU - 2.9% Mem).

I restarted the test under the same conditions but with BitmapFont = 1.

Did you get a failure with the test you performed in your home PC?
Do I have to modify/optimize my graph in order to solve the problems?

Eduardo

Hi Claes and Eduardo,

Tried to reproduce the IO error on a developmet station without succes.
Proview v5.0.0.1, Ubuntu 12.04 32 bit.

I used your intermedio graph, created 25 pwr_values connected to an Av, plc scantine 0.01 sec and graph update 0.01 sec. Stopped the test after 4 days.

Is there something I missed?

/Marc