Opened 5 months ago

Closed 6 weeks ago

Last modified 6 weeks ago

#387 closed bug (fixed)

Video memory trouble with R2

Reported by: K-L Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2018R4
Component: Imagespace.mui Version: 5.0-2018R2
Severity: minor Keywords:
Cc: Hubert Maier, Samir Hawamdeh OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

MUI 5-2018-R2 seems to eat a lot of video memory without freeing it.

Steps to reproduce

  1. Launch a monitor to check video memory consumption (to be done with R1 and then R2 to see differences)
  1. Launch any MUI application and check video memory consumption

Expected results

A huge amount of video memory will be used while using an MUI Application (Odyssey for example).

Actual results

More than 50% of video memory (I have 256MB here) will be used and not be freed when quitting all MUI applications.

Regression

It is a regression from R1.

Notes

Attachments (3)

putty.lha (375.5 KB) - added by Hubert Maier 5 months ago.
Crashlog_Odyssey_2018-08-04_17-17-20.txt (37.9 KB) - added by Hubert Maier 4 months ago.
Crashlog_Odyssey_2018-08-04_17-22-09.txt (37.6 KB) - added by Hubert Maier 4 months ago.

Download all attachments as: .zip

Change History (79)

comment:1 Changed 5 months ago by jPV

This sounds very similar to what my friend (who makes betatest for my OS4 programs) reported, but he told that MUI programs consume system memory (RAM) too, not just video memory. The memory isn't freed when quitting the applications.

If he boots the machine without MUI applications running, memory isn't consumed. But if he launches MUI program(s), memory is being consumed continuously until it's all gone. For example, while just using AmIRC, all memory (512MB) was gone after 11 hours. Just running the MUI settings program alone will also consume memory in the similar way.

This kind of behaviour was already seen with 5.0-2017R4, but it's worse with 5.0-2018R2 now.

Last edited 5 months ago by jPV (previous) (diff)

comment:2 Changed 5 months ago by Thore Böckelmann

Keep in mind that MUI does cache images. That means that images are loaded once only and will be reused when restarting the program or even when other programs use the same image. When the program that caused the loading of an image is terminated the images will stay in memory and of course will consume memory until they are flushed.

Flushing the image cache will happen when system memory is low and Exec invokes the usual low memory handlers. This can also be enforced by running the supplied FlushImagespace program.

@K-L
What kind of video memory monitor are you referring to?

@jPV
If free video memory is constantly decreasing there must be something that MUI's debugging framework is able to expose by doing excessive output.

comment:3 Changed 5 months ago by Thore Böckelmann

I have had MUI prefs of 2018R2 running for almost 8 hours now on my WinUAE/AmigaOS4 setup and have absolutely no problems. According to the Workbench title bar free video memory has decreased from 1K (yes, 1024 bytes) down to 0K as soon as MUI prefs has started. But that's it. Normal memory figures have not changed at all.

comment:4 Changed 5 months ago by K-L

Well, I'll make some new tests with screen grabs. Thanks for having tested.

comment:5 Changed 5 months ago by Hubert Maier

I can confirm this behaviour.

Especially Odyssey is eating away video ram very fast (Workbench title bar is showing envvar %mgum - Memory Graphics Used Megabytes) and is neither freeing it after the program's quit nor while Odyssey is running.

Can easily be reproduced on sites which features lots of pictures, e.g. http://uberhumor.com/
…you can actually see the video memory getting filled up.

Just scroll down the site, let the pictures load and move on to the next page and so on.

I'm filling up at leat 1 to 2 Megabytes per new site.

comment:6 Changed 5 months ago by Hubert Maier

More tests needed, but it seems as if the nightly build
https://muidev.de/download/MUI%205.0%20-%20Nightly%20Builds/MUI-5.0-20180724r6309-os4.lha
fixed the behaviour for me.

Changed 5 months ago by Hubert Maier

Attachment: putty.lha added

comment:7 Changed 5 months ago by Hubert Maier

Nope, behaviour still there

comment:8 in reply to:  5 Changed 5 months ago by Thore Böckelmann

Replying to Hubert Maier:

Can easily be reproduced on sites which features lots of pictures, e.g. http://uberhumor.com/
…you can actually see the video memory getting filled up.

Wait! This is beyond MUI's control. If Odyssey eats up tons of memory when loading web pages then MUI cannot do anything against this. These images are under control of Odyssey only and MUI does not know about them.

comment:9 Changed 5 months ago by K-L

