Author |
Topic: #graphicHandle "discard" (Read 1217 times) |
|
Rod
Full Member
member is offline
Gender: 
Posts: 110
|
 |
Re: #graphicHandle "discard"
« Reply #16 on: Jun 3rd, 2017, 06:41am » |
|
The first example discard ; redraw can be perfectly valid. It erases the current segment contents and redraws the previously fluhed segments. More code would have made that clear.
The second example flush ; discard of course achieves nothing as the current segment has just been flushed and preserved.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: #graphicHandle "discard"
« Reply #17 on: Jun 3rd, 2017, 07:15am » |
|
on Jun 3rd, 2017, 06:41am, Rod wrote:| The first example discard ; redraw can be perfectly valid |
|
Not according to the LB docs, and not according to my own tests. To reiterate, the LB docs say of redraw: "Any items drawn since the last flush will not be redrawn either, and will be lost". Note my emphasis of "and will be lost" which I interpret as meaning that any items drawn since the last flush are discarded as a side-effect of redraw, making the explicit discard superfluous.
I have attempted to test this by comparing the action of 'discard; redraw' with 'redraw' on its own, and I haven't been able to detect any differences at all, either in memory usage or what is displayed. Since you assert that the discard is not superfluous in this case, please supply some code to demonstrate how it modifies the behaviour compared with redraw alone.
Richard.
|
|
|
|
Rod
Full Member
member is offline
Gender:
Posts: 110
|
|
Re: #graphicHandle "discard"
« Reply #18 on: Jun 3rd, 2017, 2:56pm » |
|
I see the point you are making. I have always used discard ahead of redraw. I was probably not even aware that redraw has an implicit discard function.
However to muddy the water further the following code behaves very differently with and without the discard statement. Without it I see memory use escalate, with it I see rock steady memory use. Win10 LB 4.5.1
Whether it matters for LBB I am not sure, ignoring discard seems the correct strategy.
Code: nomainwin
WindowWidth = 600
WindowHeight = 400
UpperLeftX = (DisplayWidth-WindowWidth)/2
UpperLeftY = (DisplayHeight-WindowHeight)/2
button #1.b, "Draw Graphic", [nextdrawing], UL, 250, 340
graphicbox #1.gb, 50,25,500,300
open "Refreshed Graphic Example" for window_nf as #1
#1 "trapclose [quit]"
'put the pen down and set the font
'note cls has no impact on these settings
#1.gb "down ; font comic_sans 48"
'good practice to start with a clean sheet
#1.gb "cls"
'draw the background
#1.gb "fill pink ; backcolor red ; color red"
#1.gb "place 100 50 ; boxfilled 300 150"
#1.gb "place 300 150 ; circlefilled 100"
#1.gb "backcolor pink"
#1.gb "place 50 100 ;\1"
'now flush as the named segment "backgroundimage"
#1.gb "flush backgroundimage"
[loop]
scan
'redraw the background using its segment name
#1.gb "discard ; redraw backgroundimage"
'now paint the new foreground image
'notice that the foreground images do not use
'full screen fills.
#1.gb "backcolor green ; color green"
#1.gb "place 300 50 ; boxfilled 400 200"
#1.gb "place 300 200 ; circlefilled 100"
#1.gb "backcolor red"
#1.gb "place 180 120 ;\2"
goto [loop]
[quit]
close #1
end
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: #graphicHandle "discard"
« Reply #19 on: Jun 3rd, 2017, 4:04pm » |
|
on Jun 3rd, 2017, 2:56pm, Rod wrote:| However to muddy the water further the following code behaves very differently with and without the discard statement. |
|
There's nothing in the docs to suggest that redrawing a named segment makes any difference (especially if it's exactly the same segment). Also, the 'redraw backgroundimage' makes the items drawn since the last flush inaccessible, guaranteeing a memory leak if the discard is omitted.
So my conclusion is that it's probably a bug.
Richard.
|
|
Logged
|
|
|
|
Rod
Full Member
member is offline
Gender:
Posts: 110
|
|
Re: #graphicHandle "discard"
« Reply #20 on: Jun 3rd, 2017, 4:58pm » |
|
Testing further I see that the drawing commands are held in memory in the "current segment". The redraw erases them from the screen but they can still be preserved and redrawn with a flush and redraw.
So it seems redraw does not have an implicit discard. It matters little to LBB.
Code:nomainwin
WindowWidth = 600
WindowHeight = 400
UpperLeftX = (DisplayWidth-WindowWidth)/2
UpperLeftY = (DisplayHeight-WindowHeight)/2
button #1.b, "Draw Graphic", [nextdrawing], UL, 250, 340
graphicbox #1.gb, 50,25,500,300
open "Refreshed Graphic Example" for window_nf as #1
#1 "trapclose [quit]"
'put the pen down and set the font
'note cls has no impact on these settings
#1.gb "down ; font comic_sans 48"
'good practice to start with a clean sheet
#1.gb "cls"
'draw the background
#1.gb "fill pink ; backcolor red ; color red"
#1.gb "place 100 50 ; boxfilled 300 150"
#1.gb "place 300 150 ; circlefilled 100"
#1.gb "backcolor pink"
#1.gb "place 50 100 ;\1"
'now flush as the named segment "backgroundimage"
#1.gb "flush backgroundimage"
[loop]
scan
'redraw the background using its segment name
#1.gb "discard ; redraw backgroundimage"
'now paint the new foreground image
'notice that the foreground images do not use
'full screen fills.
#1.gb "backcolor green ; color green"
#1.gb "place 300 50 ; boxfilled 400 200"
#1.gb "place 300 200 ; circlefilled 100"
#1.gb "backcolor red"
#1.gb "place 180 120 ;\2"
#1.gb "redraw backgroundimage"
#1.gb "flush s"
#1.gb "redraw s"
[quit]
close #1
end
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: #graphicHandle "discard"
« Reply #21 on: Jun 3rd, 2017, 5:57pm » |
|
on Jun 3rd, 2017, 4:58pm, Rod wrote:| So it seems redraw does not have an implicit discard. |
|
Right, but only when an explicit segment is redrawn. The LB docs are quite clear that redraw on its own causes any drawing commands since the last flush to be 'lost'. You can confirm that by changing 'redraw backgroundimage' to just 'redraw' in your most recent program.
I'm confident that the use of discard in both "flush; discard" and "discard; redraw" is superfluous, and serves only to slow down the program slightly.
Richard.
|
|
|
|
|
