Sudden Death

Guys,

I need some smart ideas about a phenomenon with a ClearWin program.

Basically, my program is a standard Windows application with a lot of mouse interactions, screen refreshing (updateing of window etc.) and scrolling opererations of the active window. Everything seems to work fine. But sometimes, not expected obviously, a 'non-reproducable' error occurs:a sudden death - the program is disappearing without any system generated error message.

This error seems to have soemthing to do with a certain 'stress factor' because it occurs mostly when windows updates are required (e.g. scrolling operations). I tried to increase the heap stack and fiddled around with some compiler options with no real improvement. I guess it's a basic issue of Windows programs with ClearWin.

Has somebody made similar observations? If yes what has been the workaround? Any suggestion is highly appreciated.

Regards WoSl

WoSl,

Yes I have, and they can be very difficult to track down.

With the debugger running, I have managed to track down one major cause of program crashes and this is the error:-

Error 410: A function called from within an I/O statement has itself performed I/O

It is very also very difficult to prevent this error, but since it occured mostly during graphics repainting (in both GDI and OpenGL modes), requested by a callback after a 'dirty' or 'resize' reason was detected when text strings were being prepared to be placed in the graphics area as annotations, I put a block on (or flag) to prevent text creation whilst any graphics manipulation was taking place and when temporary dialog boxes were being displayed. For the most part this has stopped the unexplained crashes. But I never really understood the reason for them.

I hope this helps (a little).

I have found a similar problem when I have multiple interupts being generated and not being responded to quickly enough, for example multiple mouse clicks or movements occuring before the response to the first click has been completed. I would describe this as a multi-thread response, although I may not be technically correct.

To overcome the problem, I have had to speed up the program response so the backlog of interrupts does not develop.

This is especially the case for mouse movement interrupts. I fixed this by :-

1. tracking the distance the mouse has moved and not responding till it has moved (say) 50 pixels. Certainly trying to quickly filter out unnecessary interrupts fixes a lot of the problem I had.
2. speeding up the code that responds to a click or move. It is not too difficult, as if there are say 100 interupts per second, then you nedd to be able to complete a response in .01 of a second, or 30,000,000 clock cycles for a 3ghz machine.
3. If you are refreshing the screen many times in a single response, this can cause performance problems. Limit the number of times you use update_window@.
4. compiling with /opt or /debug, rather than /check will also improve performance. You could try /timing to see where all the time is being used.

First, you could simplify your program response to interrupts, to see if this is the source of your problem.

good luck

Mmmm... I'm not sure if this may help: Ask for mouse activity and do nothing until a mouse button was released or until the mouse was really moved.

For instance, you like to start an action with the left mouse button:

string = clearwin_string@('call_back_reason')

if (string .eq. 'MOUSE_LEFT_CLICK') then <just wait...> else if (string .eq. 'MOUSE_LEFT_RELEASE') then <now start the action...> end if

or, you want to use any mouse movements:

x = clearwin_info@('GRAPHICS_MOUSE_X') y = clearwin_info@('GRAPHICS_MOUSE_Y')

<store these values for the first time and compare them with the actual ones in a small loop. Continue only if there are differences in the values>

Regards Wilfried

First, many thankx for your thoughts - very helpful.

Since a while I try to 'produce' the error. It seems that my scrolling operations are one reason for the crashes.

It works with scroll bar feature %vx and %hx.

      i=winio@ ('%^vx&',ivstep,ivmaxx,ivcur,ScrollGrX)
      i=winio@ ('%^hx&',ihstep,ihmaxx,ihcur,ScrollGrX)

The call back function ScrollGrX does simply this:

1. calculates the offsets in x and y in pixels
2. redraws the complete window with the x/y-offsets using standard drawing routines (lines, text and fill area) which could take some time depending on the complexity of the picture.

Clicking on the scroll bars too fast results (after a while) in the sudden death. The window updates seem to occur with not sufficient performance.

Introduction of time delays to provide more time to redraw the windows between two mouse clicks seems to me not the appropriate solution. This would increase customer frustration because of poor performance.

I guess window scrolling via copying bitmaps could be better, right? Has soembody some code sample available how this would work?

Let me know your thoughts. Any suggestion is appreciated.

