[ Show ]
[ Shrink ]
Programming and providing support for this service has been a labor
of love since 1997. We are one of the few services online who values our users'
privacy, and have never sold your information. We have even fought hard to defend your
privacy in legal cases; however, we've done it with almost no financial support -- paying out of pocket
to continue providing the service. Due to the issues imposed on us by advertisers, we
also stopped hosting most ads on the forums many years ago. We hope you appreciate our efforts.
Show your support by donating any amount. (Note: We are still technically a for-profit company, so your
contribution is not tax-deductible.)
Donate to VoyForums (PayPal):
[ Next Thread |
Previous Thread |
Next Message |
Previous Message ]
Date Posted: 17:59:01 09/11/00 Mon
Subject: Re: Big black square
In reply to:
's message, "Re: Big black square" on 10:54:52 09/08/00 Fri
Here is the result of some testing I have done with the large image you have sent me. For printing, I also thing, this is a limitation of the API calls.
I have done some testing with the images you have sent me.
With scan011.tif I was able to open it, but it was slow loading. Usually
windows cannot handle images of this size (14400x9672). I'm quite sure
Win95/98, even NT the windows API calls will fail with such an image. My
main machine is a laptop with Windows 2000 and 128MB of ram and a basic
ATI video card with 8 megs of ram, and I successfully loaded the
image. When the image was loaded, the task manager indicated a memory
consumption of 48MB. I think for these kinds of images you need windows
2000, with enough ram and video memory.
The "black rectangle" is how windows behaves when it cannot create a
graphic of a specific size and color type. There has been an experiment
in in EFG's graphics lab,
<a rel=nofollow target=_blank href="http://www.efg2.com/Lab/Graphics/VeryLargeBitmap.htm">http://www.efg2.com/Lab/Graphics/VeryLargeBitmap.htm</a>
Unfortunately, I cannot be of more help on this. Some high end graphic
libraries, divide an image into tiles when displaying it on screen, but
it is more complex and Envision does not support that.
> > Hi Andy,
> > I tried to reproduce the problem without success.
> > the zoom value is changed in the TImageScrollBox, the
> > TResizeTransform is used. This in turn, calls the
> > windows API function,
> > SetStretchBltMode, to resize the graphic. I would
> > think that with a certain lower zoom threshold the
> > function does not work. This is probably dependent on
> > video card/driver/OS, just like with the limitation
> > with large images.
> > Best regards,
> > Michel
> In a mean time I have discovered another problem:
> nothing is coming out of the printer with the same
> file, when zoomed to extents (at 1280x960 screen size
> zoom is about 5%), with larger zoom factor printing is
> done ok. It means that, for some reasons, there is no
> information to be reproduced is received by the
> StretchDraw function. Any ideas?
Next Thread |
Previous Thread |
Next Message |
[ Contact Forum Admin ]
Forum timezone: GMT-5|
VF Version: 3.00b, ConfDB:
VoyForums(tm) is a Free Service from Voyager Info-Systems.
Copyright © 1998-2019 Voyager Info-Systems. All Rights Reserved.