Author |
Topic: Card graphics not sticking (Read 205 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 1348
|
 |
Re: Card graphics not sticking
« Reply #23 on: May 21st, 2016, 10:36am » |
|
on May 21st, 2016, 10:09am, Turtleman wrote:| Interestingly, one of the displays was "flickering" several times in LBB when opening a new window, but wasn't flickering when running in LB. |
|
In my experience all sorts of things can influence 'flickering', not just the language. The speed and type of CPU (e.g. whether it is multi-core), the graphics card, the kind of display etc. So even if something is flicker-free on your system you should not assume it will be on somebody else's.
Basically whilst you may get away with repetitively closing-and-opening a window, or using CLS, or anything else which momentarily changes the display, it's far better to avoid doing it. There are usually alternatives which result in minimal display disturbance and they should be flicker-free on all platforms.
LBB's double buffering also gives you more control of exactly when the display is updated, by calling the "InvalidateRect", "UpdateWindow" or "RedrawWindow" APIs, so even in particularly challenging circumstances there is usually a solution.
Running a program in LBB will often reveal weaknesses in your code that you never realised were there, because you 'got away with it' in LB. In such a case the fault is nevertheless with your code, not with LBB.
Richard.
|
|
 Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender: 
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #24 on: May 21st, 2016, 10:52am » |
|
You said it better than I did, namely that LBB revealed weaknesses in my code that went unnoticed in LB! The flickering was from repeated and unnecessary reads from the HD and writes to the display. That's now been fixed, but probably represents a spoonful of repairs in an ocean of goofs!
There are many CLS and FLUSH statements in the existing program that I hope will be unnecessary in LBB. Sorry for asking again, but does it "slow down" or create other problems to keep those instructions for LB compatibility when running in LBB or should they be deleted? And if the completed program runs better in LBB, is there any reason to maintain LB compatibility?
I'm currently adding additional code and testing in LB and LBB as I go.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #25 on: May 21st, 2016, 11:46am » |
|
on May 21st, 2016, 10:52am, Turtleman wrote:| Sorry for asking again, but does it "slow down" or create other problems to keep those instructions for LB compatibility when running in LBB or should they be deleted? |
|
CLS may well be essential if you are using it to clear the graphicbox/window, which is its primary purpose. Only if you are using CLS purely as a quick-and-dirty way of avoiding cumulative memory usage (and there are usually better ways, such as DELSEGMENT) can you safely delete it. Using CLS for that purpose rather than what it is intended for is a recipe for flickering!
Quote:| And if the completed program runs better in LBB, is there any reason to maintain LB compatibility? |
|
Discussed previously; I have nothing to add on the subject.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #26 on: May 21st, 2016, 12:31pm » |
|
Sorry for the repeating the question; besides, I'm finding the answers as I go and LBB is pointing out coding blunders that probably would have remained unnoticed. Adding back in "cleaned up" portions of code is going very well, and I can't wait to see the end result. Will report back later.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Card graphics not sticking
« Reply #27 on: May 22nd, 2016, 9:07pm » |
|
Quote:| is there any reason to maintain LB compatibility? |
|
Quote:| Running a program in LBB will often reveal weaknesses in your code that you never realised were there, because you 'got away with it' in LB. In such a case the fault is nevertheless with your code, not with LBB. |
|
I really wonder if there are reversal - things you get away with sloppy coding in LBB but not in LB?
It just should be somewhere - or we assume LBB is perfect (in a god-like sense).
If there are, then LB compatibility supposed to allow checking in two independent realizations, which could pinpoint sloppy coding and so make program better.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #28 on: May 22nd, 2016, 10:18pm » |
|
on May 22nd, 2016, 9:07pm, tsh73 wrote:| If there are, then LB compatibility supposed to allow checking in two independent realizations, which could pinpoint sloppy coding and so make program better. |
|
"LB compatibility" implies not using any of LBB's many language extensions, which would be a ridiculous price to pay simply to allow such checking. You would be throwing away one of the principal reasons for using LBB in the first place!
For example you cannot possibly suggest that avoiding TRY...CATCH...END TRY and instead using ON ERROR GOTO, to maintain compatibility, makes a program "better"! Or not being able to use the extensions to USING$(), or DATE$(), or word-wrap in the TEXTEDITOR, or array arithmetic, or......
And what about LB's bugs? Being forced to use a branch label as the TIMER handler, rather than a SUB (which crashes LB), makes it almost impossible to write well-structured programs. If you want more examples of code you would have to avoid, just look at the LB Bug Tracker Wiki.
So, no, allowing "checking in two independent realizations" isn't a valid reason to maintain compatibility with LB. If you want to check programs for "sloppy coding" write a tool to do it; it would be a useful thing to have.
Richard.
|
|
Logged
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: Card graphics not sticking
« Reply #29 on: May 23rd, 2016, 09:49am » |
|
tsh73,
Quote:| I really wonder if there are reversal - things you get away with sloppy coding in LBB but not in LB? |
|
If you "really wonder" this, then perhaps put up a bunch of examples?
Quote:| ... we assume LBB is perfect (in a god-like sense). |
|
What the hell does that mean in a programmer-like sense? What program is "perfect?" Certainly not LB!
Perhaps you are making some kind of oblique personal comment? If so, I don't think that part of your post is appropriate in this context.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #30 on: May 23rd, 2016, 10:52am » |
|
I'm a little reluctant to jump into this "friendly discussion," but as a newcomer to LBB, I've had nothing but trouble trying to get what appeared to be properly operating LB code to run in LBB. I was hoping to gain faster execution (and maybe reduce or eliminate infrequent crashes), but was disappointed to see that the program ran several times slower in LBB!
I'm currently dissecting and troubleshooting one section of code at a time; and so far, the problems stem entirely from sloppy programming in LB! After some changes, the code runs just as well in both, though any potential speed benefits won't be assessed until more code is "fixed" and the entire program reassembled. The point I'm making is that LBB has definitely identified "errors" in my LB coding that would have remained unnoticed. For that reason alone, I'm very glad to have "discovered" LBB and am still hoping that other benefits will be forthcoming.
On a side note: if I were talented enough to write a program to check for and identify sloppy coding, I probably wouldn't be making so many mistakes to begin with! 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #31 on: May 23rd, 2016, 12:00pm » |
|
on May 23rd, 2016, 10:52am, Turtleman wrote:| I was hoping to gain faster execution (and maybe reduce or eliminate infrequent crashes), but was disappointed to see that the program ran several times slower in LBB! |
|
You keep saying that LBB is much slower than LB, but you never tell us where the Profiler says the time is being spent, despite me having asked at least twice. Please let us know the answer, perhaps by posting an extract from the Profiler report file.
I can artificially create a program which runs "several times slower" in LBB, but it's not typical of real-world code. Here are some extreme comparisons:
Code: start = time$("ms")
for i = 1 to 1000000
next
finish = time$("ms")
print "Execution time ";finish-start;" milliseconds"
In LB 4.5.0 about 7000 ms and in LBB 3.04 about 90 ms, that's about 75 times faster in LBB. But...
Code: start = time$("ms")
for i = 1 to 100000
a$ = word$(" The quick brown fox jumps over the lazy dog ", 8)
scan
next
finish = time$("ms")
print "Execution time ";finish-start;" milliseconds"
In LB 4.5.0 about 2000 ms and in LBB 3.04 about 8000 ms, that's about 4 times slower in LBB.
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Card graphics not sticking
« Reply #32 on: May 23rd, 2016, 12:10pm » |
|
Quote:If you "really wonder" this, then perhaps put up a bunch of examples?
|
|
If I had examples I had not to wonder. I would then just said that and give examples.
Quote:>>I really wonder if there are reversal - things you get away with sloppy coding in LBB but not in LB?
It just should be somewhere - or we assume LBB is perfect (in a god-like sense).
> What the hell does that mean in a programmer-like sense? What program is "perfect?" Certainly not LB!
|
|
I'll try again.
It was said that trying to run valid working (or seem so) LB program in LBB discovers some defects in coding.
I suppose that should work *both* ways.
That is, having many working LBB programs, occasionally running it in LB will point some defect in coding (not in LB or LBB - but in mine coding, as a BASIC programmer).
Unless one assumes LB is so great that defective in some way code cannot ever work in LBB.
(of cource Richard points out that to have big amount of LBB programs and not to use LBB new features is pointless.
I agree.)
As of the rest please don't think about things I never said.
|
| « Last Edit: May 23rd, 2016, 12:12pm by tsh73 » |
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #33 on: May 23rd, 2016, 12:14pm » |
|
Russell: Perhaps you misunderstood what I meant. The slower execution I was experiencing in LBB was entirely due to sloppy programming in my LB code to start with! I wasn't saying that LBB is or isn't inherently faster or slower, merely that my inefficient program was causing speed related problems, and that once fixed, ran well in LBB! I was actually praising LBB for identifying errors that were going unnoticed in LB.
I'm currently trying to modify part of my program that's showing a very noticeable difference in speed; but as before, it's likely some goof that I haven't caught yet. I've used the Profiler, but haven't identified anything worthy of passing along … yet. This may take a few days, but I'm trying to get to the bottom of things and will be glad to pass along the results as I find them.
I appreciate your continued help.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #34 on: May 23rd, 2016, 3:15pm » |
|
Here's an example of a code snippet that runs noticeably slower in LBB than LB. It's not lifted from my program, which would only confuse, but is totally representative of what I'm trying to show.
The program populates a grid of 10 x 20 colored boxes as defined in the [Fieldvalues]. A left click on any box will sequence through 1-5 numbers and associated colors.
Here's the "problem": In LB, the program opens almost immediately, while it takes considerably longer in LBB. (The grid in my actual program is almost twice as large, and the time to load is even longer.) The opening (and closing) is by a button in another part of the program, and it's somewhat disturbing to watch the graph slowly fill in when using LBB as opposed to LB. (The sytlebits comment at the top of the program has been commented out. While the display could be hidden until finished loading, the delay is still not desirable.)
I hope I've committed some horrendous programming error and that there's a way of speeding things up. In any case, there's a noticeable difference in the time it takes to load in LB vs. LBB.
Any suggestions would be must appreciated. Thanks!
SORRY - I GOT A MESSAGE THAT THE CODE WAS TOO LONG. IT'S ONLY 300 LINES - HOW DO I ATTACH IT?
|
| « Last Edit: May 23rd, 2016, 3:20pm by Turtleman » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #35 on: May 23rd, 2016, 3:40pm » |
|
on May 23rd, 2016, 12:14pm, Turtleman wrote:| The slower execution I was experiencing in LBB was entirely due to sloppy programming in my LB code to start with! |
|
Generally, "sloppy programming" won't cause things to run more slowly in LBB. If the program runs, which means your programming (whether it be 'sloppy' or otherwise) is compatible with LBB, it should benefit from a speed improvement, or at least not run significantly slower.
So very slow-running code in LBB is a concern, irrespective of the quality of your programming, because it's not expected. Because it's so easy to run the Profiler to find out where that slowness is arising, I ask you once again to do that and to post the relevant section(s) of the report file. Many thanks.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #36 on: May 23rd, 2016, 3:48pm » |
|
Got to run right now and may not be able to get back to this until tomorrow. I ran the Profiler and am trying to figure out how to post it along with my code. I'm very anxious to get to the bottom of this. Later!
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #37 on: May 23rd, 2016, 4:10pm » |
|
on May 23rd, 2016, 3:48pm, Turtleman wrote:| I hope I've committed some horrendous programming error and that there's a way of speeding things up. |
|
No. You have hit a rare 'edge case', which I have encountered only once before, in a program written by an Australian user. LBB is not suitable for your program - use LB instead.
Richard.
|
|
Logged
|
|
|
|
|
