create_graphics_region@

I am trying to create_graphics_region@ size 4000 x 4600 and the system is reporting an error.

I have plenty of RAM free - Task manager is reporting 700MB

Is there a limit on the size of the graphics region that can be created?

Mark

There is no limit within ClearWin+ and the call with 4000X4600 is OK on my machine. As far as I know the size will not be limited by the amount of RAM available.

Paul

Thanks - I am still having problems. I have noticed that if I reboot the machine and run my application as the first thing then I can create a large region. If I try the same region after having run a number of different applications, even if they have shutdown then the region usually isn't created.

Mark,

Do you use a memory stick or some other removeable device ? I have found this to lock up some (non-clearwin) applications. There could be some system interference from some hardware that does not have the correct driver.

Mark

It sounds like you have enough memory initially but it becomes fragmented after running other applications.

If you are using Windows XP, you could try increasing your available address space from 2GB to 3GB. You do this by adding the /3GB switch to your system boot.ini file. You will also need the latest version of SLINK to take advantage of this extra space. Also, by default, you will only get the extra space if you are not using any of the debugging options but you can change this by using a SLINK command line switch.

Paul, John

Thanks for your replies. I have yet to try the /3GB switch though the removal of USB sticks etc didn't seem to make any difference.

Just as a test ran the following. The largest I can run following bootup is 5101 x 5101 (about 100MBytes of memory) I have tried defragging ram and recovering it using system mechanic but on my system 5101 is still the best I can manage. As before as more applications are opened and closed the total comes down.

! Graphics Test Program TESTGRAPHICS USE MSWIN
INTEGER*4 :: I, i4PCXHandle, i4PCXWidth, i4PCXHeight, i4Err

OPEN (10,FILE='TEST.LOG',STATUS='UNKNOWN')
DO I=1,10000,100
  i4PCXWidth=I
  i4PCXHeight=I
  i4Err=CREATE_GRAPHICS_REGION@(i4PCXHandle,i4PCXWidth, i4PCXHeight)        ! Setup image area
  WRITE (10,*)I, i4Err
  i4Err=Delete_Graphics_Region@(i4PCXHandle)
ENDDO
CLOSE (10)
END

Mark

I ran your code on my machine which has Win2k with 2GB of ram, the largest successful size was 7301 x 7301

I thought that XP was supposed to have superior memory management to win2k 😕

regards John

John

Thanks for that. I tried the test on a number of machines at work

Workstation 1 running Win2K 1GB Ram allowed 4600 Workstation 2 same spec allowed 4000 Workstation 3 running XP 2GB Ram allowed 6800 Workstation 4 same spec allowed 7000 Workstation 5 running XP 64 with 4GB ram went off the scale at 10000

In all cases task manager reported the loss of an appropriate amount of memory but in every case had stacks left.

Regards

Mark

Mark,

I ran your program on an XP os with 1gb. I only got to 4400. I was also running windows task manager, which showed only the smallest increase in memory demand. 4400 x 4400 x 32bit colour is only 74 mb, so the reason for this problem is not insufficient memory. I changed the stack in slink from the default 52mb to 500mb, with no change (assuming this is the stack size reported in the .map file). I'm not sure how to change the heap. I changed your do loop increment from 100 to 500, to see if there was a problem with releasing earlier allocations, but again no change. Maybe Paul can help here as the problem is not a lack of physical memory. There is some other limit applying. Fortunately, for a number of years I have configured graphics regions of 4096 x 3072 and never had this problem. This produces a higher resolution .pcx file that is good for printing. It would be good to know why the limit is being imposed.

It seems as though you are creating the large graphics region in order to save it as a PCX - presumably to print it later, as 4000x4000 is a bit large for the sort of displays I can afford!