WoSl

Wosl,

As you have suggested, when scrolling the graphics screen, or draging the image around the screen with the mouse, I do first take a bit-map image of the screen and simply paint the moved screen using copy_graphics_region@. In my solution, the parts that were previously not visable remain unpainted. When I get the required position, I release the mouse and fully redraw the image. Not the best solution, but it works for me. This saves on many re-draws of the screen.

An improved solution would be to initially paint the picture to a larger vitrual screen, then use this for copying from when draging around the screen. The size of the virtual screen would depend on how much zoom has been selected, but would maximise at 3 times the visable screen. I'll put this on my to-do list !

I use a vitrtual screen in other parts of my graphics program, especially for producing higher resolution .pcx files, so I can report that this is all readily achieved in a %gr window.

John

This is general suggestion is this scrolling, panning, moving or whatever when callback is involved.

I hope all you when you scroll/pan/move do prevent the callback function to execute before it did finish previous its job ? Slightest mouse move can produce hundreds of calls which start to run over each other.

You can do that by declaring some global integer or logical variable (or declare it in common block in fortran-77 style of programming) specific for given callback which changes its value only at the end of callback signaling that the job is done. The first line in the callback function checks the state of this variable

Dan makes the eminently sensible suggestion that you consider rejecting user input while screen updating is in progress. This is a method as old as Windows and the Mac, and the egg-timer cursor was invented to pacify the impatient user. An equally valid approach is not to update the screen while user input is in progress. This requires keeping an eye on how long has elapsed since the lass key press or mouse move. Judicious use of the two when most appropriate is probably the answer. It is probably a good idea to time the screen redraws for complicated cases to see what the scale of the problem is, and whether simply the march of technology will make the problem go away. For example, I used to watch CorelDRAW laboriously update the screen on my 286, but now I am never conscious of refresh being anything but instant. On the other hand, I've never had a blue screen of death or instant exit from my program that wasn't ultimately traceable to a simple (but often hard to detect) error in my fortran. If it was my problem, I would be looking (first) for a callback function that in certain cases had an undefined return code. Eddie

Thank you for all the helpful hints. Yes, I agree I need to focus on refreshing frequency of the screen. I'll work through the code to trace the refreshing cycles.

The first change I did was to apply the off-screen painting similar to the following code fragment:

         i=create_graphics_region@ (ihnd_offscr,g_width,g_depth)

        ... paint operation ...

         i=copy_graphics_region@ (ihnd_grap,  0,0,g_width,g_depth,
     *                           ihnd_offscr,0,0,g_width,g_depth,
     *                           'SRCCOPY')
         i=delete_graphics_region@ (ihnd_offscr)
         i=select_graphics_objectq (ihnd_grap)

This works fine, but after some user interaction, unfortunetely, the program stops (in debug mode) the with following message in the 'call stack/status' window:

'Windows resources exhausted - program terminated'

Any idea? I will further look to your posts in order to get an idea what is wrong.

Thank you in advance WoSl

WoSl,

SRCCOPY is an integer not string field. I have it defined as

  integer*4, parameter :: SRCCOPY = Z'cc0020'    ! copy all

Some others are defined in the ftn95 help. I'm not sure where all possible values for COPY_MODE are defined.

I would have expected that your error relating to resources exhausted could relate to delete_graphics_region@. You could try not deleting it, but reusing the same tempory area many times, especially if the dimensions do not change. I think clear_screen@ can be used to clear the region for each new redraw.

John

John,

Sure, SRCCOPY is not a character but an integer. FTN95 provided to me a nice message on this. :x

I guess the idea not to loop through

create_graphics_region@
...
delete_graphics_region@

for all graphics updates is a very good hint. I can change that easily in my code and test it. Secondly, I plan to use the scroll capability of the copy_graphics_region@ function. Currently, I redraw the screen everytime when just a scroll operation occurs. This seems to me not very clever (reading all comments carefully). Third, I need to trace my mouse operations in respect to do nothing until a mouse button was released and the mouse was really moved (Wilfried's comment).

So far, I've enough to do now. Thank you all for sharing your thoughts with me. Any further suggestion is obviously appreciated.

Regards WoSl