IGUIImage, getTexture, remoteTexture, am I doing this right?

Mloren · Post by **Mloren** » Mon Dec 27, 2010 3:24 am

So I just want to make sure I am doing this correctly:

I have an IGUIImage on screen that is initially a blank image.
The user can select an image from an IGUIComboBox and that image is displayed in the IGUIImage.

Currently what I do is when the combo box is changed, I load the image with IVideoDriver::getTexture() and then pass the result into IGUIImage::setImage().

Now what I'm noticing is that when the user then selects a different image, the old image is not freed from ram until the program closes. I assume I need to call IVideoDriver::removeTexture() if I want this to occur.

But IGUIImage doesn't have a getImage() function to get its current image so I would have to cache the pointer to the image myself elsewhere so I can remove it when the user is no longer viewing it.

Is this all correct?
Also is there any reason IGUIImage doesn't have a getImage() function? Could one be added?

CuteAlien · Post by **CuteAlien** » Mon Dec 27, 2010 9:49 am

Yes, that looks all correct. All textures are cached (and allowing to change this, for example with 1-2 additional IVideoDriver::createTexture functions which could work without caching might be a good idea... not sure right now if there's anything which would speak against that (except making the interface bigger), I remember people asked about that already in the past).

Also you are correct that IGUImage should have a getTexture. I'll add that when I find time in the evening.

CuteAlien · Post by **CuteAlien** » Mon Dec 27, 2010 8:35 pm

I've added getImage and getColor to IGUIImage in svn trunk, I hope it helps.

Mloren · Post by **Mloren** » Fri Dec 31, 2010 4:53 am

Sounds good but you said they are in the trunk?
I find the current SVN setup a little confusing, some stuff seems to get added straight to trunk while other stuff is in a branch. There seems to be a branch per Irrlicht version, whats the idea behind this?

I thought maybe everything would go into branch first and then get rolled across to trunk when a new version is released but this doesn't seem to be the practice.

I've also noticed that the differences between the trunk and 1.7 branch are huge.

All sort of inconvenient because there are changes in the branch that I need as well (I am currently working with the 1.7 branch).

CuteAlien · Post by **CuteAlien** » Fri Dec 31, 2010 10:14 am

In branch/releases you find the stable versions. So the only thing that goes in there are bugfixes.

Anything that changes the interface will go into svn trunk which contains the development version for the next Irrlicht (1.8). Also all bugfixes from the stable releases get merged with svn trunk every few weeks (and yeah, that means that we sometimes don't have a bugfix yet in the trunk).

So if you just want the latest stable (released) Irrlicht with all bugfixes you should use the release branches. If you need new features like the one I added above then you have to use the newest development version in svn trunk. We try to keep that working as well all the time, but it's less tested and you will run in a new bug once in a while as new features and new bugs usually go hand in hand.

My own way of working is either to use svn trunk (and report bugs which I can't fix myself) or to use svn branches + a bunch of patches. In most project I do the latter - I checkout once at project start and from there on I just add patches to my local version. And when I update the engine I go through the list of my patch-files and decide for each one if I have to apply it again or if that is fixed by now in the engine.

edit: And yeah - the gap between bugfixes in releases and getting the fixes into trunk is sometimes annoying. I've been myself a few times in the situation that I wanted a mix of both versions. That would need a change to our development model - maybe if everyone would add his bugfixes always in both versions directly it would be better. But we have to change that as team, if only one person adds patches to both it will get harder to merge (I accidentally did that in the past not knowing about it...).

hybrid · Post by **hybrid** » Fri Dec 31, 2010 4:16 pm

trunk should be at most a week from the branch revisions. I have a better time management currently, and get those merges more often now.

Mloren · Post by **Mloren** » Sat Jan 01, 2011 12:59 am

This seems like a very odd development model.

I would have thought Trunk would be the latest stable build and all changes would be made to branch and then once in a while rolled across to Trunk.

That way Trunk would be stable, branch would be latest and you would never want half of one and half of the other as the branch is always more up to date than Trunk.

Currently you are adding changes to both which is weird.

CuteAlien · Post by **CuteAlien** » Sat Jan 01, 2011 10:22 am

Uhm... releases are named releases because they are... released versions. And current development in a folder called trunk is rather standard.

And bugfixing in trunk and doing backports would be fine in theory - except that it makes merging probably harder. I would be fine with that in theory, but we would have to find some way that everyone marks which bugs then would have to be ported back.

But in your case using trunk is probably the best solution. It means you have to wait for the bugfix occasionally a little while, but as hybrid said above it's usually just for a week or so.

hybrid · Post by **hybrid** » Sat Jan 01, 2011 2:16 pm

Just check the SVN red book and you'll find this to be the suggested development way.

Mloren · Post by **Mloren** » Sun Jan 02, 2011 3:39 am

Has the memory leak in CImage been fixed in the trunk yet? (fixed in branch version 3517) because that's the reason I'm working out of a branch. It causes over 100mb of leaked memory in my project so I need that fix.