Re: Another examples of the screen refresh problem on the Mac?
Great explanation and break down Richard. I very much enjoyed this. -- Tom McGrath III http://lazyriver.on-rev.com 3mcgr...@comcast.net On Oct 12, 2011, at 9:54 AM, Richard Gaskin wrote: James Hurley wrote: Thank you for this Bernd. It is going to take me a while to digest these new graphic features in 5.0. I confess I am unaware of the interaction between RR code and the display on the screen. That's probably important. :-) Like you, I don't see much improvement of 5.0 over 4.6 in animation. The effect of lowering the syncRate, not so much the rate as the time between syncs (?), is significant, but then that was something available to us in 4.6--except that I didn't know it. The nomenclature suggests that it is the frequency, when it appears to be the period. And, as we all learned in physics, one is the reciprocal of the other. I would like to see a little help from RR on these new features--by way of a demonstration stack perhaps. Yes, I think that's going to be necessary, and over time as more is understood about the new rendering scheme, hopefully there will also be more intelligent defaults so users can immediately see at least some benefit without having to do multiple iterations of experimentation. The v5.0 rendering engine represents perhaps the biggest change in the history of the engine to how objects are rendered on screen. The upside is that it's possible to see graphics performance increase many times over previous versions. The downside is that it's not easy to realize that performance gain without a great deal of experimentation. In earlier versions, cards were rendered using a very brute-force method, in which every time there was a screen refresh every object was rendered from back to front until all had been rendered, and then that composite image was copied to the graphport of the window in which the card is displayed. So simply moving a single billiard ball, which might actually affect only one small portion of the screen, caused the entire screen to go through that rendering process. It was thorough and robust, but often redundant. In the new rendering engine, the screen composite is divided into tiles, and logic is applied to determining whether a given tile is affected by a given change. Those tiles that are affected will be re-rendered, while those that aren't will simply retain their last rendering and use that to copy to the window for the finished result. There is a certain amount of additional internal overhead to this tiled scheme, however, since it now has to keep track of multiple sections of the screen and run through that hit-testing to determine which ones need to be re-rendered. On the one hand, more tiles can mean less re-rerendering, but on the other hand it means more tile management. So the key to using the new graphics engine effectively boils down to finding the right tile size optimal for your particular layout and the nature of the changes happening within it. If you have relatively small objects whose changes affect relatively small portions of the screen, you may find a smaller tile size will offer greater performance. But if even a small object moves over a large area, a larger tile size may provide even better performance. The optimal tile size can't be known in advance, because it depends on a wide variety of factors driven by scripts that may exist in the objects on the card themselves, or even in some remote library, and the sum of their interactions may be too complex to expect that the engine can figure out in advance how to set an optimal tile size. So in v5, to take advantage of this new rendering scheme we need to experiment with different tile sizes, some larger and some smaller, and perhaps even different rendering engines on the platforms they're available on (LC now uses OpenGL, for example, on platforms where that technology is available). Through the evolution of this new engine, developers on the dev list noted a wide range of performance results from worse than before to OMG this thing just flies!, depending on the different combinations of tile sizes and other rendering options they took the time to experiment with. Given the complexity of the new renderer, and how much conceptualization and experimentation is required by the user to use it well, it could be argued that it has introduced a level of complexity that seems counter-productive to RunRev's goal of delivering the simplest system possible for delivering professional software. But I believe that as we use it more often, and as experimentation and development continue at RunRev, we will shortly see ever-better versions of this engine which are able to apply defaults which provide at least some of the benefits, leaving further performance enhancement to those developers who need it and will be willing to put in the time
Re: Another examples of the screen refresh problem on the Mac?
Thank you for this Bernd. It is going to take me a while to digest these new graphic features in 5.0. I confess I am unaware of the interaction between RR code and the display on the screen. That's probably important. :-) Like you, I don't see much improvement of 5.0 over 4.6 in animation. The effect of lowering the syncRate, not so much the rate as the time between syncs (?), is significant, but then that was something available to us in 4.6--except that I didn't know it. The nomenclature suggests that it is the frequency, when it appears to be the period. And, as we all learned in physics, one is the reciprocal of the other. I would like to see a little help from RR on these new features--by way of a demonstration stack perhaps. Jim Hurley Message: 10 Date: Tue, 11 Oct 2011 12:40:46 -0700 (PDT) From: BNig niggem...@uni-wh.de To: use-revolut...@lists.runrev.com Subject: Re: Another examples of the screen refresh problem on the Mac? Message-ID: 1318362046019-3895717.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Hi, to anyone who is interested in the stack moving two graphics and different settings of syncrate, a handler that calls itself and does a lock screen wait for syncrate milliseconds and unlock screen and the Livecode 5.0 options of compositortype/tile/cache and layer mode and wants to test all the possible variations by optionMenus checkboxes etc here is the stack to test (basically the one I sent to Jim Hurley plus the livecode 5 options) berndniggemann.on-rev.com/movegraphic/movegraphic.livecode.zip I still don't seem to get the Livecode 5.0 graphic options. At least I only see minor improvements with moving two graphics along a path of 180 points. The largest effect on smoothness comes from reducing the syncrate. And I agree with Colin that the dictionary has it the wrong way around: the lower the syncrate the smoother the movement and the higher the processor load. A little to the smoothness is added by calling a handler during movement that lock/pauses/unlocks the screen. Graphic effects do not seem to be of much difference. I am still not shure about the optimal settings. Kind regards Bernd ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
James Hurley wrote: Thank you for this Bernd. It is going to take me a while to digest these new graphic features in 5.0. I confess I am unaware of the interaction between RR code and the display on the screen. That's probably important. :-) Like you, I don't see much improvement of 5.0 over 4.6 in animation. The effect of lowering the syncRate, not so much the rate as the time between syncs (?), is significant, but then that was something available to us in 4.6--except that I didn't know it. The nomenclature suggests that it is the frequency, when it appears to be the period. And, as we all learned in physics, one is the reciprocal of the other. I would like to see a little help from RR on these new features--by way of a demonstration stack perhaps. Yes, I think that's going to be necessary, and over time as more is understood about the new rendering scheme, hopefully there will also be more intelligent defaults so users can immediately see at least some benefit without having to do multiple iterations of experimentation. The v5.0 rendering engine represents perhaps the biggest change in the history of the engine to how objects are rendered on screen. The upside is that it's possible to see graphics performance increase many times over previous versions. The downside is that it's not easy to realize that performance gain without a great deal of experimentation. In earlier versions, cards were rendered using a very brute-force method, in which every time there was a screen refresh every object was rendered from back to front until all had been rendered, and then that composite image was copied to the graphport of the window in which the card is displayed. So simply moving a single billiard ball, which might actually affect only one small portion of the screen, caused the entire screen to go through that rendering process. It was thorough and robust, but often redundant. In the new rendering engine, the screen composite is divided into tiles, and logic is applied to determining whether a given tile is affected by a given change. Those tiles that are affected will be re-rendered, while those that aren't will simply retain their last rendering and use that to copy to the window for the finished result. There is a certain amount of additional internal overhead to this tiled scheme, however, since it now has to keep track of multiple sections of the screen and run through that hit-testing to determine which ones need to be re-rendered. On the one hand, more tiles can mean less re-rerendering, but on the other hand it means more tile management. So the key to using the new graphics engine effectively boils down to finding the right tile size optimal for your particular layout and the nature of the changes happening within it. If you have relatively small objects whose changes affect relatively small portions of the screen, you may find a smaller tile size will offer greater performance. But if even a small object moves over a large area, a larger tile size may provide even better performance. The optimal tile size can't be known in advance, because it depends on a wide variety of factors driven by scripts that may exist in the objects on the card themselves, or even in some remote library, and the sum of their interactions may be too complex to expect that the engine can figure out in advance how to set an optimal tile size. So in v5, to take advantage of this new rendering scheme we need to experiment with different tile sizes, some larger and some smaller, and perhaps even different rendering engines on the platforms they're available on (LC now uses OpenGL, for example, on platforms where that technology is available). Through the evolution of this new engine, developers on the dev list noted a wide range of performance results from worse than before to OMG this thing just flies!, depending on the different combinations of tile sizes and other rendering options they took the time to experiment with. Given the complexity of the new renderer, and how much conceptualization and experimentation is required by the user to use it well, it could be argued that it has introduced a level of complexity that seems counter-productive to RunRev's goal of delivering the simplest system possible for delivering professional software. But I believe that as we use it more often, and as experimentation and development continue at RunRev, we will shortly see ever-better versions of this engine which are able to apply defaults which provide at least some of the benefits, leaving further performance enhancement to those developers who need it and will be willing to put in the time to apply it effectively. In the meantime, it's my understanding that the current defaults should be using rendering methods roughly on par with previous versions, so ideally just running stuff you've already written should perform as well as it did
Re: Another examples of the screen refresh problem on the Mac?
Hi Richard, thank you for outlining the architecture of the new 5.0 LiveCode graphics engine. That shurely helps to take advantage of it. And as you pointed out we will have to experiment to find a setting that suits a particular situation. It just happens that Jim brought up the problem of moving simultaneously two graphics along the points of a graphic. And that he was not pleased with it. If you like you can test that scenario: http://berndniggemann.on-rev.com/movegraphic/movegraphic.livecode.zip From all the many variations I did for this particular task, it seems that simply setting the syncrate from 20 to e.g. 16 improves the smoothness of the movement tremendously. That applies to 4.6 as well as 5.0 The new graphics engine features do improve movement but again with the new graphic features setting the syncrate to 16 improves movement considerably. In this particular instance more than the new features at a syncrate of 20. Do you or anybody else have some more information on syncrate? Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Re-Another-examples-of-the-screen-refresh-problem-on-the-Mac-tp3897913p3898506.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
On 10/12/11 8:10 AM, James Hurley wrote: I would like to see a little help from RR on these new features--by way of a demonstration stack perhaps. We all would. Richard's explanation was very good and with a few guidelines I think we'll all catch on eventually and jaws will drop. I know that in my sample stack, it went from barely useable on mobile platforms to amazingly smooth -- at least, on my particular tablet. I gave it to Richard to test and it failed miserably. I'm sure it has something to do with tile size and cache limits but I need some info on how to calculate those. Right now I'm stabbing in the dark. As I understand it, the cache isn't so important on desktop builds or in stacks. Computers have plenty of RAM these days so set it as high as you want for now. Tile size probably matters though. What I'd suggest for now is to play with the new settings in 5.0 and see what you come up with. It took me about a day to get something to work, but once it did I was awfully impressed. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
These are exciting times for RR. I am grateful to all who have responded to this thread--Bernd, Bob, Kevin, Jacque, Ken, et. al. And special thanks to Richard for taking the time for his expansive discussion of the new features. THANK YOU. I am grateful, but. I am not satisfied. I would like to see one example, one animation stack from RR, that is manifestly improved in 5.0 over 4.6 I will do my part. I have put together a stack/library of graphic routines together will multiple examples of their use in the following stack: go url http://jamesphurley.com/jhurleyFolder/ProgrammableGraphics.livecode; It should run in both 4.0 and 5.0 Here are dozens of animations on which to test 5.0. New commands and functions for graphically programming lines (setAngle, getAngle, setLength, getLength, JoinLines. Plus intersection points of overlapping circles, tangent lives to ellipses, collision detection inside a convex polygon, etc. After 40 years of teaching I have come to one immutable conclusion: People learn best and most easily by example. (That's why Winkler and Kamins was such a great book from which to learn HyperTalk.) An example is worth a thousand pictures, and you know how many words a picture is worth. (Good grief, that compounds to a million words.) So I would like to see one example from RR to celebrate the animation capabilities of 5.0 But once again, I am grateful for RR's continued efforts to improve animation. I realize that is not a high priority at this time of such emphasis on mobil applications. Jim Hurley Message: 25 Date: Wed, 12 Oct 2011 06:54:51 -0700 From: Richard Gaskin ambassa...@fourthworld.com To: use-livecode@lists.runrev.com Subject: Re: Another examples of the screen refresh problem on the Mac? Message-ID: 4e959c2b.5080...@fourthworld.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed James Hurley wrote: Thank you for this Bernd. It is going to take me a while to digest these new graphic features in 5.0. I confess I am unaware of the interaction between RR code and the display on the screen. That's probably important. :-) Like you, I don't see much improvement of 5.0 over 4.6 in animation. The effect of lowering the syncRate, not so much the rate as the time between syncs (?), is significant, but then that was something available to us in 4.6--except that I didn't know it. The nomenclature suggests that it is the frequency, when it appears to be the period. And, as we all learned in physics, one is the reciprocal of the other. I would like to see a little help from RR on these new features--by way of a demonstration stack perhaps. Yes, I think that's going to be necessary, and over time as more is understood about the new rendering scheme, hopefully there will also be more intelligent defaults so users can immediately see at least some benefit without having to do multiple iterations of experimentation. The v5.0 rendering engine represents perhaps the biggest change in the history of the engine to how objects are rendered on screen. The upside is that it's possible to see graphics performance increase many times over previous versions. The downside is that it's not easy to realize that performance gain without a great deal of experimentation. (skip) In the meantime, it's my understanding that the current defaults should be using rendering methods roughly on par with previous versions, so ideally just running stuff you've already written should perform as well as it did before. And if you want it even faster, just set aside some time to experiment with different tile sizes and chances are you'll have a Wow! moment once you find the right combination for your layout. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv -- ___ use-livecode mailing list use-livecode@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-livecode End of use-livecode Digest, Vol 97, Issue 26 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
heh heh. nice. On Oct 10, 2011, at 6:16 PM, Mark Wieder wrote: Bob- Monday, October 10, 2011, 4:59:15 PM, you wrote: I guess the logic is, All that is not true is false. Didn't Gödel disprove that? -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Hi, to anyone who is interested in the stack moving two graphics and different settings of syncrate, a handler that calls itself and does a lock screen wait for syncrate milliseconds and unlock screen and the Livecode 5.0 options of compositortype/tile/cache and layer mode and wants to test all the possible variations by optionMenus checkboxes etc here is the stack to test (basically the one I sent to Jim Hurley plus the livecode 5 options) berndniggemann.on-rev.com/movegraphic/movegraphic.livecode.zip I still don't seem to get the Livecode 5.0 graphic options. At least I only see minor improvements with moving two graphics along a path of 180 points. The largest effect on smoothness comes from reducing the syncrate. And I agree with Colin that the dictionary has it the wrong way around: the lower the syncrate the smoother the movement and the higher the processor load. A little to the smoothness is added by calling a handler during movement that lock/pauses/unlocks the screen. Graphic effects do not seem to be of much difference. I am still not shure about the optimal settings. Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Another-examples-of-the-screen-refresh-problem-on-the-Mac-tp3891506p3895717.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
On 10/10/2011 10:22 PM, James Hurley wrote: I suspect this is a problem peculiar to the Mac. When I run: set the lockmoves to true move grc Oval to tPoints without waiting move grc rectangle to tNewPoints without waiting set the lockmoves to false The oval moves reasonably smoothly, but the rectangle take several abrupt steps. Is this another manifestation of the screen refresh problem on the Mac? Normally I intersperse a unlock screen command to force a screen refresh, but I can't do that with the move command. I don't really know; but I set up a plain vanilla stack Mover with a rectangular graphic and an oval graphic; rekt and oval respectively; the card containing this script: on mouseDown move grc rekt to the mouseLoc without waiting end mouseDown on mouseUp move grc rekt to the mouseLoc without waiting end mouseUp all this on a merry old PPC MacMini running 10.4.11 and, frankly didn't notice anything particularly different about the way the two graphics moved... this may say something about your Macintosh or your code. if you wish you may download the stack here: http://andregarzia.on-rev.com/richmond/BOX/Mover.rev.zip of course one can also have quite a spot of vaguely infantile fun playing around with it. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
On Oct 10, 2011, at 2:22 PM, James Hurley wrote: I suspect this is a problem peculiar to the Mac. When I run: set the lockmoves to true move grc Oval to tPoints without waiting move grc rectangle to tNewPoints without waiting set the lockmoves to false The oval moves reasonably smoothly, but the rectangle take several abrupt steps. Is this another manifestation of the screen refresh problem on the Mac? Normally I intersperse a unlock screen command to force a screen refresh, but I can't do that with the move command. Jim, I'm not seeing that on my Mac (I'm running Lion if that makes any difference, and LC 4.6.4). Does either your oval or rectangle have graphic effects applied to it? Perhaps something like that is slowing down redraw… Just to compare, here's what I did: 1) Created a new stack, made the window like 1024x768 (approximately. 2) Created an oval graphic in the upper-left corner of the window 3) Create a rectangle graphic just underneath it 4) Dragged a button to the lower-right corner of the window 5) Dragged a button to the lower-left corner of the window and edited its script to read: on mouseUp lock moves move grc 1 to the loc of btn 1 without waiting move grc 2 to the loc of btn 1 without waiting unlock moves end mouseUp Switched to browse, and then executed it - the movements were smooth and no jerkiness. Since I don't know what values you have in tPoints or tNewPoints, maybe you can try what I did and see if you get the same result? If so, then it might be the number of points or something else related to properties of the graphics themselves. Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Ken, Thanks for your careful test. This is driving me nuts and I can't find a work-around. I think the problem is RR not doing a screen refresh after each of the MULTIPLE steps. (I have always, in OS 10) had to do a refresh after EACH step. Would you please try this for me: on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 100 times put x,y cr after tPoints add dx to x end repeat put 200 into x put 200 into y repeat 200 put x,y cr after tNewPoints add dy to y end repeat lock moves move button one to tNewPoints without waiting move button two to tPoints without waiting unlock moves end mouseUp When I tried your script I got what you got: Smooth motion. But with the script above, eliminating possible problems with the graphics, I get herky-jerky motion with the second move. I suspect it is due to the multiple steps in the move. Running RR 4.6.3 and Mac OS 10.6.8 Thanks again, Jim Jim, I'm not seeing that on my Mac (I'm running Lion if that makes any difference, and LC 4.6.4). Does either your oval or rectangle have graphic effects applied to it? Perhaps something like that is slowing down redraw… Just to compare, here's what I did: 1) Created a new stack, made the window like 1024x768 (approximately. 2) Created an oval graphic in the upper-left corner of the window 3) Create a rectangle graphic just underneath it 4) Dragged a button to the lower-right corner of the window 5) Dragged a button to the lower-left corner of the window and edited its script to read: on mouseUp lock moves move grc 1 to the loc of btn 1 without waiting move grc 2 to the loc of btn 1 without waiting unlock moves end mouseUp Switched to browse, and then executed it - the movements were smooth and no jerkiness. Since I don't know what values you have in tPoints or tNewPoints, maybe you can try what I did and see if you get the same result? If so, then it might be the number of points or something else related to properties of the graphics themselves. Ken Ray Sons of Thunder Software, Inc. Email: kray at sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Ok I get the first button moving smoothly and the second button jerky. If I run each move individually without the other, then both are smooth. The horizontal move leaves vertical line artifacts, which is not good. I get the same effect even after commenting out the lock moves/unlock moves commands, so I do not know what they are there for. Bob On Oct 10, 2011, at 4:04 PM, James Hurley wrote: Ken, Thanks for your careful test. This is driving me nuts and I can't find a work-around. I think the problem is RR not doing a screen refresh after each of the MULTIPLE steps. (I have always, in OS 10) had to do a refresh after EACH step. Would you please try this for me: on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 100 times put x,y cr after tPoints add dx to x end repeat put 200 into x put 200 into y repeat 200 put x,y cr after tNewPoints add dy to y end repeat lock moves move button one to tNewPoints without waiting move button two to tPoints without waiting unlock moves end mouseUp When I tried your script I got what you got: Smooth motion. But with the script above, eliminating possible problems with the graphics, I get herky-jerky motion with the second move. I suspect it is due to the multiple steps in the move. Running RR 4.6.3 and Mac OS 10.6.8 Thanks again, Jim Jim, I'm not seeing that on my Mac (I'm running Lion if that makes any difference, and LC 4.6.4). Does either your oval or rectangle have graphic effects applied to it? Perhaps something like that is slowing down redraw… Just to compare, here's what I did: 1) Created a new stack, made the window like 1024x768 (approximately. 2) Created an oval graphic in the upper-left corner of the window 3) Create a rectangle graphic just underneath it 4) Dragged a button to the lower-right corner of the window 5) Dragged a button to the lower-left corner of the window and edited its script to read: on mouseUp lock moves move grc 1 to the loc of btn 1 without waiting move grc 2 to the loc of btn 1 without waiting unlock moves end mouseUp Switched to browse, and then executed it - the movements were smooth and no jerkiness. Since I don't know what values you have in tPoints or tNewPoints, maybe you can try what I did and see if you get the same result? If so, then it might be the number of points or something else related to properties of the graphics themselves. Ken Ray Sons of Thunder Software, Inc. Email: kray at sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
A variation of this script shows that lockmoves is getting set to false before the first move command. Given: on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 100 times put x,y cr after tPoints add dx to x end repeat put 200 into x put 200 into y repeat 200 put x,y cr after tNewPoints add dy to y end repeat put empty into mmsg lock moves put the lockmoves into mmsg move button two to tPoints without waiting put comma and the lockmoves after mmsg move button one to tNewPoints without waiting put comma and the lockmoves after mmsg unlock moves put comma and the lockmoves after mmsg put mmsg end mouseUp I get truefalsefalsefalse in the message box. Odd though that there are no commas?? But I digress. It is obvious that the first move command is setting lockMoves to false. This has to be a bug. Bob On Oct 10, 2011, at 4:04 PM, James Hurley wrote: Ken, Thanks for your careful test. This is driving me nuts and I can't find a work-around. I think the problem is RR not doing a screen refresh after each of the MULTIPLE steps. (I have always, in OS 10) had to do a refresh after EACH step. Would you please try this for me: ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Bob, Here is what I get on the lockMove messages. (I'm on the email digest so I have trouble copying your message.) on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 100 times put x,y cr after tPoints add dx to x end repeat put 200 into x put 200 into y repeat 200 put x,y cr after tNewPoints add dy to y end repeat put Before lock the lockmoves cr into tMessage lock moves put After lock the lockmoves cr after tMessage move button one to tNewPoints without waiting put After first move the lockmoves cr after tMessage move button two to tPoints without waiting put After second movethe lockmoves cr after tMessage unlock moves put After unlock the lockmoves cr after tMessage put tMessage into msg box end mouseUp And the message in the message box is: Before lock false After lock true After first move true After second move true After unlock false So all of that seems OK. Jim ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Hi Bob, wouldn't put comma and the lockmoves after mmsg be rather put comma the lockmoves after mmsg ? in your version of the code you ask for the logical AND and this returns false Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Another-examples-of-the-screen-refresh-problem-on-the-Mac-tp3891506p3892227.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Hi Jim, I sent you a stack that decreases the syncrate and has a self-calling routine with lock screen, wait x milliseconds unlock screen that smoothes the movement of the two graphics moving along a path of 180 points considerably. Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Another-examples-of-the-screen-refresh-problem-on-the-Mac-tp3891506p3892232.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
DOH! of course. Bob On Oct 10, 2011, at 4:47 PM, BNig wrote: Hi Bob, wouldn't put comma and the lockmoves after mmsg be rather put comma the lockmoves after mmsg ? in your version of the code you ask for the logical AND and this returns false Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Another-examples-of-the-screen-refresh-problem-on-the-Mac-tp3891506p3892227.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
yeah I had a brain fart and used AND instead of . DOH! I wonder then why ANDING comma and true does not produce an error? Adding 1 to green certainly does! I guess the logic is, All that is not true is false. Bob On Oct 10, 2011, at 4:44 PM, James Hurley wrote: Bob, Here is what I get on the lockMove messages. (I'm on the email digest so I have trouble copying your message.) on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 100 times put x,y cr after tPoints add dx to x end repeat put 200 into x put 200 into y repeat 200 put x,y cr after tNewPoints add dy to y end repeat put Before lock the lockmoves cr into tMessage lock moves put After lock the lockmoves cr after tMessage move button one to tNewPoints without waiting put After first move the lockmoves cr after tMessage move button two to tPoints without waiting put After second movethe lockmoves cr after tMessage unlock moves put After unlock the lockmoves cr after tMessage put tMessage into msg box end mouseUp And the message in the message box is: Before lock false After lock true After first move true After second move true After unlock false So all of that seems OK. Jim ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Bob- Monday, October 10, 2011, 4:59:15 PM, you wrote: I guess the logic is, All that is not true is false. Didn't Gödel disprove that? -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
On Oct 10, 2011, at 6:04 PM, James Hurley wrote: Ken, Thanks for your careful test. This is driving me nuts and I can't find a work-around. I think the problem is RR not doing a screen refresh after each of the MULTIPLE steps. (I have always, in OS 10) had to do a refresh after EACH step. Would you please try this for me: I get the same jerky effect that you get. Now that I see the code, I think the issue is that you're doing a single pixel move for both objects; when I spread that out to do that every 8 pixels, it was smooth: on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 25 times put x,y cr after tPoints add (4*dx) to x end repeat put 200 into x put 200 into y repeat 25 put x,y cr after tNewPoints add (8*dy) to y end repeat lock moves move button one to tNewPoints without waiting move button two to tPoints without waiting unlock moves end mouseUp Will that work for you? Or do you really need to move the objects in 1 pixel increments? Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Ken, The script I sent you was just an example and I simplified what I ultimately would like to try. I would like, for example, to simulate dynamical motion, for example projectile motion, and that requires fairly close spacing of the points. Or motion around an elliptical orbit. Generally this is done with a repeat loop and setting the location with each successive time interval in the motion, rather than using the move command along a predefined set of points. The thing I was going to try was to first calculate all the points, the complete trajectory, and then move the icon along those points. The problem is coordinating this movement with other things that are moving as well. That is much easier to control with a repeat loop. But I can do what I have done before, in the game of pool for example where one relies on RR's speed of execution to allow the sequential motion of each ball to give the appearance of concurrent movement. I just got a personal note from Benrd Niggemann who has experimented with a number of parameters affecting the smoothness of the motion. He has found, and I I have just confirmed it myself, that setting the syncrate (I was totally unaware of such a property) to 6 rather than the default of 20 is very helpful. That is to say, SLOWING the screen update INCREASES the smoothness of the motion. Go figure. It is still necessary to force a screen refresh with an unlcok screen command after each step. I haven't a clue what goes on behind the scene in this regard. I have been putting together a graphics library to share, following the good example of Peter Brigham who recently shared his library of utilities for text parsing and processing. Well, back to the drawing board--almost literally, And thank you again for testing this more me. The feedback was very helpful. Jim Hurley I get the same jerky effect that you get. Now that I see the code, I think the issue is that you're doing a single pixel move for both objects; when I spread that out to do that every 8 pixels, it was smooth: on mouseUp put 200 into x put 200 into y put 2 into dx put 1 into dy repeat 25 times put x,y cr after tPoints add (4*dx) to x end repeat put 200 into x put 200 into y repeat 25 put x,y cr after tNewPoints add (8*dy) to y end repeat lock moves move button one to tNewPoints without waiting move button two to tPoints without waiting unlock moves end mouseUp Will that work for you? Or do you really need to move the objects in 1 pixel increments? Ken Ray Sons of Thunder Software, Inc. Email: kray at sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
I just got a personal note from Benrd Niggemann who has experimented with a number of parameters affecting the smoothness of the motion. He has found, and I I have just confirmed it myself, that setting the syncrate (I was totally unaware of such a property) to 6 rather than the default of 20 is very helpful. That is to say, SLOWING the screen update INCREASES the smoothness of the motion. Go figure. It is still necessary to force a screen refresh with an unlcok screen command after each step. I haven't a clue what goes on behind the scene in this regard. Wow! I have been using LiveCode since it was MetaCard and only on Unix, and I wasn't aware of syncRate either! Looks like I need to go through the LC Dictionary and see what *else* I'm missing! :D Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
On 10/10/11 6:04 PM, James Hurley wrote: Ken, Thanks for your careful test. This is driving me nuts and I can't find a work-around. The workaround might be LiveCode 5.0, where animation has been greatly enhanced. That said, I have a script that moves two objects together that also misbehaves in both 4.6.4 and 5.0. What I had to do was make the second object move faster than the first. Both move commands use a time factor, so: move btn btn1 to x,y in 500 milliseconds move btn btn2 to x,y in 100 milliseconds Then they both move together, only at the faster rate. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
Ken- Monday, October 10, 2011, 7:58:39 PM, you wrote: that setting the syncrate (I was totally unaware of such a I wasn't aware of syncRate either! That makes a lot more sense than when I first read it as syn-crate. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Another examples of the screen refresh problem on the Mac?
I just tried some values, and it appears that the documentation is wrong. The example given of setting it to 12, makes you think that it's 12 frames per second. Saying that 20 is the default and that decreasing the rate will reduce CPU load, but may make things jerky, confirms that the help is talking in terms of frame per second. But, if you try: set the syncrate to 1000 you'll see that there is exactly one update of the Move movement per second. Setting it to 100 give a convincing 10 fps. In other words, the number is the amount of milliseconds between updates, and not the frames per second at all. Setting it to the default of 20 would give you 50 fps, which should be plenty smooth enough for anyone, especially if the company that used that default lives in a country that has PAL TV. I believe that Mac OS and iOS have an effective fixed rate of 60 fps, so if you're using syncrate you may as well use 17 rather than 6. In related news, there is a new iOS specific command, iphoneSetRedrawInterval. With that you can have LiveCode just do updates when iOS does them, which would be a bit like having a syncrate of 16.666, that is in sync with the system redraw. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
