Have I Hit The Wall With Pixmaps? [VW 7.4 of 5 December 2005] on XP

From http://idlastro.gsfc.nasa.gov/idl_html_help/WINDOW.html,

"On Microsoft Windows systems, the number of pixmap windows that can be
created is limited by system GDI resources. The number of pixmap windows
IDL can create is constrained by the total amount of GDI memory, the
amount of GDI memory used by other applications, and the size of the IDL
pixmap windows."

From http://doc.trolltech.com/3.3/qpixmap.html,

"Note regarding Windows 95 and 98: on Windows 9x the system crashes if
you create more than about 1000 pixmaps, independent of the size of the
pixmaps or installed RAM. Windows NT-systems (including 2000, XP and
following versions) do not have the same limitation, but depending on
the graphics equipment the system will fail to allocate pixmap objects
at some point (due to system running out of GDI resources)."

Hope this helps,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Stewart MacLean [mailto:[hidden email]]
Sent: Monday, September 11, 2006 1:15 PM
To: [hidden email]
Subject: Have I Hit The Wall With Pixmaps? [VW 7.4 of 5 December 2005]
on XP

Hi Smalltalkers,
 
I'm running into a problem with allocation of Pixmaps, and I'm wondering
if I've reached some resource limitation, or if I can work my way around
it somehow (by allocating more?).
 
I've developed a printing setup whereby I "print" to Pixmaps for screen
display. This works fine until I try to display more than a few "pages".
 
This seems to have been a problem before, as there are similar messages
in the archive.
 
If I run (1 to: 100000) collect: [:i | Transcript cr; show: I
printString. Pixmap extent: 1@1] (thanks to John Brant)
 
it gets to around 9,100 before going into spasms. If I run this after
getting the said walkback, it goes directly into spasm.
 
I my case, I don't think it's the actual number of handles that is the
problem, but maybe the actual size of the pixmaps, so I may be running
out of memory (although I have 1GB of physical memory).
 
Is there any way I can increase the available memory for pixmaps? (or
any other way around this show stopper...)
 
Thanks,
 
Stewart
 
 
Unhandled exception: a primitive has failed
HandleRegistry>>evaluateWithFullProtection:
HandleRegistry>>registerValueOf:
Pixmap class(DisplaySurface class)>>registerValueOf:
optimized [] in DisplaySurface>>handleValue:
BlockClosure>>ifCurtailed:
Pixmap(DisplaySurface)>>handleValue:
Pixmap class(UnmappableSurface class)>>extent:on:initialize:
Pixmap class(UnmappableSurface class)>>extent:on:
Pixmap class(UnmappableSurface class)>>extent:
ToDisplayDocumentRenderer>>endPage
ToDisplayDocumentRenderer>>newPage
ToDisplayDocumentRenderer(DocumentRenderer)>>addTable:
optimized [] in Document>>render:
OrderedCollection>>do:
GeneralDocument(Document)>>render:
ToDisplayDocumentRenderer>>render:
ToDisplayDocumentRenderer class>>render:icon:
----------------------------------------------------------------------
 

Stewart,
Could you specify your problem better ? What are you trying to accomplish ?

if you don't need to display all of those pixmaps in the same time you
can pre allocate few and reuse them as needed. like you turn the pages
in the book.

Or you can create one very big pixmap and display few of your pictures
on it.

Just my 2c.

I tried both techniques in the past an both did work BTW

--Mark Pirogovsky

Stewart MacLean wrote:

I am a bit late with this answer, but you are probably running out of
GDI handlers. The default number is often set to 10000 on Windows.

If you do a garbage collect, lets say, every 1000 created Pixmap, you
should be fine. This of course leads me to ask whether garbage
collection should be forced to start if "many" GDI handlers are in
use.

(I am having a problem in our system when we run automated tests. We
iterate through UIs and run out of GDI handlers after a while. But in
my case a garbage collection does not work. It seems like the GDI
handlers are held by objects that are not released for garbage
collection.)

Read more about GDI handlers here:
http://msdn.microsoft.com/en-us/library/ms724291(v=vs.85).aspx


Runar Jordahl
http://blog.epigent.com/


2006/9/11 Stewart MacLean <[hidden email]>:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You should explicitly #close a Pixmap when you have finished with it.
Otherwise its handle only gets released back to the OS when it is
garbage collected, and after that finalized. If your app is busy, e.g.
printing many pages, and you don't explicitly garbage collect, you can
run out of OS resources because the garbage collection idle loop never
kicks in. (I'm not sure whether an explicit gc would also force
finalization.)

It's more likely that you'll run out of graphics memory than OS graphics
handles. There are limits on the largest byte size of Pixmap that the OS
will return, and on the total byte size of Pixmaps. The Windows VM
always requires Pixmaps to be in graphics RAM, so it's very easy to run
out if you have a non-gaming PC - e.g. we have desktops and laptops with
only 64MB. Laptop graphics drivers seem particularly bad: perhaps the
graphics memory gets fragmented, like with any allocation, and it can't
return a sequential area big enough to match the request.

Trying to handle errors like this is a pain, because the error just says
"primitiveFailed". When we run out of normal memory, VW automatically
garbage collects and retries the allocation. Since running out of
graphics memory is actually more common these days, I think VW should
handle it in a similar way, garbage collecting and forcing finalization.
If possible, it should fall back to using GDI resources based in normal
memory - it seems likely that the decision to force the use of graphics
RAM was made long ago and hasn't been revisited. Google "Limits on size
of bitmap from CreateCompatibleBitmap()" for some discussion on this -
my recollection is that VW uses DDBs (DeviceDependentBitmaps), which are
always on the graphics card's memory, whereas if it asked for DIBs it's
up to the driver whether to allocate from the faster graphics card
memory or more abundant main memory.

Steve
around after (or ---------------------------------------------------------------------
> -
> >
> >
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>Google "Limits on size
>of bitmap from CreateCompatibleBitmap()" for some discussion on this -
>my recollection is that VW uses DDBs (DeviceDependentBitmaps), which are
>always on the graphics card's memory, whereas if it asked for DIBs it's
>up to the driver whether to allocate from the faster graphics card
>memory or more abundant main memory.

What is the benefit of using DDBs?
>From my (granted limited) experience, shouldnt the OS be responsible for allocation memory for graphics?
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>I am a bit late with this answer, but you are probably running out of
>GDI handlers. The default number is often set to 10000 on Windows.

You can use the taskmanager to show a column for GDI Objects.
I used to always keep an eye on this when I did graphics stuff:

open taskmanager (remember GDI objects) open GUI, do stuff, close GUI (look at GDI Objects again).
If everything went right, the number goes down again to the original number.
If not, then some GDI object is not released and sooner or later, things will blow up on you.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc