LB Booster
Programming >> Compatibility with LB4 >> #graphicHandle "discard"
http://lbb.conforums.com/index.cgi?board=compatibility&action=display&num=1495832615
#graphicHandle "discard"
Post by tsh73 on May 26th, 2017, 9:03pm

I have a program at JB forum
Games and Graphics\Fire?
Reply #11
It is conversion of old QB program.
Anyway. I was really surprised that it looks much worse in LBB than in JB.
It supposed to draw lines of width 2 more or less smooth - and it looks so in JB - but in LBB I apparently see lines of size 1
And overall piclure was darker, seemingly missing lines.

Today I sit and try to hunt it down.
I was looking for something like rounding work differently.

But the problem happened to be in "discard" statement.
If I remove "discard" in line 57 (first loop), picture instantly gets nice.

Somehow I was under impression that LBB just ignore "discard" so it should not matter. Or was it "flush"?
But obviously I am wrong.

So what happens here and what "discard" actually do?
Re: #graphicHandle "discard"
Post by Richard Russell on May 27th, 2017, 04:37am

on May 26th, 2017, 9:03pm, tsh73 wrote:
Somehow I was under impression that LBB just ignore "discard" so it should not matter. Or was it "flush"?But obviously I am wrong.

So what happens here and what "discard" actually do?

The LBB docs say "Discards anything drawn since the last FLUSH (deprecated)" so you should have realised that something happens! DISCARD is relied upon in too many programs to be ignored completely.

What LBB does is as follows (pseudo-code):

Code:
LockWindowUpdate(hwnd)
BitBlt(BackingStore,LastFlushedGraphic)
LockWindowUpdate(NULL)

What this does is to make the displayed graphic 'volatile': if covered/uncovered or minimized/restored it will no longer 'stick'.

This strategy significantly improves compatibility with LB programs; it is unusual and unfortunate if it makes yours worse. I would question whether you are using DISCARD correctly; does your final displayed graphic 'stick'? If not your output is also 'volatile' and there is an element of luck that it (normally) displays correctly in LB4.

Richard.
Re: #graphicHandle "discard"
Post by tsh73 on May 29th, 2017, 6:38pm

Hello Richard
Quote:
I would question whether you are using DISCARD correctly;

Well, what is "correctly"?
My program works there I write it - in JB - and does what I want it to do (and before trying somewhere else I had no idea it could work other way - and it just always happens so wink ).
But now I really doubt if I use "discard" for aim it was designed for.

So.
My program constantly draws on screen, overwriting previous picture.
JB/LB stores all things I draw, this increases memory used, visibly slows drawing and eventually crashes program.
So I issue "discard" meaning "you should not store my graphic operations - I do not care about them".
And for JB, it works - memory consumption does not increase, program do not crash.
And that's the only thing I use discard, ever. I think.
As for
Quote:
does your final displayed graphic 'stick'

- there is no final stage, and I really don't care.

Now, I thought that LBB does not stores drawing commands - I thought so because it obviously doesn't need "flush" - so it doesn't need "discard". So I thought it just passed over, no action taken.

EDIT (after some thought while it doesn't *need* flush, it should do *something* for supporting named segments.)

I really wonder what right use for
Quote:
to make the displayed graphic 'volatile': if covered/uncovered or minimized/restored it will no longer 'stick'.

might be?

Is where an example?
Re: #graphicHandle "discard"
Post by Richard Russell on May 29th, 2017, 8:14pm

on May 29th, 2017, 6:38pm, tsh73 wrote:
Well, what is "correctly"?

If you look in the 'Troubleshooting' section of the LBB docs you will see an example of what I mean. There are two code snippets listed, both of which (superficially) work the same in LB4, but only one works properly in LBB. If you look at the sequence of operations in each case, you can see why one is 'correct' and the other 'incorrect'.

Quote:
My program works there I write it - in JB - and does what I want it to do

On how many different PCs, versions of Windows, graphics cards (with acceleration enabled and disabled) etc. have you tried it? The point I am making is that you cannot assert that a program is 'correct' simply by observing that it does what you want on a particular platform.

The 'flame' program that you listed at the JB forum works perfectly well for me in LBB, without modification, on my Windows 10 laptop.

Quote:
Now, I thought that LBB does not stores drawing commands

Well, it doesn't store drawing "commands" (that is, it doesn't save them to a graphics metafile like JB/LB do) but it does store the graphics themselves because otherwise they won't 'stick'. LBB uses a conventional double-buffering scheme whereby the graphics are drawn to an 'off screen' memory buffer and then 'blitted' to the screen by Windows when required, such as when the window is covered-and-uncovered or minimised-and-restored.

