[RESOLVED] About RenderPNG function

[Daniel Duta]

Hi,
This thread is related to my previous issue regarding how to display a png image in a simple/simplest way. The Api function created by LaVolpe a few years ago www.vbforums.com/showthread.php?582741-RESOLVED-Minimum-code-to-draw-PNG-GDI worked very well in a certain context (within click event) but when I tried to call the same function in the Form_Load event I was surprised to see that the same pics cannot be loaded as before.
I suppose it is something related to the cycle of the Form loading event because it seems the device context hDC has not enough time to be read. Considering this effect, is it possible to call this function properly when the main form is loaded ?

[SamOscarBrown]

I haven't played with, seen, or used LaVolpe's code on that link, however, have you tried it in Form.Activate or Form.Initialize?

[LaVolpe]

Ensure the target you are drawing to has AutoRedraw=True. Otherwise, image is drawn before displayed & when displayed, the context is erased. AutoRedraw should solve that.

[Daniel Duta]

Thanks for reply, Sam. Yes, I have tried but whenever the main Form is re-sized (maximized/minimized) all pictures visible previously are disappearing. I think once the form is resized my pictures remain on the old x, y form coordinates...I am about to convert them in GIF format so that to make my life easier...

[SamOscarBrown]

Did you apply post #3 suggestion?

[Daniel Duta]

After many attempts I have managed to use the RenderPNG function properly. Yes, LaVolpe, I set the form to AutoRedraw=True from beginning and I tested your function in many possible scenarios (especially related to form events) but with no success. After I read with caution your response I tried to dig deeper into my issue and I noted that my Picture control - the place where I put the png file via the RenderPNG function - has also an AutoRedraw property... Once the Picture control property was set to true everything worked well. The line where I called the function is as below

Call RenderPNG(App.Path & "\Skin\check.png", Form1.Pic(i).hDC, 0, 0)

and I mention that I prefered to include the icon in a picture control because of its drag property within the Form (allowed me to set the function coordinates to zero). Thank you all for your support.

[LaVolpe]

That's what I was trying to say to you. Whatever you are rendering/drawing to should have AutoRedraw=True in this case.

However, I suggest, as a matter of good coding habits, that you do not set AutoRedraw to true on anything unless it is truly necessary. By using AutoRedraw, that object (form, picturebox, usercontrol, etc) is creating a bitmap that uses system resources. The larger the bitmap, the larger amount of resources used.

[Daniel Duta]

By using AutoRedraw, that object (form, picturebox, usercontrol, etc) is creating a bitmap that uses system resources. The larger the bitmap, the larger amount of resources used.

Well, I don't understand this point completely. Actually, I don't understand it at all. Do you mean that whatever I set the AutoRedraw property to true a bitmap somewhere is created ? I don't see any bitmap... Or maybe it is "a matter of maturity" - how Dile used to say Is that bitmap hidden and how large could it be (is related to the object size) ? As a consequence of this effect, will I spend twice as many resources setting AutoDraw to true (that bitmap + my PNG) than in case I would use a simple GIF image ? Thank you.

[LaVolpe]

Think you have now grasped the idea. Generally speaking, if you are not using dozens upon dozens or hundreds of AutoRedraw controls, no harm really. Memory and disk space conservation are not as critical as it was with the older operating systems. So, unless you are planning to use large amounts of controls with AutoRedraw=True, on modern operating systems, you are not likely to encounter runtime errors like "Out of Memory"

[dilettante]

You might first look at AutoRedraw Property, though the remarks there can be a little cryptic to work out. Basically it involves the use of two distinct "canvases" for one Form, PictureBox, etc.

Then maybe read the first few posts in Error 480 - can't create autoredraw image, for example:

> I'm trying to do a simple crop by
> loading a JPG into a picturebox,
> then PaintPicture to a second box
> with size set to the crop region.
>
> Very simple. It works fine but fails
> on certain images. The one picture
> I have that fails is 2500 x 1700 pixels
> (approx.), from a digital camera. And
> other pics saved from the same camera
> seem to fail, even though they open
> fine in IrfanView or PaintShopPro.
>
> Is the picture just too big? Should I do it
> a different way?

VB's back-buffer implementation uses a Device Dependant Bitmap (DDB) to store the image data, which is quite limited in how large it can be made. On older OS' this used to be ~16mb ncompressed data size, on later OS this has been expended but is still quite restrictive.

The image you describe would take just over 16mb uncompressed space at 32-bit so this looks like it's hitting that boundary.

A workaround for this is to use a Device Dependant [he meant Independent here] Bitmap (DIB) and manage the GDI resources yourself, have a look at the DIB article on my site for an example of how to work with them.

Hope this helps,

Mike

[Bonnie West]

Do you mean that whatever I set the AutoRedraw property to true a bitmap somewhere is created ?

According to Creating Persistent Graphics with AutoRedraw:

When the AutoRedraw property of a form is set to True, Visual Basic applies graphics methods to a "canvas" in memory.

... and how large could it be (is related to the object size) ?

From that same topic:

In most cases, the size of this canvas for forms is the size of the screen. If the form’s MaxButton property is False and the border of the form is not sizable, the size of the canvas is the size of the form.


AutoRedraw and Picture Boxes

When the AutoRedraw property of a picture box is set to True, Visual Basic saves only the visible contents of the picture box in memory. This is because the memory canvas used to save the contents of the picture box is the same size as the picture box. Graphics that extend outside the picture box are cropped and never appear later, even if the size of the picture box changes.

[Navion]

AutoRedraw and Picture Boxes

When the AutoRedraw property of a picture box is set to True, Visual Basic saves only the visible contents of the picture box in memory. This is because the memory canvas used to save the contents of the picture box is the same size as the picture box. Graphics that extend outside the picture box are cropped and never appear later, even if the size of the picture box changes.

This is not true.

Microsoft does a terrible job at explaining the dual nature of VB6's picture buffers. There are also a couple of undocumented bugs that will haunt VB6 programmers seeking the large.

When proper methods are followed, VB6 has no problems handling, loading and writing to picture boxes with Autoredraw set to True in excess of 225 Megapixels. Here's one at 211 megapixels on a Vista system 32bits color with the themes on. At these upper limits, if you ran Firefox or RealPlayer before, you're toast. They both leak memory and leave you much less to work with. VB6 does not leak, and on a freshly booted system, you can manage the large images for a while before getting the dreaded 480 error.

Win 10 does a little bit better with large size images, probably because of the absence of themes. At any rate, the maximum size of VB6's picture boxes I believe is 16,327 x 16,327.

My Win 10 system is a rather old clunker with only 2 gig ram, and I have not been able to achieve theoritical maximum size but I could handle 16,203 x 16,325 pictures (249.5 Mpx) with Autoredraw set to True and GDIP+ writing graphics on them.

At these extreme sizes, it is possible to save the picture to a bmp (249.5 Mpx is saved at 766 Mb), but not to load it back.

With proper care, VB6 will handle images larger than the Windows Image Viewer can. VB routinely handles large images in the 150-180 Mpx size without much problems. GDI+ does a good job saving and loading PNG's this size.

[xman2000]

Hi, Navion, what name of software is in this picture above?