But, how can you explain that there was not this behaviour with 2018R1 and it now happens with 2018R2 with the exact same version of Odyssey ?

comment:10 Changed 5 months ago by Thore Böckelmann

I have created some nightly build versions of previous commits dated around the release of 2018R1. Please check these as well:
commit 6244
commit 6244 debug version
commit 6248
commit 6248 debug version
commit 6251
commit 6251 debug version

Changed 4 months ago by Hubert Maier

Changed 4 months ago by Hubert Maier

comment:11 Changed 4 months ago by Hubert Maier

All three of the provided debug versions produce a reproducable crash on start

comment:12 in reply to:  11 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

All three of the provided debug versions produce a reproducable crash on start

Did you install the debug version of muimaster.library on top of the corresponding "normal" archive contents? As usual you should not mix files of different releases, unless told explicitly.

comment:13 Changed 4 months ago by Hubert Maier

It seems i'm not getting alterted when there is a new comment :-(

…and, yes, i did, as i don't have a debug release installed, it's the latest release from the download page.

And it worked with the very first debug muimaster.library you sent out, so i thought it will do now too

comment:14 Changed 4 months ago by Thore Böckelmann

Cc: Hubert Maier added

comment:15 in reply to:  13 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

It seems i'm not getting alterted when there is a new comment :-(

I added you as CC, so you should get notified now.

…and, yes, i did, as i don't have a debug release installed, it's the latest release from the download page.

And it worked with the very first debug muimaster.library you sent out, so i thought it will do now too

I just tried all 3 archives on my virtual AmigaOS4 setup and none of them causes a crash.

Let me repeat again: do not mix files from different releases. If you want to test the debug version of the r6244 release from the download page, then first install all files from the "normal" r6244 archive and then copy the debug version of muimaster.library from the debug r6244 archive on top. After that you can either call MUI:FlushMUI to remove all possibly remaining stuff from a previous release from memory or just reboot the system to be absolutely sure that no previous stuff is used. Then start your debugging session.

If the special builds should be broken in any way this would mean that all the nightly builds would be broken as well, as these archives have been built from scratch in exactly the same way as the normal nightly builds and release builds.

comment:16 Changed 4 months ago by Hubert Maier

I added you as CC, so you should get notified now.

Yes, thank you

I didn't know that, sorry.
The files you linked to only hold the muimaster.library, so i thought it would be sufficient to copy that to my installed MUI temporarily.

I have to ask how i'm supposed to get that special build/files?
There is nothing on the downloads page and following your r6244 link takes me to the release info only.

comment:17 in reply to:  16 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

The files you linked to only hold the muimaster.library, so i thought it would be sufficient to copy that to my installed MUI temporarily.

I have to ask how i'm supposed to get that special build/files?
There is nothing on the downloads page and following your r6244 link takes me to the release info only.

??? I downloaded the archives from the given links myself using Odyssey. But it should not matter which link you are using. The 6 archives can be found on the download page between the 2018R1 and 2017R4 archives as well.

comment:18 Changed 4 months ago by Hubert Maier

Yep, my bad, i never checked the "normal" links, sorry about that.

After testing build r6244 for a pretty long time and stressing it, i can savely say that this revision doesn't suffer from the OP problems.

I'll move on to the next revision shortly

comment:19 Changed 4 months ago by Hubert Maier

r6248 doesn't show the behaviour aswell

comment:20 Changed 4 months ago by Hubert Maier

…and r6251 neither have that problem too

comment:21 in reply to:  20 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

…and r6251 neither have that problem too

Hm, that is interesting. According to #379 r6251 is exactly the first revision which causes issues. And now you tell me that there are no issues with that revision.

Either #379 and this ticket are about different faults or we are turning in circles here.

I will provide more interim builds until we find the guilty revision. Please test each build exactly like you tested the other three build.

comment:23 Changed 4 months ago by Thore Böckelmann

r6306 exactly matches 2018R2. Hence the issue must have crept in somewhere between r6251 and r6306.

comment:24 Changed 4 months ago by Hubert Maier

Progress :-)

r6261 is fine

r6278 is the first version displaying the behaviour

btw, i found another way to easily test and fill up my gfx ram (slowly)
Just load in new sites one after the other, i.e. i'm going through my bookmarks from top to bottom and all five or so sites my gfx ram gets filled by another % and exactly these filled up % never get freed on quit.

Looking at the additions inbetween those revisions it now can only be r6262, r6264 or r6265, right?
All the others are either translation updates, one utf-8 fix that only affects greek (r6270?) or a package merge (r6263) for the release build?

Last edited 4 months ago by Hubert Maier (previous) (diff)

comment:25 Changed 4 months ago by Thore Böckelmann

Some more archives to test:
commit 6262
commit 6262 debug version
commit 6264
commit 6264 debug version
commit 6265
commit 6265 debug version
commit 6272
commit 6272 debug version

All the other commits between 6261 and 6278 are irrelevant as they cover changes to the catalog translations only. And from my point of view the only possibly guilty commit is r6272, because this one covers the highlighting of the selected list columns. However, I still fail to see why that change should cause any harm. But if that revision turns out to cause the memory eating effect then please try to set the list highlighting effect to "off" (MUI prefs → Lists → Brightening).

comment:26 Changed 4 months ago by Hubert Maier

r6265 is fine

r6272 is the culprit

Though turning "Brightening" off doesn't help, it's still eating away gfx mem and refuse to give it back after quit.

PS: What is that "Brightening" supposed to do?
I can set the sliders to 100% on each side and nothing happens

Last edited 4 months ago by Hubert Maier (previous) (diff)

comment:27 in reply to:  26 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

r6272 is the culprit

Hmpf. I feared that… No idea yet.

PS: What is that "Brightening" supposed to do?
I can set the sliders to 100% on each side and nothing happens

Lists with sortable columns will highlight the currently sorted column. The List2 demo demonstrates this.

comment:28 Changed 4 months ago by Hubert Maier

No problem, take your time

comment:29 Changed 4 months ago by Thore Böckelmann

A slightly modified version with brightening code disabled. This is essentially the only modification compared to previous commits.

commit 6272 without brightening
commit 6272 debug version without brightening

comment:30 Changed 4 months ago by Hubert Maier

I have bad news, this release still has the issue in place.

Why am i the only one testing here, btw, where is K-L??? :-)

comment:31 Changed 4 months ago by Thore Böckelmann

comment:32 Changed 4 months ago by Hubert Maier

Yep, r6271 is fine

comment:33 Changed 4 months ago by K-L

Hi,

I'm following your results by mail :-)

I'm on holidays so I did not test the debug buids but as far as I can see, you managed to track the culprit.

comment:34 Changed 4 months ago by Hubert Maier

@K-L

Pfft, i at least expect a bag of sand from the beach you are slowly tanning… ;-)

…and maybe a shell for Thore :-D

comment:35 Changed 4 months ago by Thore Böckelmann

Another test build of r6272 with some more code disabled:

commit 6272
commit 6272 debug version

comment:36 Changed 4 months ago by Hubert Maier

This still has the problem in place, i'm afraid

comment:37 Changed 4 months ago by Thore Böckelmann

Well, then there is nothing else I can do. The List class of the last test build has all the fancy stuff disabled and is in no way different from r6271 (except the missing brightening stuff). And the column brightening stuff is the all that r6272 is about. All other changes are either locale stuff or MUI prefs. If r6271 works but r6272 - modified or unmodified - does not, then I am completely out of ideas what might be causing this issue. And since I am not able to reproduce it myself I cannot provide a solution at the moment.

comment:38 Changed 4 months ago by Hubert Maier

Maybe if someone else could cross-check (K-L?), there is always a slim chance i mixed something up while testing.

Right now i still have the last (6272 from comment #35 in place and it's displaying said behaviour.

Thank you so far for providing the test builds.

Do i understand it correctly that everything else was stripped except the column brightening stuff?
If that is the one still in the place, shouldn't that be the culprit then?
Maybe i misread though

comment:39 Changed 4 months ago by Thore Böckelmann

All row and column brightening effects have been disabled, because this is essentially is what r6272 is all about. Before the column brightening was hard coded to +20%, with r6272 it became user configurable. That's all.

Have you tried resetting all MUI settings to defaults already? Perhaps that makes a change.

I am still wondering what kind of "monitor to check video memory consumption" K-L is referring to. Is the WB title bar sufficient? If yes, then I cannot do anything about that, because WinUAE/PPC emulates a Picasso4 with 4MB video RAM only and that is almost completely eaten up by the Workbench screen already. There are 7K left initially and these decrease to 0K as soon as any further window is opened.

comment:40 Changed 4 months ago by Hubert Maier

All MUI settings set to default - no change.

I don't know what K-L is using.
I'm using two things to chek/display my gfx mem
1) env var text display in the WB titlebar (Total/Used)
2) The GFXMem docky which graphically displays the used mem in either % or MB

