forums.silverfrost.com

[sparge]

I've been using %gr for a few years now and I'm starting to realise that I still don't understand the updating process. I regularly want to copy an image to a %gr region and perform analysis on it, as a callback function - the analysis takes long enough that I want to update the %gr region before the analysis is carried out. But I can't get it to happen.

The manual says that, under normal circumstances, graphics are not updated until the app is idle. My experience is that graphics are not updated until the app is idle under all circumstances, no matter what documented overrides I try and use.

I'm using direct manipulation of the graphics surface, using a pointer to a graphics buffer, as described in the manual.

If I:

- window_update@ the pointer immediately after this manipulation, update occurs but only when the app is idle
- instead, call perform_graphics_update@ immediately after this manipulation, no update occurs at all
- window_update@ the pointer AND call perform_graphics_update@ immediately after this manipulation, update occurs but only when the app is idle

I have also tried using the %lw code in the code for the window that contains the %gr region, reasoning that this might "free" ClearWin+ to update graphics while my code goes about the rest of its business downstream in the callback. But it makes no difference.

My conclusion is window_update@ing the pointer is necessary for updating to occur at all, and that perform_graphics_update@ doesn't do what it is supposed to.

Please, is it actually possible to enforce graphics update "on demand"? Hopefully,

Andy

[PaulLaidler]

Andy

I am not sure about this but you may be able to trigger an update by making a prior call of the form

hdc = clearwin_info@("GRAPHICS_HDC")

immediately before the update action.

Please let me know if this works or not.

[sparge]

Hi Paul,

No, I can't get it to work. I have now written sample code to try and illustrate the problem, and it behaves correctly ( . So I need to figure out the important difference from real code. Watch this space.

Andy

[sparge]

I haven't yet managed to get sample code that illustrates the one I am having, but here is some sample code that illustrates a problem that is intimately connected. When the Go button is pressed, a chain of two callbacks are invoked. It is intended that the first one sets up the %gr region, using %sc, and the second one analyses it. What actually happens is that %sc does not happen until after the second callback, hence the analysis gets the wrong answer.

This structure mirrors my real code. I can see now why the graphics update appears to always happen at the last minute - it's actually the setting up of the graphics array that happens at the last minute, immediately followed by the update. What I'm having rather more trouble figuring out is how I'm getting sensible answers from the image analysis.

program grupdate
use callbacks
integer iomain
states = ''
count = 0
iomain = winio@ ('%lw&', cvmain)
iomain = winio@ ('%`rs%ff%nl&', states)
iomain = winio@ ('%cn%^bt[Go!]&', '+', setgra, anagra)
iomain = winio@ ('%taCount: %`rd&', count)
iomain = winio@ ('%ff%nl%fr', 600, 600)
stop
end program grupdate

module callbacks
character (len = 30) states
integer cvmain, iograp, ptrgra, grawid, i, j, offi, offj, ptr, rowlen, count, lens
contains

integer function setgra ()
setgra = 2
lens = len_trim (states)
states (lens + 1: lens + 6) = 'setgra'
call window_update@ (states)

grawid = 400
iograp = winio@ ('%gr[user_surface]&', grawid, grawid, ptrgra)
iograp = winio@ ('%sc&', filgra)
iograp = winio@ ('%aw', cvmain)
return
end function setgra

integer function filgra ()
filgra = 2
lens = len_trim (states)
states (lens + 1: lens + 6) = 'filgra'
call window_update@ (states)
rowlen = ls (rs (3*grawid + 3, 2), 2)
offj = 0
do 20 j = 1, grawid
offi = 0
do 10 i = 1, grawid
ptr = ptrgra + offj + offi
ccore1 (ptr) = char (mod (i + j, 255))
ccore1 (ptr + 1) = char (mod (i - j, 255))
ccore1 (ptr + 2) = char (mod (i*j, 255))
offi = offi + 3
10 continue
offj = offj + rowlen
20 continue
call window_update@ (ptrgra)
return
end function filgra

integer function anagra ()
anagra = 2
lens = len_trim (states)
states (lens + 1: lens + 6) = 'anagra'
call window_update@ (states)
count = 0
offj = 0
do 40 j = 1, grawid
offi = 0
do 30 i = 1, grawid
ptr = ptrgra + offj + offi
if (ccore1 (ptr) .eq. '#') count = count + 1
if (ccore1 (ptr + 1) .eq. '#') count = count + 1
if (ccore1 (ptr + 2) .eq. '#') count = count + 1
offi = offi + 3
30 continue
offj = offj + rowlen
40 continue
call window_update@ (count)
return
end function anagra

end module callbacks

[PaulLaidler]

Andy

Perhaps you need to move the call to alagra from the main program to

iograp = winio@ ('%sc&', '+', filgra, anagra)

Also, when I first ran the program, rowlen was undefined when first encountered.

[sparge]

[small]Paul Laidler wrote:[/small]
Perhaps you need to move the call to alagra from the main program to

iograp = winio@ ('%sc&', '+', filgra, anagra)

Also, when I first ran the program, rowlen was undefined when first encountered

Paul, the second is a manifestation of the first - if the routines get called in the intended order, rowlen is calculated before it is used. I took the reverse approach and eliminated the %sc callback, moving it into the main program. Everything is working fine now.