Re: Re: RE: DrawGraphics Figure-8 && CPU Strangeness
- To: mathgroup at smc.vnet.net
- Subject: [mg37583] Re: [mg37535] Re: [mg37523] RE: [mg37451] DrawGraphics Figure-8 && CPU Strangeness
- From: John Fultz <jfultz at wolfram.com>
- Date: Tue, 5 Nov 2002 05:03:48 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Yes, it does occur in all Windows OS's (although my experience is that you can squeeze a little more memory out of Windows 9x...my suspicions as to why this is would require a pretty complicated and detailed explanation of the problem, so I won't elaborate here). The limitation is on the memory consumed by the bitmap format we're using, so whether or not you run into the limitation would depend upon how large your graphics are, how many there are, and what color depth your screen is set to (the lower the color depth, the more bitmaps you can create). Most people tend to run out of memory when working with animations that have somewhere around one to two hundred frames (exact number depending upon the above variables). The system is not truly out of memory, but it is out of memory for creating more bitmaps (and thus for rendering more graphics). It is possible to generate animations this large and not run out of memory, though, since the images may not be rendered into bitmaps until you actually *view* the animation (as opposed to simply having generated it).. Sincerely, John Fultz jfultz at wolfram.com User Interface Group Wolfram Research, Inc. > Does this limitation occur in all Windows OS's? I don't seem to have the > problem with my Windows98. But I tend to have only one or two animations > present at a time and I delete them before running others. Bobby seems to > have a problem when running just a single animation of moderate size. > > David Park > djmp at earthlink.net > http://home.earthlink.net/~djmp/ > > From: John Fultz [mailto:jfultz at wolfram.com] To: mathgroup at smc.vnet.net > > On Sat, 2 Nov 2002 03:32:01 -0500 (EST), DrBob wrote: > >I hope Tech Support can help with this. > > > >When I run the Figure-8 animation, I get the "not enough memory to > >display a cell" message and then the "not enough memory to do what > >you asked" message. I have to close and reopen Mathematica to get a > >usable display. > > > >I have this problem with many animations (SpinShow, etc...) -- with > >or without DrawGraphics -- despite having 1024MB of RAM. I'm using > >version 4.2 and WinXP Home, and I had the same problem with version > >4.1. The problem is very consistent, in that each animation either > >always works or never does. If I reduce the number of frames > >enough, the animation works. The Figure-8, for instance, works if I > >change the step size from 2Pi/50 to 8Pi/50. > > > >I have had no memory problems with other applications -- including > >SAS 8.2, Photoshop 7, Prime95, etc. > > > >Help? > > > >Bobby > > > >-----Original Message----- > >From: Steven T. Hatton [mailto:hattons at globalsymmetry.com] To: To: mathgroup at smc.vnet.net > To: mathgroup at smc.vnet.net > >mathgroup at smc.vnet.net Subject: [mg37583] [mg37535] [mg37523] [mg37451] DrawGraphics > >Figure-8 && CPU Strangeness > > > >In a sense this problem gives me an excuse to call attention to one > >of the best uses I've seen a computer put to. The figure-8 > >Animation in David Park's DrawGraphics package is exactly the kind > >of graphical expression of the mathematics of physics which reviel > >more about the situation than pencile and paper lend themselves to. > >(People such as John A. Wheeler, and Hermann Weyl seem to have this > >kind of mechanism build into thier brains, and therefore don't need > >no stinkin' computer.) > > > >This is on SuSE Linux 8.1, P4/w 1 GIG of RAM. > > > >While I was exploring this animation I noticed something rather > >strange about the CPU's behavior. If I open Help Browser -> Add-Ons > >-> DrawGraphics -> Examples -> Figure Eight Animation, the CPU > >utilization is virtually 0. > > > >I evaluate the first cell to load the package and the CPU jumps for > >a second and then settles back down. I then select the remainder of > >the notebook. The CPU utilization remains very low. Then I evaluate > >it. The CPU utilization jumps way up, as is to be expected. The > >animation frames are created, and the animation runs fine. The CPU > >utilization remains very high. > > > >The interesting observation comes when I stop the animation by > >quitting the local kernel. If I select the cell holding the > >graphic, I notice the CPU utilization jups to 98%+-. The kernel > >isn't even running at this time. > >When I say I select the cell holding the graphic, I mean to say I > >select the brace to the right which has the 'foldable' indicator. > >Selecting the inner-most brace does not cause the CPU utilization to > >increase, but selecting any of its parents does. > > > >Can someone explain this? > > > >You can find the DrawGraphics package here: > >http://home.earthlink.net/~djmp/Mathematica.html > > The memory issue arises from the following problem. Mathematica uses > bitmaps to store the rendered images. These bitmaps last the lifetime of > the image itself. Bitmaps are very fast (which makes flipping between > them in animations very fast), but they can consume a lot of memory. > Nonetheless, if you crunch the numbers, you'll find that the bitmaps > cannot account for your system running out of memory. > > Unfortunately, Microsoft placed an undocumented limitation on the kind of > bitmap we chose to use in Mathematica for Windows. This limitation causes > bitmap allocations to fail at a much lower memory threshold then is > available to the virtual memory of modern computers. Since the limitation > was undocumented, it has taken us some time to root out exactly what's > going on and what our options are for proceeding. > > This limitation, incidentally, is a global limitation (it could cause > other applications to claim to run out of memory, too), and the memory > used shows up nowhere in any memory monitoring tool, as it's allocated in > a special area by the system. > > We will be working on improving this for future versions (we have a couple > of viable options). In the mean time, the only way you can work around > this is to limit the memory consumed by bitmaps. You could do this by... > > * Reduce the number of animations per notebook and don't have multiple > notebooks with animations open. > * Reduce the frame in the animation. > * Reduce the size of the graphic in the animation. > * Reduce the color depth of your display. > > I know it's pretty inconvenient for doing this kind of work, but > understand that we weren't exactly happy about it, either, especially > after the extensive amount of time we consumed tracking this down. > > Sincerely, > > John Fultz > jfultz at wolfram.com > User Interface Group > Wolfram Research, Inc. > > >