Both show the same gain in used mem when opening sites (no need to let them load completely, just surf to different sites) and the same amount of non-freed mem after i close the program.

I have yet to find another MUI based program that displays the same behaviour, so i might be guessing that Odyssey is doing something "special" which breaks.

Could you enhance your virtual video mem somehow?
I wonder what happens when your systems asks for more video mem? Maybe it silently gets added in the background, or your "normal" memory is decreasing is that case?

comment:41 Changed 4 months ago by K-L

I'm using : http://os4depot.net/index.php?function=showfile&file=utility/workbench/titlebarclock.lha (and GFXDock from the zTools package available on AmiStore).

comment:42 Changed 4 months ago by Hubert Maier

Maybe it's easier to track whats happening with a single site?

Go here: https://www.netbank.de/privatkunden/
Make that a bookmark or a link button and keep spamming it.

It takes five or so reloads of that specific page to eat away a percent of my GFX mem.
I'm not sure why, but it does that all the time, there are more sites out there, but maybe it has to do with some of the page's source that is interfering?

comment:43 in reply to:  42 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

It takes five or so reloads of that specific page to eat away a percent of my GFX mem.
I'm not sure why, but it does that all the time, there are more sites out there, but maybe it has to do with some of the page's source that is interfering?

And exactly this is the strange thing about this issue. r6272 just changes the column highlighting in List class. Before it was fixed, now it is user configurable. Nothing more, nothing less. Why should reloading a specific web page cause memory issues after that change, but not before?

comment:44 Changed 4 months ago by Hubert Maier

I don't want to give you more work than you already have, but would it be possible to add some kind of debug flag/output which counts the accesses to the column hightlighting/List class?

That way i could check if the access count is higher than it was with the fixed version…maybe it's just the access /from Odyssey) to that List class that is eating away the memory (and it couldn't be seen/didn't made a differnence when it was static)?

Just a guess

comment:45 in reply to:  44 Changed 4 months ago by Thore Böckelmann

Replying to Hubert Maier:

I don't want to give you more work than you already have, but would it be possible to add some kind of debug flag/output which counts the accesses to the column hightlighting/List class?

I doubt this will reveal anything. The column brightening code was there before already, just the level of brightening was fixed. Now the level can be configured (and switched off completely by setting it to zero or "off").

K_L's debugging tool TitlebarClock doesn't help me either, because for me it just visualizes exactly the same values as the normal Workbench title bar on my virtual OS4 setup: video memory is extremly low even without any MUI application from the beginning. So there is no additional consumption that I could monitor.

Furthermore the function to apply the brightening effect has been in place for years by now and never caused any memory leaks. Why should it do now? There must be something else which is causing this issue. And my assumption is that r6272 is not the really guilty commit, even if it is the first revision to reproduce this issue for you.

It would be really helpful if either K-L or anybody else could confirm or refute this issue.

comment:46 Changed 3 months ago by Hubert Maier

@Thore

I think i found the reason, but i'm not sure so please bear with me.

For your convenieance i have added the gfx mem usage for the single steps below

Steps to reproduce:

1) Open MUI prefs (with no other program open, just MUI prefs after a reboot)
2) Head to the "Groups" setting
3) Open the "Container" setting
4) In the "Frame" setting there is the possiblity to choose "walkero / chips" images as background…do so and get mad :-)
5) Click through the three chips graphics over and over again and watch your gfx mem get eaten away by the second

Gfx mem usage:

0) I normally start off with 40% gfx mem used after the system has completely loaded (roughly 99 MB used)
1) After starting MUI prefs - 42% are used (104 MB)
2) Inside the "Groups" setting - 44% are used (109 MB)
3) "Container" setting - 47% used (117 MB)
4) "Frame setting" - another 3% gone, 50% used (124 MB)
5) For every "chip" graphic i now click on, another 1-3% get eaten away until it reaches 75% (where i then get a warning from the gfxdock docky). But i can fill up to 100% where the system refuses to open any new window and i'm stuck with the need to reboot.

If i f.e. fill up my gfx mem with this method to 75% and then CANCEL the changes and close MUI prefs only, 3% of my gfx memory gets returned!!!

btw:
Actually every start of MUI prefs eats away gfx mem which won't get returned, but it's so little (if you close it immediately again) that you would need to open and close it a dozen times to actually see it, the way described above is by far easier and faster.

This is with the latest "official" release.
Now that the focus lies somewhere else, maybe you could provide new debug builds (if needed?)