Have you thought of using a vector file format instead? There is something called SVG (scaleable vector graphics) that is importable into Adobe Illustrator and CorelDRAW, or can be viewed in a web browser if you have the Adobe or Corel viewer installed (and presumably by other applications I don't know about). The rules for creating SVG files are similar to those you may be familiar with in HTML ... in fact, SVG is a similar text-based 'markup language'. Your image file is then likely to be more like 70kb than 70 Mb. Most of the 'tags' in SVG are very similar in function to the graphics commands in FTN95/Clearwin, and I was able to hack a set of subroutines over an hour or so. I suggest Googling for SVG, or if you want my routines, e mail me at Kingston.ac.uk (I am on the staff list as e.bromhead). Apologies in advance, the routines aren't elegant, but they are straightforward.

I used HP graphics language as a vector metafile type for about 20 years, but it thinks in terms of pens and outlines, not RGB and filled areas, and definitely knows nowt about fonts, but SVG does, so I am a convert.

Eddie

Hi Eddie,

Sorry to disagree a little with you, but your description of HPGL is correct only for the original (very old) monochrome version.

HPGL/2 which supports colour filling using any RGB combination and fonts has been around for a very long time, and works extremely well.

I used Salford FTN77 in a about 1992 to read plot files produced by Catia V3 or V4 with a '.gl' extension (which were in fact in HPGL/2 format) for viewing and subseqent printing using PC's. I also used the format for improved quality printing of coloured stress contour plots using HP printers where I could utilise the full resolution of the printers.

AutoCad PLT files use the HPGL/2 or the HP-RTL format (HPGL with raster data), so it's still an important format.

But, yes you are correct, very large bitmaps are no joke, and most applications (paintbrush, photoeditor....) simply fail to import them, vector graphics are the best (provided you have a suitable printer!)

cheers John

Hi John,

OK, I give in. I've got Addison-Wesley's 'The HPGL/2 Reference Guide' and their 'HPGL/2 and HP RTL Reference Guide Third Edition', and they aren't very readable - on a par with a Sanskrit to Egyptian Hieroglyphics dictionary crossed with the Shanghai phone directory. Once you get beyond the simple vector stage with 'pens', the descriptions are simply incomprehensible.

Oddly, I used HPGL as a metafile format for much the same thing as you, starting with my first 'Apricot' in 1983-4. Back then, HPGL definitely lacked good area fills. I later tried the algorithms in Angell & Griffith, but gave up. I've been using Fortran-drawn outlines, with Corel-DRAWn infills for a long time. In recent months I have become aware of SVG, and I urge you to take a look. It has more readability than HPGL (even of the simplest kind), and is easy to write.

As well as HPGL, I've had a go with PostScript, and dabbled with AutoCAD DXF files (there are codes for both in Fortran on the web), written GEM files, and saved to MSP, PCX and BMP, but I liked none of them - but I find SVG 'hits the spot' 😄 😄 . Give it a try!

As for the original post, a 16 million pixel PCX file is a rather unmanageable beast ...

Eddie

Hi Eddie,

Oh dear, I based my entire HPGL/2 programming on a two page summary in the appendix of a HP pjetXL300 manual !

Very simple to follow, for instance in this extract:-

NP 254; CR 0,100,0,100,0,100; PC 1, 0, 0, 0; PC 2,100, 0, 0; PC 3, 0,100, 0;

NP = number of pen colours to be defined CR = colour intensity range for red, green and blue (all set to a 0 to 100) PC = pen colour rgb definition (here pen 1 = black, 2 = red , 3 = green)

And this extract fills in a polygon with colour definition 16 :-

SP 16; PU3226,1725;PM0; PU3226,1555; PU3328,1505; PU3328,1676; PU3226,1725; PM2;FP;

where PM0 starts the perimeter definition and PM2 finishes it, whilst FP fills it. The PU is obviously the old pen up command. There is a little more to set the font and place text, but nothing difficult.

I had a quick google on SVG, and saw that it is XML based, and that Adobe intend to discontinue developing it. A user community backlash then stopped Adobe from carrying out their initial intention of a complete discontinuation. A bit of an odd ball really since it won't displace HPGL/2 as a printer language, and for web browsers most developers will want dynamic 3D model displays using 3D XML (which is slowly replacing VRML as the format of choice). VRML being facet based is very easy to program, I had a look at 3D XML but didn't find it so easy to understand, but that's just my preference, and I've digressed probably too much!

John

John & Eddie,

I use a depth based pixel colouring routine which produces good quality graphics for printing, so old vector and hpgl approaches are not as easy to use.

I am still puzzled as to why we get the error message for create_graphics_region. My previous post estimated that the maximum memory allocation was only 74mb so is there a reason for this very low limit, certainly much lower than available memory? May be Paul may have some idea ?

Regards

John Campbell

Hi John and John,

I digressed into a private conversation with John H .... to whom I must say that he has the commands - I went straight from a real plotter with physical pens to the Adisson Wesley book, and missed this halfway house. My subset of HPGL was good enough for what I wanted - right up until late last year!

For John C, I agree that vector-based graphics are never going to be a proper means for colouring individual pixels, it was only a suggestion that the OP might find it useful.

As for Adobe discontinuing their support for SVG (John H), I note that both Adobe Illustrator and Corel DRAW both can read and write SVG files as a native graphics format, but Corel DRAW has to 'import' HPGL .

I tried John C's graphics program - my, you were lucky that your 4:3 4096*3072 fell just below the lock-out point. I got to 4360x4360 (going up one at a time) before my 1Gb XP machine returned 0. I tried it with your 4:3 aspect ratio, and there is something about the memory block size. I would bet that this is set somewhere - either in the Registry explicitly, or derived from one's total RAM size. Clearly, it is bigger if you have more RAM. Microsoft often put in such arbitrary limits - for example on maximum disk size or maximum file size. I was reminded that I originally upgraded to XP to overcome a 4Gb file size limit ... about 20 minutes' worth of video from my camcorder which sported 1 hour tapes. However, my exploration of the Registry was not very exhaustive - I gave up at 'Memory Management' in the Registry, when I discovered that main memory is paged.

Presumably 'create_graphics_region' uses the service that asks for a block of memory in a single page, and baulks when it is told it can't have that much. It would make sense for the page size to increase with available memory. My money is therefore on it being a limit in Windows, with XP allegedly having (as John H put it) 'superior memory management to win2k' - which it would have if it were more granular.

By the way, is it 32bit or 24bit colour in a create-graphics_region? If the latter, then the critical block size is rather less than 64Mb, which looks like one of those MS limits, 70+ would be an odd choice.

Eddie

Eddie,

You may be right with the 24 bit colour. Certainly rgb@ returns a 24 bit value range. Clearwin+ may use a 3 byte storage for each pixel, although I've never tried it. (May be I should define a type colour variable using rgb as integer*1, for my screen buffer, although I've never considered this memory to take a lot.)

