Oh, additional info. After sending this email, I clicked on the close window button of the J Session and now J is "Not Responding". I loaded the task manager and its using 50% of my CPU resources and 23MB of memory. This unit is a Lenovo T61 with a Core 2 Duo 2.0Ghz CPU. So the 50% is technically saying that J is tying up CPU0 and I am now only using CPU1? :)
I wonder what's happening. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alex Rufon Sent: Wednesday, September 16, 2009 5:01 PM To: Programming forum Subject: Re: [Jprogramming] switching between windows and opengl Hi Brian, I tried your script on WindowsXP 32bit with J602a. After type "try 100", I got the following result: +-+---------+ |0|318839029| +-+---------+ And pressing the arrow keys, i, o and the F5 key ... the image on the J isigraph form kept changing appropriately. r/Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Brian Schott Sent: Wednesday, September 16, 2009 3:29 PM To: [email protected] Subject: [Jprogramming] switching between windows and opengl This question has been plaguing me for some time as you can see from the date on the link below. I have been trying to revise my turtle graphics simulation with some frustration over losing the isigraph's handle. The problem I am having may be related to the issue explained by Eric Iverson in the following quote taken from the following link, but I cannot be sure because I even lose the handle with a single instruction if the instruction contains a for. loop that is long enough. http://www.jsoftware.com/pipermail/beta/2006-June/001297.html "gl2 and gl3 commands have an implicit target isigraph. When the host calls the paint handler the correct isigraph is automatically selected as the target. If you are going to be switching between windows and calling the paint handler manually then you have to make sure the isigraph is selected. The easiest way to do this is to get its handle when it is created and then do a glsel handle as required." The verb "try" is basically a for. loop. try =: monad define for. i. y do. g...@pickone@? 144 end. ) go =: monad define GS_CLEARCOLOR=: y paint'' ) On my Mac, if I load the script below and then in the .ijx window type "try 100", then I will have lost the handle of the graphic window. Otoh, if I type "try 9" (a smaller iteration count of 9), then I do not lose the handle unless I have been issuing lots of "try ..."'s in one session -- in that case, because of some cumulative effect, I sometimes begin to lose the handle, too. This may be a Java issue or a Mac issue, not a Windows issue. I cannot test in the Windows environment. The way I know I have lost the graphics handle is that I cannot use the keystroke commands like F5, F6, and arrow keys to reorient the graphic window. Another indication is that I cannot press the Esc key to close the graphics window, even though the mouse can click on the close button to close the graphic window. I am listing the entire script below. It contains two versions of the "paint" verb: a very simple version that does not produce any graphic object, and a slightly more detailed "paint" verb. Both paint's produce the problem I have mentioned, the simpler paint just takes longer to lose its handle. The script is basically a slightly embellished version of the systems standalone gldemo script at ~system/examples/graphics/opengl/demo/glviews.ijs Please copy and paste the script below into an ijs window and then press Ctrl-W to load it. Then type "try 100" into the ijx window and watch the background color change (100 times). Then try some keyboard alterations, like press F5 or i or an arrow key. If you see the graphic change, then your system has not (yet?) lost graphics handle, and you might increase 100 to 300, for example, and retry the keyboard alterations. (Btw, you will only see the graphic image change with the second "paint", because there is nothing to change with the first "paint". The only way I know to test the first "paint" is to try to close the graphics window with a keystroke instead of the mouse.) So.... my questions are: Is this a Mac/Java problem only? Is this problem correctable with Eric's recommendation above, and if so, how can his recommendation be added to my script? Is this a bug? Thanks, in advance, -- (B=) **************************************************** require 'opengl' NB. cocurrent 'gldemo' coinsert 'jzopenglutil' gsetdefaults'' OPENGL=: 0 : 0 pc opengl; xywh 0 0 200 150;cc g isigraph opengl rightmove bottommove; pas 0 0; rem form end; ) opengl_run=: 3 : 0 wd OPENGL ogl=: '' conew 'jzopengl' wd'pshow;' ) opengl_close=: 3 : 0 destroy__ogl'' ogl=: '' wd 'pclose' ) opengl_cancel=: opengl_close NB. ========================================================= NB. cups surface - colored by height j=. steps _2.4 2.4 35 f=. (5: * ] % ^...@+&*:)"0/~ CUPS=: 1.4*gsfit11 gsmakexyz (];];f) j j=. (1r4"_ ,. |. ,. ]) _2}.8}. gsint01 16 CUPCLR=: j gshue gsfit01 {:"1 CUPS ".COLORTABLE gsetdefaults'' GS_CLEARCOLOR=: IVORY pickone =: COLORTABLE&(13 : '".>{.;:y{x') try =: monad define for. i. y do. g...@pickone@? 144 end. ) go =: monad define GS_CLEARCOLOR=: y paint'' ) paint=: 3 : 0 NB. even this paint fails with "try 100" NB. glsel 'g' wd'psel opengl;pactive' gsinit '' gsclearcolor GS_CLEARCOLOR gsfini'' ) paint=: 3 : 0 NB. glsel 'g' wd'psel opengl;pactive' if. gsinit GS_LIGHT do. gsdrawsurface2 makelist 1 CUPS;CUPCLR end. gsclearcolor GS_CLEARCOLOR glCallList 1 gsfini'' ) NB. ========================================================= opengl_g_paint=: paint opengl_g_char=: gschar opengl_default=: gsdefault NB. ========================================================= opengl_run'' ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
