ImageLibEx library

[klaus]

On my Sony Vaio labtop with NVIDIA GeForce Go 7400 graphic card,
with XP SP3 and color depth set to 32 bits it works OK.

Best regards.

[agraham]

Looks like it may be a chipset/driver issue. My EEE PC and Laptop are both XP SP3 but both use an Intel graphics chip and driver and both work at 16bit but not 32 bit color depth.

[agraham]

Version 1.6 now posted with a single change.

I tried to use dzImage screen capture on the device but it wouldn't work for me so I have added a ScreenCapture method to BitmapEx.

[eww245]

Good job on the ScreenShot, nice and simple.

[agraham]

Version 1.7 posted.

Added to DrawerEx are Draw/FillArc and Draw/FillPie methods. The "1" methods draw circles, the "2" methods draw ellipses. Although you can draw circles with the ellipse methods they are more processor intensive as they deal with two axes whereas the the circle methods do less processing as they only deal with a radius. The demo has an extra page added to show these.

Unlike the other DrawerEx methods these new methods are not native but are coded within ImagelibEx and use Draw/FillLines and Draw/FillPolygon to draw so there may be a performance penalty when using them compared to using the native methods.

[agraham]

Version 1.8 posted with some significant improvements.

The Draw/FillArc and Draw/FillPie methods added in version 7 have their zero points moved to 12 o'clock (from 3 o'clock - a bad previous decision ) to match a compass.

DrawLineDashed and DrawLineDashDot methods are added to DrawerEx to enabled various patterns of line to be drawn.

GcCollect and GetTotalMemory are added to BitmapEx. These are intended for possible diagnostic use and should not be required in normal use.

A Locked property, and LockBits, GetLockedPixel, SetLockedPixel and UnlockBits methods are added to BitmapEx to provide fast low level access to bitmap pixel data if required.

[corwin42]

Originally Posted by agraham

GcCollect and GetTotalMemory are added to BitmapEx. These are intended for possible diagnostic use and should not be required in normal use.

As you mention this I have a question about memory handling and BitMapEx objects.

I'm currently writing an OpenStreetMap Mapviewer program for the device. OpenStreetMap Maps are generated from tiles with 256x256 pixels. For displaying the complete map I have to load several tiles and put them on an image. In the first version this was done with two BitMapEx objects. One for the tile (bmpTile) and another (bigger) for the map (bmpImage) which will be displayed.

The tiles were loaded with bmpTile.New1(filename) and then copied to the correct position on bmpImage with a DrawerEx Object with drwImage.DrawImage(bmpTile.Value, ...).

The problem with this solution was that when scrolling around, many tiles are loaded with bmpTile.New1() method and I get an OutOfMemory exception very soon.

I looked into the source of ImageLibEx and I don't understand why I get the OutOfMemory Exception because when the New1() Method is called the old bitmap gets disposed and a new one is created.

Is the GarbageCollector too slow in freeing the not used memory or is there somewhere a memory leak?

Currently I use a ControlsExDevice/NativeImage for Loading the tiles with nImgTile.LoadPicture(filename). This works well and I have no OutOfMemory exceptions any more.

As a conclusion BitMapEx.New1() method called several times on the same objects seems to eat up memory but I don't understand why. Perhaps I should try it again with calling GcCollect after calling bmpTile.New1() method.

Greetings,
Markus

[agraham]

Originally Posted by corwin42

I looked into the source of ImageLibEx and I don't understand why I get the OutOfMemory Exception because when the New1() Method is called the old bitmap gets disposed and a new one is created.

Ah, I had forgotten that was there! That Dispose in New1 actually does nothing! but is harmless. It is a result of my early misunderstanding of what Basic4ppc does when it sees a New method and I should have removed it a long time ago.

BmpEx1.New1(filename) ' creates a new instance of a BitmapEx and calls New1
....
BmpEx1.New1(filename)' creates another new instance of a BitmapEx and calls New1

The first BmpEx is left floating and unreferenced and should be swept up by the GC. The second BmpEx1 is a totally new instance and so has no reference to the original bitmap that was in the first BmpEx instance so the Dispose test is unnecessary.

Most of the memory in a Bitmap is unmanaged memory which the GC knows nothing about so successive calls to New1 to the same object build up a list of floating Bitmaps but as the managed memory overhead of a Bitmap is small the GC may not run before unmanaged memory runs out. Explicitly Disposing and recreating the BitmapEx object should overcome this problem.

BmpEx1.New1(filename) 
....
BmpEx1.Dispose
AddObject("BmpEx", "BitmapEx")
BmpEx1.New1(filename)' creates another new instance of a BitmapEx and calls New1

[corwin42]

Thanks very much for your explanation.

I have found some articles about this now in the internet and when I understand it correct, I should call Dispose() on objects which implement IDisposable when I don't need them any more.

I often call New() methods on objects to reinitialize them without disposing them first. Am I right that this is normally not a problem (because the GC will handle this) but it's a bad idea for objects that use unmanaged memory or implement IDisposable?

Thanks,
Markus

[agraham]

Originally Posted by corwin42

Am I right that this is normally not a problem (because the GC will handle this)

Yes, normally you should let the GC do its' job.

but it's a bad idea for objects that use unmanaged memory or implement IDisposable?

It's only really a problem for things like (and it's the only example I can think of) Bitmaps where the ratio of unmanaged memory used by the underlying native object is very large in relation to the small amount of managed memory used to encapsulate it for .NET use. Before reusing the same object name the only things other than Bitmap and BitmapEx that I would rooutinely Dispose would be Drawer andDrawerEx that are really GDI Graphics objects.

If you don't have problems I would not worry about memory use or using Dispose.