One interesting thing I noticed when running the test program and monitoring with Task Manager, was that the memory demand for the program never grew by very much at all, but that may relate to the memory not being taken by the program until it is actually used, rather than only being allocated.

It all sounds like a limit of a 64k memory packet on my system, but how do the other tests reported get more than this apparent 64k limit?

( On the issue of file size, I've certainly created fixed length record fortran files up to 8gb on w2k and XP (my software limit) and I think Salford can create much larger. )

John C.

John,

Perhaps the memory packet is larger on a 2Gb system, or there may be a finite number of them, which is how they come to be odd-ish sizes (and this would account for the 2Gb systems permitting more than twice as big, as the extra Gb is free from OS encumbrances compared to the first Gb.

All speculation, of course. The proof of this hypothesis would be to turn off virtual memory. I may experiment on a spare machine tonight.

Eddie

John, Eddie, others,

I, too, have experienced the same issue in trying to create large graphics regions. Have you by chance isolated the particular system setting that might allow larger regions?

I have also experienced problems with calls to GET_SCREEN_DIB@ after successfully creating a large graphics region. When the size of the graphics region approaches the upper limit, GET_SCREEN_DIB@ returns 0.

Interestingly, my development machine (WinXP with 512MB RAM) allows larger regions than other machines with more memory! So, size of region allowed is not necessarily proportional to amount of RAM (as had been suggested by John's tests). As discussed, there is something else in play.

[Note: I edited this post on 19 Mar 2007 to more accurately reflect my situation after further diagnosis.]

Thanks, David Heise