Re: Graphic speed comparison between webLets and desktop stacks
Message: 10 Date: Wed, 9 Sep 2009 14:54:01 -0700 (PDT) From: SparkOut sparkout...@gmail.com Subject: Re: Graphic speed comparison between webLets and desktop stacks To: use-revolution@lists.runrev.com Message-ID: 25373791.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii James Hurley wrote: On the Mac there has been a longstanding problem in using repeat loops to control the movement of screen objects. It is necessary to insert a forced screen refresh every time through the loop on the desktop. That problem goes away on the Web. A screen refresh is no longer needed. The stack I wrote is very busy, lots of factors to vary in order to compare all the possibilities. If you have the courage you can compare these things for yourself on the desktop using the stack: go url http://jamesphurley.on-rev.com/OnRevGraphicTimer.rev; And on the Web, go to http://jamesphurley.on-rev.com/OnRevTimer/test.html The stack is a little busy. Jim Hurley (P.S. On the third card of the stack above I added is a simulation of planetary motion. The speed is fine on the desktop and the motion is very smooth, but it is WAY too speedy on the Web. I didn't include any accommodation for the speed change on the Web. A good example of the need to do so. For comparison, I tried some examples on Windows (XP, Rev Enterprise 4.0-dp-4, Internet Explorer 8) and got identical* results on the desktop stack as with the revlet. *OK, I got the range 727, 728 or 729 milliseconds consistently when choosing 90 points in the circle and 7 milliseconds on the delay slider. -- And I meant to say, the blue planet spinning round the sun was high speed to the point of stroboscopic inability to see where it was at any given point - both on the web revlet and the desktop stack. -- SparkOut, Thanks for the feedback. I knew that the Rev took a hit on the Mac in these kinds of applications, but I didn't realize it was this bad. That make the PC roughly twice as fast as the Mac. Makes it difficult to develop cross platform. Jim Hurley ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Graphic speed comparison between webLets and desktop stacks
Jim, one funny thing I noticed on the mac: if in your repeat loop you set the wait to 0 millisecs on the slider the time goes down from 1500 millisecs to 630 millisecs, you can replace the wait with a unlock screen and you have again around 630 millisecs. As soon as you wait even 1 millisecond you go up to 1500 again. So there is more going on on the Mac then meets the eye. By contrast I did not manage to speed up the send in time handler, maybe someone has an idea. regards Bernd James Hurley wrote: Message: 10 Date: Wed, 9 Sep 2009 14:54:01 -0700 (PDT) From: SparkOut sparkout...@gmail.com Subject: Re: Graphic speed comparison between webLets and desktop stacks To: use-revolution@lists.runrev.com Message-ID: 25373791.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii James Hurley wrote: On the Mac there has been a longstanding problem in using repeat loops to control the movement of screen objects. It is necessary to insert a forced screen refresh every time through the loop on the desktop. That problem goes away on the Web. A screen refresh is no longer needed. The stack I wrote is very busy, lots of factors to vary in order to compare all the possibilities. If you have the courage you can compare these things for yourself on the desktop using the stack: go url http://jamesphurley.on-rev.com/OnRevGraphicTimer.rev; And on the Web, go to http://jamesphurley.on-rev.com/OnRevTimer/test.html The stack is a little busy. Jim Hurley (P.S. On the third card of the stack above I added is a simulation of planetary motion. The speed is fine on the desktop and the motion is very smooth, but it is WAY too speedy on the Web. I didn't include any accommodation for the speed change on the Web. A good example of the need to do so. For comparison, I tried some examples on Windows (XP, Rev Enterprise 4.0-dp-4, Internet Explorer 8) and got identical* results on the desktop stack as with the revlet. *OK, I got the range 727, 728 or 729 milliseconds consistently when choosing 90 points in the circle and 7 milliseconds on the delay slider. -- And I meant to say, the blue planet spinning round the sun was high speed to the point of stroboscopic inability to see where it was at any given point - both on the web revlet and the desktop stack. -- SparkOut, Thanks for the feedback. I knew that the Rev took a hit on the Mac in these kinds of applications, but I didn't realize it was this bad. That make the PC roughly twice as fast as the Mac. Makes it difficult to develop cross platform. Jim Hurley ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- View this message in context: http://www.nabble.com/Re%3A-Graphic-speed-comparison-between-webLets-and-desktop-%09stacks-tp25388757p25389915.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Graphic speed comparison between webLets and desktop stacks
James Hurley wrote: On the Mac there has been a longstanding problem in using repeat loops to control the movement of screen objects. It is necessary to insert a forced screen refresh every time through the loop on the desktop. That problem goes away on the Web. A screen refresh is no longer needed. The stack I wrote is very busy, lots of factors to vary in order to compare all the possibilities. If you have the courage you can compare these things for yourself on the desktop using the stack: go url http://jamesphurley.on-rev.com/OnRevGraphicTimer.rev; And on the Web, go to http://jamesphurley.on-rev.com/OnRevTimer/test.html The stack is a little busy. Jim Hurley (P.S. On the third card of the stack above I added is a simulation of planetary motion. The speed is fine on the desktop and the motion is very smooth, but it is WAY too speedy on the Web. I didn't include any accommodation for the speed change on the Web. A good example of the need to do so. For comparison, I tried some examples on Windows (XP, Rev Enterprise 4.0-dp-4, Internet Explorer 8) and got identical* results on the desktop stack as with the revlet. *OK, I got the range 727, 728 or 729 milliseconds consistently when choosing 90 points in the circle and 7 milliseconds on the delay slider. -- View this message in context: http://www.nabble.com/Graphic-speed-comparison-between-webLets-and-desktop-stacks-tp25332280p25373791.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Graphic speed comparison between webLets and desktop stacks
SparkOut wrote: James Hurley wrote: On the Mac there has been a longstanding problem in using repeat loops to control the movement of screen objects. It is necessary to insert a forced screen refresh every time through the loop on the desktop. That problem goes away on the Web. A screen refresh is no longer needed. The stack I wrote is very busy, lots of factors to vary in order to compare all the possibilities. If you have the courage you can compare these things for yourself on the desktop using the stack: go url http://jamesphurley.on-rev.com/OnRevGraphicTimer.rev; And on the Web, go to http://jamesphurley.on-rev.com/OnRevTimer/test.html The stack is a little busy. Jim Hurley (P.S. On the third card of the stack above I added is a simulation of planetary motion. The speed is fine on the desktop and the motion is very smooth, but it is WAY too speedy on the Web. I didn't include any accommodation for the speed change on the Web. A good example of the need to do so. For comparison, I tried some examples on Windows (XP, Rev Enterprise 4.0-dp-4, Internet Explorer 8) and got identical* results on the desktop stack as with the revlet. *OK, I got the range 727, 728 or 729 milliseconds consistently when choosing 90 points in the circle and 7 milliseconds on the delay slider. And I meant to say, the blue planet spinning round the sun was high speed to the point of stroboscopic inability to see where it was at any given point - both on the web revlet and the desktop stack. -- View this message in context: http://www.nabble.com/Graphic-speed-comparison-between-webLets-and-desktop-stacks-tp25332280p25373806.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Graphic speed comparison between webLets and desktop stacks
I enjoyed Ben Beaumont's presentation of planetary motion at the conference. I couldn't tell from the streaming video how smoothly the planets moved around the Sun. It was very bumpy on my screen, but most of that was surely due to the nature of streaming video. To see this for myself, I built a stack (see below) to compare the moving planets on the desktop with the webLet. We know that the speeds will change, but by how much? (By the way, I thought it was terrific. I was really impressed by how bright and articulate the presenters were. Lots of really good information.) In order to get some quantitative data I made a stack to simulate a ball (planet) moving along a set of points on a circle--see stack and web site below. In dealing with graphics (or images) moving along a set of points on a line there are three ways to cycle through the points: (1) Use a Send message in x millisec to cycle recursively through the points using x to control speed. (Asynchronous--i.e. allows for concurrent message sending) (2) Use a simple repeat loop, using a Wait x millisec between repeat to control speed (Not asynchronous) (3) Or use the Rev Move command, using the DragSpeed propterty to control speed. (Asynchronous) And there are generally two methods of moving an object from one point to the next: (A) Using the set location command (B) Using the Move command. In all of these options, the number of points on the graphic line is a potential variable and will affect the speed and the smoothness of the motion. It is the smoothness of the motion that to me is the critical factor, not too difficult to achieve on the desktop but much more difficult on the Web. I failed on the Web task. I don't know if Rev is still working on this. It is not a high priority issue at this time. Here is what I found from playing with the parameters (1, 2, 3, A, B above) using the OnWebGraphicTImer stack below: (1) Speed: The web is much faster than the desktop, as much as five and a half times faster if one uses Set Loc to cycle through the points. If one uses the Move command to move through the points THERE IS NO CHANGE in speed. I presume that Rev redefined Move to have this effect. (2) Smooth motion: On the desktop, Set Loc and Send Message In TIme is the best way to go. The synchronous repeat loop is bumpy, as it the Move command. On the Web I couldn't find any combination of parameters and modes and number of points on the line to achieve smooth motion. You can also see this bumpy motion on Rev's own Web site: http://revmedia.runrev.com/revMedia/ Notice how the Rev icon bumps along the set of line points. There is another problem intrinsic to the Move command: The speed along the points is uniform regardless of the distance between points. The speed along the entire path is governed by the MoveSpeed property. Because of this it cannot be used to deal with planetary motion (or simple projectile motion) since the planet should speed up as it nears the Sun at the focal point of the ellipse and slow down as it move away from the focal point. And of course a bouncing ball does not move with uniform speed. Someone at the conference asked about this speed issue (slow on the desktop--much faster on the web) but I couldn't hear the answer, only that it sounded like it was Kevin who responded. I suspect it must be a matter of timing of the screen refresh rate. But I have no real understanding of what goes on behind the scenes. Can anyone fill me in on what Kevin said? And it still under consideration? It is surely not a high priority at this early stage. On the Mac there has been a longstanding problem in using repeat loops to control the movement of screen objects. It is necessary to insert a forced screen refresh every time through the loop on the desktop. That problem goes away on the Web. A screen refresh is no longer needed. The stack I wrote is very busy, lots of factors to vary in order to compare all the possibilities. If you have the courage you can compare these things for yourself on the desktop using the stack: go url http://jamesphurley.on-rev.com/OnRevGraphicTimer.rev; And on the Web, go to http://jamesphurley.on-rev.com/OnRevTimer/test.html The stack is a little busy. Jim Hurley (P.S. On the third card of the stack above I added is a simulation of planetary motion. The speed is fine on the desktop and the motion is very smooth, but it is WAY too speedy on the Web. I didn't include any accommodation for the speed change on the Web. A good example of the need to do so. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Graphic speed comparison between webLets and desktop stacks
Someone at the conference asked about this speed issue (slow on the desktop--much faster on the web) but I couldn't hear the answer, only that it sounded like it was Kevin who responded. I suspect it must be a matter of timing of the screen refresh rate. But I have no real understanding of what goes on behind the scenes. Can anyone fill me in on what Kevin said? From what I can remember, he said that Rev apps on OS X use three layers of buffering to draw to the screen, but due to the way the plug- in interacts with the browser only two layers of buffering are required. Ian ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
