LOADSPRITE and Memory

[Hemlos]

The images are "as is" found on thier website. They are square jpgs.
I just netwebget "latest_ful.jpg" ...thats it.
I name them with timestamps.
And you must run it for a day or two to get a decent animation.
Note: it does not download an archive...its only a latest live version when you run it.
If it downloads an image of the same kb it deletes it and tries again at the next interval.

Edit;
note:
the images there are from the last 2 days since i got it running correctly

[fuzzy70]

I must point out there was a post sometime back with regards to problems with some images acquired via netwebget. If I remember correctly they where greyscale JPG's upon inspection. I will have to see if the post is still about on the forum.

Lee

EDIT - Found it http://www.glbasic.com/forum/index.php?topic=9220.0

[MrTAToad]

If it is any consolation, it does work fine on x64 Windows 8 - there is no memory change; it is all constant.

It does sound like a limitation of 32-bit Windows - it could be having to use the page file for it's work...

[Hemlos]

It does sound like a limitation of 32-bit Windows - it could be having to use the page file for it's work...

I compiled on an 64 windows 7
AMD a10 trinity w/8gb ram and 250gb ssd......


....with or without the paging file, i get the same exact issue....and the paging file doesnt seem to do anything as far as taking some of the memory load when the ram becomes critical

Sounds to me....a memory leak in LOADSPRITE

[MrTAToad]

I wonder if there is still a loading problem with JPEGs...

[Hemlos]

I wonder if there is still a loading problem with JPEGs...

I just tested it by converting the jpegs to png....they went from 1 mb to 10 mb image file size.

And...The amount of memory being sucked up is the same.

[fuzzy70]

Just done the same tests again but with BMP's & PNG's & witnessed exactly the same memory pattern as before.

I said that earlier.

Probably a dumb question but could it be related to the size. For example gfx cards have differing texture size limits?, assuming GLB treats a loaded image as a texture that is.

Lee

[Moru]

Since you are loading images into glbasic, you need enough memory for them on the grafics card. I'm not sure how GLBasic handles this but I can imagine there will be trouble trying to load 1.5 GB of data onto the grafics card if it has shared memory with the computer. Are you doing an animation of these live pictures? I have done something similar, I downloaded them locally like you and used a program to combine them into a normal Xvid movie instead of even attempting to load them into GLBasic :-)

[MrTAToad]

I wonder if there is still a loading problem with JPEGs...

I just tested it by converting the jpegs to png....they went from 1 mb to 10 mb image file size.

And...The amount of memory being sucked up is the same.

Not surprising that the converting to PNG would produce large files

I presume that memory was still being continually consumed - does your program still crash after a while ?

One thing : How are you removing the graphics (assuming you do), or are you just reloading them over each other ?  I was wondering if, when doing something like LOADSPRITE "",0 - that the memory being used by that sprite may not being totally freed, and thus a reload would consume more, and one after that would consume even more, and so on...

If you are loading without freeing, then its possible that LOADSPRITE isn't deleting memory beforehand.

[Hemlos]

If you are loading without freeing, then its possible that LOADSPRITE isn't deleting memory beforehand.

Aye
Well if the live image is a dupe....
LOADSPRITE "", self.INDEX
....and this index is reused later on when it isnt a dupe.
I made very sure that the memory doesnt have a leak when loading the images.
Im assuming saving as a BMP as opposed to a PNG isnt much of an alternative either.

Since you are loading images into glbasic, you need enough memory for them on the grafics card. I'm not sure how GLBasic handles this but I can imagine there will be trouble trying to load 1.5 GB of data onto the grafics card if it has shared memory with the computer. Are you doing an animation of these live pictures? I have done something similar, I downloaded them locally like you and used a program to combine them into a normal Xvid movie instead of even attempting to load them into GLBasic :-)

My graphics card has 2 gig ram, thats why i dont understand why my binary is clogging up the main cpu ram when the images are about half that total size.
Yes, i am itterating through ZOOMSPRITE, incrementing the index every 128 milliseconds to make an animation which includes the latest live downloaded image.

  Display adapter type AMD Radeon HD 6670
  Total available graphics memory 5863 MB
        Dedicated graphics memory 2048 MB
        Dedicated system memory 0 MB
        Shared system memory 3815 MB
  Display adapter driver version 14.100.0.0
  Primary monitor resolution 1920x1080
  DirectX version DirectX 10

The available is higher, because this is an APU, which uses the gfx card memory first, after that is filled then it will spill into the motherboard ram.

When the sucks up about 6 gig of ram on the mb(during load time because i already have 40+ images ready to load)...this is when the app crashes.
The crash happens when it is loading image # 38+, not before.

This isnt a wierd native bug i created either, because a test case shows:
im using another version of the same routine, which is loading images that are only 100k in size.
...and so far i have not exceeded a gig of image space, yet....im at frame # 69 now.....that is 69 x 2 = 138 images being loaded. (2 satelites animating)

[Hemlos]

I think i figgured it out!

On Linux....works fine minimized, i can keep it minimized for days and it still renders....

On windows.....i think.....DIRECTX is dorking the rendering when the program is minimized?

[MrTAToad]

You have stumbled on something there!

Tried it with a test program here, and memory usage is slowly increasing when minimised and stopped when the program is restored!

I have left mine running (minimised) whilst I'm out - the program starts at 30Mb, so it'll be interesting to see how much it is when I get back.  It looks like 0.1Mb is consumed every second, so theoretically it should have increased by around 30Mb by the time I get back

[MrTAToad]

Weird - its gone down to 9.1Mb 

However, the program has crashed 

[Hemlos]

Sprung a memory leak.   

[MrTAToad]

I think we've found a bugette!