Sharon,
Inline.
Willy.
Sharon said:
Hi Willy,
Thanks again for your help.
It will be good if the allocated memory for the image loading will be
available in the C# app, so I thing I will work with unsafe code and
pointers
to do it.
I do not have the xpsp2res.dll problem because unmanaged C++ application
successfully using large memory chunk (850 MB loaded image).
Well, actually an unmanaged C++ application using graphics (GDI etc.) might
load xpsp2res.dll, so any managed app. that interops with MFC C++ will have
this module mapped in it's address space. I'm pretty sure GraphicsSuite
(
http://www.codeproject.com/bitmap/graphicsuite.asp).) do load xpsp2res.dll
(note that this is for XP/SP2 only).
It seems like you do not correctly understand what .NET is (I'm not talking
about the marketing term), it's nothing more than an OO oriented API
supported by a sophisticated run-time (the CLR). The API is thin, in some
area's almost nothing more than a direct call into unmanaged code loaded by
the CLR or a call into the CLR itself. The bulk of the code running in a
process is nothing more than unmanaged code taken from the loaded win32
DLL's available in the system (not .NET). Even the "Fatter" managed API's
like Windows.Forms are simply wrappers arround unmanaged Windows code used
by any other unmnaged process/windows application. That means that most
restrictions like the memory usage pattern you are describing, is also valid
for non ".NET" applications.
What I’m trying to achieve?
Ok, we are working on a project that among other think receives on run
time
large reference image on file, this image is then loaded to memory and
scanned to compare it with a smaller images generated on run time using
cameras.
One of my role in this project is to create GUI that will also has a
control
that shows the reference image and draw on it some more data and has a
zooming and scrolling capabilities with high resolution.
As we already know, the .NET PictureBox control can not handle that big
image. So I need to build one from scratch. But then again, I fail to load
this image at all in the C# application.
Beware, there is no such thing as a .NET PictureBox, the PictureBox is an
unmanaged control that uses GDI, not GDI+) , just the same control as would
be used by any unmanaged application. But as you already experienced, the PB
was not meant to be used to hold images that are 10 times the sceen size,
that's one thing, the other is that the PB can handle images as large as the
amount of free memory (contigious) allows.
So I’m trying to find some reasonable way to create this king of
control.
As you know now, I’m trying to approach this issue from many ways; the
last
resort that I can think of is divide the project into two processes (at
least
two), managed and unmanaged. The unmanaged process will load the image and
will help with the zooming and scrolling by each time copying some portion
of
the loaded image and use it to create a new image that will have the size
of
the GUI control client area. Then the C# process will take this new
smaller
image and will draw it on the control.
Waw, this will be slow!
The trouble with this solution is it requires more then one process, some
kind of process communication (COM+ or shared memory etc.), maybe some
reduced performance, longer development time that we do not have and who
knows what more.
If there is a way to go, it's the Shared memory way you should go.
It should be much simpler.
Yes, and that's when you are writing the whole image handling stuff in C++,
or move to 64bit.
Another bad solution will be to create a smaller image (a lot smaller that
will result on poor summing resolution) from the large reference image
(that
also I need an unmanaged process for it), and use it in the .NET
PictureBox
control.
But for that I need to do the resizing in run time that takes a lot of
memory, and I will need to hold in memory 2 images, the original one (for
algorithm issues) and another one for the GUI.
We can not move the entire project to C++ because this is a big project,
most of it is already written, and it will consume a long time to rewrite
it,
time that we do not have.
I hope I made the problem more understood.
More or less, but I don't get what you mean with a large project, no-one
said you can't mix C++ and managed code in a large project, all you have to
do is take the appropriate language for the imaging stuff .
My problem with the .NET frame work is that event if a .NET application
can
have only ~1.406.000Kb minus all the needed memory for the .NET should
leave
me with a least 850MB of continues memory.
No, no 1.4GB is the max. free block when GDI+ is not loaded into the
process, but if you use C# with System.Drawing, you bring in GDI+, the same
is true for C++, once you load gdiplus.dll in a process the largest free
block is reduced to 1.83GB, because the dll is loaded at baseaddress
0x5ec50000. So, yes probaly 850MB will not be a problem as long as you don't
have to copy this whole block to the managed heap.
The difference between C++ application and a C# application is too great
concerning memory consumption and / or fragmentation.
How and what do you compare? The fragmentation is the same, did you actually
run the C# code that I corrected, it should work (as long as you don't copy
the buffer, but that's the same for the C++ version)?