Are you able to record (e.g. by taking a video) the 'unwanted' behaviour of your program when running in LBB?

Richard.
Re: #graphicHandle "discard"
Post by Rod on May 30th, 2017, 3:01pm

The program output is different on my pc running Win10. The essential difference is that LBB discard actually changes the screen and sets it back to the last saved segment. Liberty on the other hand simply forgets the building metafile and leaves the screen untouched with the graphics in view. They are volatile but usually you won't care because you will be redrawing or overdrawing frequently.
Re: #graphicHandle "discard"
Post by Richard Russell on May 30th, 2017, 3:55pm

on May 30th, 2017, 3:01pm, Rod wrote:
The essential difference is that LBB discard actually changes the screen and sets it back to the last saved segment.

It shouldn't (and it doesn't on my PCs). Liberty BASIC has a separate graphics command with that functionality: REDRAW.

If you look at the pseudo-code I listed you will see that LockWindowUpdate is used to prevent the display updating immediately, but only when Windows later forces a refresh - for example on a cover/uncover or minimise/restore.

I don't know why your PC is disregarding the LockWindowUpdate and updating the display immediately. One possible cause is that another running application has also called LockWindowUpdate - it is a limitation that only one window may be locked at a time. If that's the case there's not a lot I can do about it.

The advantages of LBB's conventional double-buffered graphics over LB4's 'segments' are more than enough to compensate for any minor compatibility issues resulting from the use of FLUSH / DISCARD / REDRAW. I deliberately document them as "deprecated" to discourage their use in new programs.

Richard.
Re: #graphicHandle "discard"
Post by Rod on May 30th, 2017, 6:15pm

Don't know why the blit is happening but it is erasing previously drawn graphics. Perhaps discard should capture the current screen to the background buffer in LBB.

Re: #graphicHandle "discard"
Post by Richard Russell on May 30th, 2017, 6:48pm

on May 30th, 2017, 6:15pm, Rod wrote:
Perhaps discard should capture the current screen to the background buffer in LBB.

That doesn't have the required effect. What you want is for a cover/uncover or minimize/restore operation to replace the current graphics with the 'last flushed' graphics. So the 'background buffer' must contain those last flushed graphics.

I'll experiment a bit to see if I can make the DISCARD operation more reliable across different PCs.

Richard.
Re: #graphicHandle "discard"
Post by tsh73 on May 30th, 2017, 6:58pm

Quote:
What you want is for a cover/uncover or minimize/restore operation to replace the current graphics with the 'last flushed' graphics.

But why one could want it?

I did managed to upload videos
It is taken under WinXP SP3, my working computer
(same effect as WinXP SP3 at my home computer)

without discard
https://youtu.be/5aFNT22YLuQ

with discard
https://youtu.be/ZqYg_aytGxo
Re: #graphicHandle "discard"
Post by Richard Russell on May 30th, 2017, 8:53pm

on May 30th, 2017, 6:58pm, tsh73 wrote:
But why one could want it?

Simply because there are some LB programs that do not run properly in LBB if DISCARD is ignored.

Quote:
I did managed to upload videos

OK. Firstly I must apologise that the program I was testing was a different one. I can now see the effect here.

The way LBB, as it currently stands, emulates DISCARD improves compatibility with some programs but worsens compatibility with other programs, like yours! Ideally what is needed is a way to determine when DISCARD should be ignored and when it should not be ignored.

One possible approach might be to look for the presence of a FLUSH command. Programs that rely on LBB's emulation of DISCARD are likely to be using it to restore graphics previously flushed, whereas programs like yours that are using it simply to avoid memory buildup won't be using a flush command.

Does that sound like being worth a try?

Richard.
Re: #graphicHandle "discard"
Post by Richard Russell on May 30th, 2017, 9:52pm

... indeed, even the current version of LBB (3.07) will run your program 'correctly' if you remove the flush:

Code:
    #gr, "trapclose [quit]"
    #gr, "down; fill black"
    #gr, "size 2"
    #gr, "setfocus"

Richard.
Re: #graphicHandle "discard"
Post by tsh73 on Jun 1st, 2017, 08:54am

Thank you Richard
It's always good to know "why"
I'll probably do a search for "discard" and compare how it works on more programs.
Re: #graphicHandle "discard"
Post by Richard Russell on Jun 1st, 2017, 1:13pm