Why that only seems to display with the aforementioned changes is beyond me though…

I will check with one of the "clean" debug builds too and report back

UPDATE:
Tested with the "last known" working version 6271

It DOES display the same behaviour, but on a MUCH smaller scale.

  1. The gfx mem usage going to the "Container" setting (from Groups) takes only away 1% (instead of 3%)
  2. Clicking madly on the chips graphics need MUCH more time to actually eat away gfx mem (30 to 50 times for approx. 3% of gfx mem), BUT these 3% are also gone and never returned!

@K-L

Please check aswell

Last edited 3 months ago by Hubert Maier (previous) (diff)

comment:47 Changed 3 months ago by Thore Böckelmann

With your instructions I am able to reproduce a constant memory decrease on AmigaOS3 with every single change of bitmap frames. Since AmigaOS3 has nothing comparable to "video" memory and since my virtual AmigaOS4 system has no free video memory at all I can only hope that this outlines the same issue.

So far I have no idea yet what might be causing the memory loss, but expunging MUI from memory (MUI:FlushMUI) eventually releases all memory back to the system. So there must be some kind of caching involved.

Just to preempt your obvious answer: r6272 does not cover any kind of "caching" or similar. It just turns a fixed setting into a user definable setting.

comment:48 Changed 3 months ago by Hubert Maier

Wrt to r6272:

I know, I just wanted to be sure that the problem is still there with a "clean" revision as I wrote above.

I don't blame that version, I just wanted to cover every possibility.

Once I'm back home I can test old releases for this behaviour, if you need me to.

comment:49 in reply to:  48 ; Changed 3 months ago by Thore Böckelmann

Replying to Hubert Maier:

Once I'm back home I can test old releases for this behaviour, if you need me to.

That would be really helpful.

comment:50 Changed 3 months ago by jPV

Friend of mine told that his (this?) memory consumption issue can be reproduced even by keeping the mouse button pressed on the main MUI settings listview and keep selecting different setting pages. If you keep doing this long enough, all memory is consumed, and when you close the MUI settings window, hundreds of megabytes of memory isn't freed and is left missing from the original situation.

comment:51 Changed 3 months ago by K-L

I can confirm that r6271 is ok for me, far better than r6272.

Last edited 3 months ago by K-L (previous) (diff)

comment:52 in reply to:  49 Changed 3 months ago by Hubert Maier

Replying to Thore Böckelmann:

Tested the prior release R1-2018 Version: 21.125 (svn 6249) from 03.04.2018 and it doesn't have that behaviour.

comment:53 Changed 3 months ago by Thore Böckelmann

Please try these two test builds:
with
without

They represent the current state of affairs, but the "without" version will never add the root scrollgroup in case window contents do not fit on the screen. This was the only code change between r6249 (2018R1) and r6251 (first nightly build after 2018R1). According to #379 this was the first build to cause issues.

comment:54 Changed 3 months ago by Hubert Maier

I'm afraid both these builds display the issue heavily

comment:55 Changed 3 months ago by Thore Böckelmann

Ok, three more test builds:

r6251 with
r6251 without
r6249 2018R1 rebuild

These three build represent the two commits around 2018R1.

comment:56 Changed 3 months ago by Hubert Maier

All of the above are fine

comment:57 Changed 3 months ago by Thore Böckelmann

Cc: Samir Hawamdeh added

Hm, that's strange. According to #379 r6251 war the first build to cause strange issues, even if the modified parts of the code never became active.

Samir, can you please check the three builds as well?

comment:58 in reply to:  50 Changed 2 months ago by jPV

Replying to jPV:

Friend of mine told that his (this?) memory consumption issue can be reproduced even by keeping the mouse button pressed on the main MUI settings listview and keep selecting different setting pages. If you keep doing this long enough, all memory is consumed, and when you close the MUI settings window, hundreds of megabytes of memory isn't freed and is left missing from the original situation.

A small update to this, the "long enough" means about 5 mins or so. And his system just hangs if he tries to open anything after running memguard…

comment:59 Changed 8 weeks ago by K-L

Hi all,

I reverted to R1 and won't update to any new version since this causes too much trouble (I can't open too many MUI applications without loosing all my V-Mem).

I tested the builds and still encountered the trouble.

R1 has no problem at all.

Has there been any news regarding this topic ?

comment:60 Changed 7 weeks ago by Thore Böckelmann

Unfortunately there has been no progress. I have been on vacation with my family lately and I will have no time to continue research for the next 2 weeks.

