Asp Forum - GDI+ - microsoft.public.vb.general.discussion

Mayayana

11/8/2011 3:35:00 PM

Does anyone have the whole skinny on GDI+
stability? I'v got an Explorer bar that has crashed,
though only once. It was on the first folder opening,
without doing any graphics operations, so I'm
guessing it has to do with loading gdiplus.dll?

Norm Cook mentioned loading it specifically, but I
don't find any info. about that online. What I have
found are worrisome discussions about GDI+ causing
crashes if there's a corrupt font on the system.

Another issue is that GDI+ doesn't seem to get put
into the System32 folder. There are several copies
in winsxs (which is weird because that folder is barely
used on XP, which is where I'm working). And software
such as OpenOffice seems to use its own copy. Should
I be putting a copy in my program folder? Is there an
explanation somewhere about the explicit LoadLibrary
usage? Is GDI+ simply unstable?

3 Answers

ralph

11/8/2011 7:01:00 PM

On Tue, 8 Nov 2011 10:35:12 -0500, "Mayayana"
<mayayana@invalid.nospam> wrote:

> Does anyone have the whole skinny on GDI+
>stability? I'v got an Explorer bar that has crashed,
>though only once. It was on the first folder opening,
>without doing any graphics operations, so I'm
>guessing it has to do with loading gdiplus.dll?
>
> Norm Cook mentioned loading it specifically, but I
>don't find any info. about that online. What I have
>found are worrisome discussions about GDI+ causing
>crashes if there's a corrupt font on the system.
>
> Another issue is that GDI+ doesn't seem to get put
>into the System32 folder. There are several copies
>in winsxs (which is weird because that folder is barely
>used on XP, which is where I'm working). And software
>such as OpenOffice seems to use its own copy. Should
>I be putting a copy in my program folder? Is there an
>explanation somewhere about the explicit LoadLibrary
>usage? Is GDI+ simply unstable?
>

That's a bunch of questions. <g>

Here is my take on what you are asking (likely unsatisfactory <bg>).

GDI+ is what MS calls a subsystem over the GDI API - a "C++ based
interface" or class library replacement. Think of it as a wrapper to
make using GDI easier. It is quite successful. Instead of managing
every element directly you create a graphics object and intuitively
chew on it. But like any wrapper, while it adds some features that
would be more difficult if coding directly, it adds overhead, and
links you into using whatever resource management (devices, handles,
memory, ...) and procedures the authors decided to use when they built
the wrapper. (As well to any bugs or mistakes the authors missed.)

That management policy is by design a 'best case'. Which means that
most of the time it is appropriate for most scenarios inside a given
envelope, but can easily be inappropriate for anything that starts to
stretch that envelope.

For example, it is well known that GDI+ is generally slower than using
GDI directly. It tends to use more resources and not always that good
in cleaning up after itself. Here is where unloading/loading comes in.

Finding a hard answer is (and will be) hard to come by because 'best
practice' is so situational. If I told you I had three GDI+
applications that have been running flawlessly for years and will
certainly use it again - what does that mean for YOUR application? If
I told you I chewed on a troublesome GDI+ application for about the
same length of time and finally bailed and re-wrote it using the GDI
API - what does that tell you about YOUR application?

[Everything is a trade-off. In this case ease of programming vs.
resources. If rendering thousands of graphics use GDI, if only a
couple - the GDI+ is fine. If writing a game - use DirectX. Lots of
animation - definitely something else. A couple of clever dialogs -
GDI+ makes it too simple to pass up.]

The problem with a corrupt font is well known. AFAIK the only way to
protect yourself is to run a MS supplied utility to check Fonts. (They
may have fixed it by now?) Personally it doesn't bother me that much.
I fault the authors for failing to catch the problem and offering a
more graceful exit, but after-all a corrupt system file is a corrupt
*system* file. The crash profile is equally well-known and the fix
quick.

IMHO ALL graphics or device programming is inherently unstable - too
much can go wrong and always does while developing. (At least for me
it seems <g>) If you don't crash the box 6 or 7 times you aren't doing
it right. Close down and restart with a clean-slate often. Never judge
a library or technology until you have a release. Then test, test,
test.

I never include the GDI+ library with any install. I prefer using MS's
utility whenever it is necessary to install it.
http://www.microsoft.com/download/en/details.asp...

Why? Simple. I have no desire to go into that business. <g> I don't do
anything particularly clever that makes me dependent on any specific
version. (Well, so far anyway.)

If you feel you need the additional comfort level then go with a
side-by-side strategy. It is your call there is no "best practice".

-ralph

Mayayana

11/8/2011 7:14:00 PM

Thank you, Ralph. I've been finding GDI+ fine for
saving JPGs in a normal EXE. In my Explorer bar
perhaps I'm asking too much of it. It takes down
Explorer itself if there are any problems, so I need
it *very* stable.
I started using
it because StretchBlt makes a mess of very large
images shrunk to thumbnails. But I have straight
VB bicubic interpolation code (which can't be much
slower than using GdipDrawImageRectRectI as a
StretchBlt replacement) so maybe I'll try that.

--
--
"ralph" <nt_consulting64@yahoo.net> wrote in message
news:oapib7l6hr7icg4s42u06scqs193u43uv7@4ax.com...
| On Tue, 8 Nov 2011 10:35:12 -0500, "Mayayana"
| <mayayana@invalid.nospam> wrote:
|
| > Does anyone have the whole skinny on GDI+
| >stability? I'v got an Explorer bar that has crashed,
| >though only once. It was on the first folder opening,
| >without doing any graphics operations, so I'm
| >guessing it has to do with loading gdiplus.dll?
| >
| > Norm Cook mentioned loading it specifically, but I
| >don't find any info. about that online. What I have
| >found are worrisome discussions about GDI+ causing
| >crashes if there's a corrupt font on the system.
| >
| > Another issue is that GDI+ doesn't seem to get put
| >into the System32 folder. There are several copies
| >in winsxs (which is weird because that folder is barely
| >used on XP, which is where I'm working). And software
| >such as OpenOffice seems to use its own copy. Should
| >I be putting a copy in my program folder? Is there an
| >explanation somewhere about the explicit LoadLibrary
| >usage? Is GDI+ simply unstable?
| >
|
| That's a bunch of questions. <g>
|
| Here is my take on what you are asking (likely unsatisfactory <bg>).
|
| GDI+ is what MS calls a subsystem over the GDI API - a "C++ based
| interface" or class library replacement. Think of it as a wrapper to
| make using GDI easier. It is quite successful. Instead of managing
| every element directly you create a graphics object and intuitively
| chew on it. But like any wrapper, while it adds some features that
| would be more difficult if coding directly, it adds overhead, and
| links you into using whatever resource management (devices, handles,
| memory, ...) and procedures the authors decided to use when they built
| the wrapper. (As well to any bugs or mistakes the authors missed.)
|
| That management policy is by design a 'best case'. Which means that
| most of the time it is appropriate for most scenarios inside a given
| envelope, but can easily be inappropriate for anything that starts to
| stretch that envelope.
|
| For example, it is well known that GDI+ is generally slower than using
| GDI directly. It tends to use more resources and not always that good
| in cleaning up after itself. Here is where unloading/loading comes in.
|
| Finding a hard answer is (and will be) hard to come by because 'best
| practice' is so situational. If I told you I had three GDI+
| applications that have been running flawlessly for years and will
| certainly use it again - what does that mean for YOUR application? If
| I told you I chewed on a troublesome GDI+ application for about the
| same length of time and finally bailed and re-wrote it using the GDI
| API - what does that tell you about YOUR application?
|
| [Everything is a trade-off. In this case ease of programming vs.
| resources. If rendering thousands of graphics use GDI, if only a
| couple - the GDI+ is fine. If writing a game - use DirectX. Lots of
| animation - definitely something else. A couple of clever dialogs -
| GDI+ makes it too simple to pass up.]
|
| The problem with a corrupt font is well known. AFAIK the only way to
| protect yourself is to run a MS supplied utility to check Fonts. (They
| may have fixed it by now?) Personally it doesn't bother me that much.
| I fault the authors for failing to catch the problem and offering a
| more graceful exit, but after-all a corrupt system file is a corrupt
| *system* file. The crash profile is equally well-known and the fix
| quick.
|
| IMHO ALL graphics or device programming is inherently unstable - too
| much can go wrong and always does while developing. (At least for me
| it seems <g>) If you don't crash the box 6 or 7 times you aren't doing
| it right. Close down and restart with a clean-slate often. Never judge
| a library or technology until you have a release. Then test, test,
| test.
|
| I never include the GDI+ library with any install. I prefer using MS's
| utility whenever it is necessary to install it.
| http://www.microsoft.com/download/en/details.asp...
|
| Why? Simple. I have no desire to go into that business. <g> I don't do
| anything particularly clever that makes me dependent on any specific
| version. (Well, so far anyway.)
|
| If you feel you need the additional comfort level then go with a
| side-by-side strategy. It is your call there is no "best practice".
|
| -ralph

Abhishek

11/8/2011 8:48:00 PM

I have used GDI+ in my apps and I just put it in app.path folder, instead of
system32 to avoid any conflicts with other software.

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:j9bi70$nsl$1@dont-email.me...
| Does anyone have the whole skinny on GDI+
| stability? I'v got an Explorer bar that has crashed,
| though only once. It was on the first folder opening,
| without doing any graphics operations, so I'm
| guessing it has to do with loading gdiplus.dll?
|
| Norm Cook mentioned loading it specifically, but I
| don't find any info. about that online. What I have
| found are worrisome discussions about GDI+ causing
| crashes if there's a corrupt font on the system.
|
| Another issue is that GDI+ doesn't seem to get put
| into the System32 folder. There are several copies
| in winsxs (which is weird because that folder is barely
| used on XP, which is where I'm working). And software
| such as OpenOffice seems to use its own copy. Should
| I be putting a copy in my program folder? Is there an
| explanation somewhere about the explicit LoadLibrary
| usage? Is GDI+ simply unstable?
|
|

microsoft.public.vb.general.discussion

GDI+

Mayayana

ralph

Mayayana

Abhishek

x Login to ForumsZone