on Jun 1st, 2017, 08:54am, tsh73 wrote:
It's always good to know "why".

I must admit I'm coming around to your opinion. I've got more examples of the use of discard than when LBB was originally designed, and the strategy I adopted then seems to break at least as many programs as it fixes! So maybe it would be better to ignore discard after all.

The trouble with making that change now is that although it will help some programs, such as your 'fire' example, it will break others, and that may be an annoyance or at least an inconvenience. Unfortunately it's not something that I can easily make configurable (since discard is handled in the real-time LB emulation library, not by the compiler).

Fundamentally I cannot exactly reproduce what LB4 does, so there's no perfect answer. Here's an illustration of the problem; try running this program in LB 4:

Code:
    open "test" for graphics_nsb as #w
    #w "trapclose [quit]"
    #w "down"
    #w "line 100 100 100 200"
    #w "discard"
    #w "line 100 200 200 200"
    ' #w "flush; redraw"
    wait

[quit]
    close #w
    end

The result is an L-shaped graphic. Now uncomment the flush; redraw line and run it again: now it displays just a horizontal line!

The first result is best emulated by LBB ignoring the discard, but the second result is best emulated by LBB acting upon the discard - but since the difference doesn't occur until later in the code it can't determine which to do!

Richard.
Re: #graphicHandle "discard"
Post by Richard Russell on Jun 2nd, 2017, 09:59am

Before changing LBB to ignore discard, I just want to check that my understanding of precisely what the command does - and what the LB docs say it does - are correct. I have seen a few programs that do this:

Code:
    #w "flush; discard"

The LB docs state that the command discards "all drawn items since the last flush" and since in this case there are no such items I believe the discard to be a no-op and entirely superfluous.

Similarly I have seen a few programs that do this:

Code:
    #w "discard; redraw"

The LB docs say of redraw that "Any items drawn since the last flush will not be redrawn, and will be lost". Therefore once again the discard would appear to be superfluous, because this happens anyway as a side-effect of redraw.

Does anybody disagree with this analysis? Does the discard do anything at all in either of these code snippets?

Richard.
Re: #graphicHandle "discard"
Post by Rod on Jun 2nd, 2017, 5:24pm

I think that looking at posted code could be misleading because the segment drawing system is poorly understood.

So some of the code you post, in fact all of the code you post is from poorly structured coding. Typically someone that understands would use discard in a repetitive environment. There might be an initial flush to preserve the static background then repetitively restore the background and discard the foreground. The background graphics are restored on a redraw or on windows restore. The foreground graphics are restored by the program rapidly redrawing the foreground.

Flush, and redraw need to change the graphics to whatever the programmer has preserved. If you see discard you don't need to care because the programmer never should either. Ignore it but leave the graphics on display.

Currently this does not happen.
Re: #graphicHandle "discard"
Post by Richard Russell on Jun 2nd, 2017, 7:13pm

on Jun 2nd, 2017, 5:24pm, Rod wrote:
the segment drawing system is poorly understood.

Definitely, which is one of the main reasons why I decided not to copy it in LBB (although I could have done). The result is that people use it incorrectly, typically by doing things 'by rote' or by copying other people's faulty code.

Quote:
all of the code you post is from poorly structured coding.

Well, examples of exactly that 'poor' usage can be found at Liberty BASIC Programmers' Encyclopedia, which one might hope would get things right! For example 'discard; redraw' is recommended here and 'flush; discard' is used here. Not helpful!

I've analyzed the use of discard in the set of programs I have collected over the years to test LBB. In the majority of programs which use it, it does nothing at all (even in LB4) and can safely be deleted. In most of the rest discard is used solely to prevent cumulative memory usage, so it is safe for LBB to ignore it.

In only one program that I've found is discard used in a 'functional' way, and if ignored by LBB the program won't work correctly. However in that program discard can be replaced by redraw to make it work correctly in both LBB and LB 4.

So it's clear that Anatoly is correct in recommending that discard be ignored by LBB; on balance it will improve compatibility. The few programs adversely affected by the change should be amenable to a minor modification which will retain compatibility with LB 4.

Richard.
Re: #graphicHandle "discard"
Post by Rod 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.
Re: #graphicHandle "discard"
Post by Richard Russell 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.
Re: #graphicHandle "discard"
Post by Rod 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

Re: #graphicHandle "discard"
Post by Richard Russell 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.
Re: #graphicHandle "discard"
Post by Rod 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
Re: #graphicHandle "discard"
Post by Richard Russell 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.