The strange thing is that 2018R1 works but the first nightly builds (r6251) after that release cause issues. But according to Huberts latest comment the rebuilt versions from exactly that commit is working without causing issues. Neither the build environment nor the source code did change between these two builds. So why does one build work while the other doesn't?

comment:61 Changed 7 weeks ago by Hubert Maier

It would probably be best if anyone else than me cross checks the three latest builds rom comment 55 to rule out anything stupid *i* did while testing.

I'm going to retest them myself too once more.

comment:62 Changed 7 weeks ago by Hubert Maier

@K-L

I tested the builds and still encountered the trouble.

Which builds?
Which worked and which didn't?

comment:63 Changed 7 weeks ago by Hubert Maier

@Thore

I have retested (with more time) all of your builds and have to admit i made a mistake :blush:

Somewhere along my last testings something stupid crept into my brain and made me (probably, as i don't really know for sure) miss actually copying the test builds to the installation drawer, which let me test old versions that worked.

I have found (due to my recent testing of builds from #379) that r6261 is the one that first displays the bahaviour, while r6251 is working perfectly fine.

Would you please spend some more time building inbetween versions or do you already see where it could have been broken?

Sorry for the inconveneance :-(

comment:64 Changed 6 weeks ago by Hubert Maier

@Thore

No to sound pushy, but did you see my last comment?

comment:65 Changed 6 weeks ago by Thore Böckelmann

Yes, I did see it. But I have wife, children, house, etc, and little spare time recently.
I hope to build some further interim versions tonight when I am back from work.

Unfortunately I have no idea yet what could be the culprit between r6251 and r6261. Most commits deal with translations or Changelog modifications only, two cover handling of gradients and the remaining three cover the handling of eventhandlers.

Are you using gradients in any way? Since we are talking about video memory trouble here this is the only modification between r6251 and r6261 which possibly could cause the described issue.

Last edited 6 weeks ago by Thore Böckelmann (previous) (diff)

comment:66 Changed 6 weeks ago by Hubert Maier

…and i apologize for dragging you away from much more important things, i just wanted to be sure that it doesn't get lost.

I tend to not touch the global MUI settings, if i change something i do it on the app level (YAM, Odyssey) so i'm not really sure if my settings are default settings or settings i changed it some years back and forgot about them.

On a quick check i see gradient settings in
1) "Buttons", "Text Buttons" > "Look" (the right one is set to "Gradient: vertical")
2) "Buttons", "Slider" > "Look" (the right one "background" is set to "Gradient: horizontal")
3) "Lists", both "Knobs" have gradient set.
4) "Images" > "Used images", "backgrounds" have a gradient setting

comment:67 Changed 6 weeks ago by Thore Böckelmann

Here are two more test builds:

Unchanged gradient
Without gradient related changes no_gradient

comment:68 Changed 6 weeks ago by Hubert Maier

We are on the right track, i believe :-)

6261 with gradient - gfx mem problem

6256 no gradient - no gfx mem problem

comment:69 Changed 6 weeks ago by Thore Böckelmann

That's good to hear! At least the issue can be restricted to a very small modification. It seems the internal hashing algorithm to cache images (a gradient is treated as an image) is mixing up identical gradient and hence recreates them over and over again and thus constantly consumes memory.

Here is another test build based on r6261 but with a slightly different way to calculate the hash value: gradienthash

comment:70 Changed 6 weeks ago by Hubert Maier

I'm afraid the bug is still there with the gradienthash test build

comment:71 Changed 6 weeks ago by Thore Böckelmann

In 6364:

  • Imagespace.c: added the missing initialization of the flags field when adding a new entry to the hash table. This refs #387.

comment:72 Changed 6 weeks ago by Thore Böckelmann

Please test the possibly fixed build based on r6261 as well:
fixed hash

And of course the next nightly build, which will contain the fix as well.

comment:73 Changed 6 weeks ago by Hubert Maier

You did it :-D

Thanks a lot

comment:74 Changed 6 weeks ago by K-L

Yes ! I confirm the fixed hash version is working flawlessly ! :-)

comment:75 Changed 6 weeks ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Resolution: fixed
Status: newclosed

In 6365:

  • Imagespace.c: set up the hash key only once when looking up and creating new image cache nodes to avoid forgetting to initialize certain variables. This finally closes #387

comment:76 Changed 6 weeks ago by Thore Böckelmann

Component: undefinedImagespace.mui
Milestone: future release5.0-2018R4
Priority: undecidednormal
Note: See TracTickets for help on using tickets.