|
History
| Log In
|
|
|
|
You're right; it's not completely broken, although there are bugs (and differences) with the version that's up now:
The version in 3.3.3 uses the default OpenLaszlo splash tag. My example uses a custom SWF. There's an important difference between IE and Firefox (on the PC at least): The ratio attribute appears to be ignored on IE. Ratio defaults to 0.5, which means that the slider should move half-way while downloading, and the remainder while starting up. This means that the first time you browse to the app, the slider should move slowly for the first 50%, then move at startup pace for the remainder. When you reload the app in the browser, it should start at 50% (because it's cached), then move the remainder while the app starts. In Firefox, this works fine. In IE, when you reload the cached up, you don't see the splash page at all. It's completely blank. The splash screen is completely blank in FF1.5 and IE6 (XP) using the 3.4.x build (2250). On the mac (2250) the splash make a brief appearance in FF1.5. The 3.3.3 release behaves the same as the 3.4.x nightly on XP.
Quoting from email the last time this issue was raised:
On Apr 27, 2006, at 2:28 PM, P T Withington wrote: > The Flash player will defer animation updates in favor of loading. > You can prove this to yourself by loading your app through a > bandwidth restricter (e.g., a modem). When your app is local and > loading 'infinitely fast', the player spends it's time doing useful > work, rather than spinning animations. > > As annoying as this may be, it's going to get your app loaded faster. > > Personally I think this is the right choice. True it is the opposite > of the Windows model which gives priority to the flapping folder, or > the IE model which advances the progress bar whether any data is > actually being transferred or not, but there's nothing you can do > about it, unless you want to artificially throttle your servers. > > Similarly, the player will defer animations when there is computation > happening. If your app is a huge app that initializes all at once, > this will cause any spinners to not get updated. You can look at the > 'initstage' feature to address this issue. By deferring bits of your > app that are not needed immediately, you will both get to your first > screen faster and possibly free up some cpu cycles to animate your > spinners. You can verify that the splash tag is working "as designed" by editing WEB-INF/lps/config/lps.properties and adding the line: lps.throttle=60 Then uninstall/reinstall your server (ant webapp.undeploy webapp.deploy), so that it re-reads the properties file. Clear the cache on your browser and load the test case. You will see that the splash tag works as designed (because the server is delivering the app artificially slow). [ptw@tin-woodsman trunk 15:09:10]$ svn diff WEB-INF/lps/config/lps.properties
Index: WEB-INF/lps/config/lps.properties =================================================================== --- WEB-INF/lps/config/lps.properties (revision 2255) +++ WEB-INF/lps/config/lps.properties (working copy) @@ -158,3 +158,4 @@ # Enable/disable the schema validator for more strict warnings in compilation compiler.validate = true +lps.throttle=60 [ptw@tin-woodsman trunk 18:01:49]$ I've confirmed that I can see the preloader in OpenLaszlo 3.3 in IE. There is still a bug here.
The following code should get you a preloader that animates from beginning to halfway during the download process. The remaining half of the animation should occur during early/normal startup of the app. i.e. between when the app is downloaded and the canvas fires its oninit event: <splash> <view name="foo" ratio="0.5" resource="tween2.swf" /> </splash> I've set some live (over HTTP) testcases. Here is OpenLaszlo 3.3: http://www.laszlosystems.com/lps-3.3/my-apps/preloader2/preloader.lzx Note that the preloader never actually gets to the end of its animation. The blue bar is supposed to reach the width of the gray bar. Now here it is in OpenLaszlo 2.0: http://www.laszlosystems.com/lps-2.0/my-apps/preloader2/preloader.lzx Notice that it reaches the end of the cycle? The first bug is that the preloader never reaches the end of its run (and doesn't move during startup). Jim can you assign this one to a developer. See Antun's comments.
Can we have the source of the testcase please?
Here's the source, including .fla file for the tween.
I can't tell from the documentation for splash whether the 2.x or 3.x behavior is the 'expected' behavior.
A plain splash tag is keyed _only_ to the load progress, not to the instantiation progress. Setting the ratio to .5 means that when the app is completely loaded, 1/2 the movie will have been played. It appears that in 2.x, once the app is loaded, instead of stopping the movie, the movie continues to play (perhaps giving the illusion that it is tracking the instantiation progress). In 3.x, once the app is loaded, the splash movie is stopped. If you pass the persistent flag to the splash, the splash stays in place, and you can establish a handler for canvas.onpercentcreated that can continue to animate the splash movie. (See for example the amazon demo, although the code for this is commented out, for reasons unknown to me. Oh, perhaps because it does not work. Wait, the code is broken, once I fix the type-oh's in the code, it does work just fine.) My question to the reporter and other interested parties is: Do you want the 2.x behavior, that once the app is loaded the splash movie just continues to run (like an IE progress bar, with no relation to anything, just as eye candy to amuse the user); or do you want the 3.x behavior, that the splash movie is stopped when loading is complete (and if you want to animate it further, you need to do so in an `initstage=early` in the app proper)? [Relevant email thread]
From: P T Withington <ptw@openlaszlo.org> Subject: Re: [JIRA] Commented: ( Date: Fri, 27 Oct 2006 19:09:59 -0400 To: Adam Wolff <adam@laszlosystems.com> [Adding Max, Jim, Ma,ye] On 2006-10-27, at 18:48 EDT, Adam Wolff wrote: > On Oct 27, Antun Karlovac wrote: > >> [cc-ing Adam since he wrote this originally] >> >> As far as I remember, the intended behavior was always that setting >> ratio="0.5" on a view with a resource in the splash tag meant that: >> >> - 1/2 of the animation would play during download. >> - 1/2 of the animation would play while all the normal views >> initialize. >> - When canvas fired its oninit event, the animation would be >> coming to >> the end of its run. > This is correct. >> >> Adam, can you confirm the expected behavior here? It seems like >> splash >> has either been broken for ages, or my understanding has been >> broken for >> ages. > This is also correct. We had talked about really fixing splash, but > had > never gotten around to it. Also, when we ditched the old SWFWriter, I > think we broke a bunch of this stuff and never fixed it. As I > recall, the > product team did a lot of work to make the splash work correctly in > mail, > but it didn't sound like that stuff was reliably generalized to the > platform. So you are saying that the movie should just free run after it has noted the d/l progress? Which simply means that when the preloader is done, rather than saying gotoAndStop on the movie, I would say gotoAndPlay. This is an easy enough fix. I was also able to fix amazon, which had some code that looked like it was trying to pace the second half animation to onpercentdone, and make it work. Max has suggested that if you leave the splash movie running, and want to override it to match percentdone, you can just do that. I was concerned that leaving it running might make the progress bar jump backwards when percent done gets noted, but perhaps that's not an issue. I'd still like to know how the behavior got changed between 2.x and 3.x, but for now it seems the consensus is to just let the movie keep running after the load is complete. Correct? Ok, I found out why this 'works' in 2.x and is 'broken' in 3.x.
It is because sallen fixed the `ratio` attribute of the splash tag to actually do something in 3.x! In 2.x the `ratio` tag is ignored. If you look for `lastframe` in the 2.x [SplashCompiler](http://tinyurl.com/yyapk7), you will see that it computes lastframe from ratio, and then sets lastframe back to 100 (effectively ignoring the ratio altogether). If you look at Antun's http://www.laszlosystems.com/lps-2.0/my-apps/preloader2/preloader.lzx test case carefully (watching the browser's loading progress) you will see that the splash transitions from 'Loading' to 'Starting' even though the browser is still loading the app, then there is a long pause while the app inits before the splash goes away. In 3.x, Sarah fixed ratio to actually be obeyed in change [26469](http://tinyurl.com/y36po5). Hence, when you load a simple app with a ratio of .5, the splash will correctly only animate 1/2 way, paced to the file load. If you look at Antun's http://www.laszlosystems.com/lps-3.3/my-apps/preloader2/preloader.lzx test case, you see that the splash does not transition to 'Starting' until the app is actually fully loaded. The splash does not continue to animate, because no one is animating it with percentcreated. Adding the following code to Antun's test case _will_ cause the progress bar to continue to animate according to percentcreated: <splash persistent="true"> <view name="foo" ratio="0.5" resource="tween2.swf" /> </splash> <node initstage="early" oninit="canvas.initdelay=400"> <method event="onpercentcreated" reference="canvas" args="p"> var f = canvas.splash.foo; f.stop(Math.floor(f.totalframes * (1+p)/2)); </method> <method event="oninit" reference="canvas"> this.destroy(); </method> </node> I will grant this is rather convoluted code and that if we want the default behavior of splash to be to track loading _and_ node creation, we should probably package this up better (perhaps as a component). But for now, I claim that there is not a bug in the splash implementation. Actually, this simpler code will achieve the same thing. Just put the event handler directly on the canvas:
<method event="onpercentcreated" args="p"> var f = this.splash.foo; f.stop(Math.floor(f.totalframes * (1+p)/2)); </method> [Relevant mail]
From: P T Withington <ptw@openlaszlo.org> Date: Mon, 30 Oct 2006 15:19:45 -0500 On 2006-10-30, at 15:03 EST, Max Carlson wrote: > Adam Wolff wrote: >> On Oct 27, P T Withington wrote: >> [snip] >>> So you are saying that the movie should just free run after it >>> has noted >>> the d/l progress? >> No. This is how the feature was originally designed: if I have a >> splash >> with 100 frames and I set my ratio to .6 the following will >> happen: As the app loads, splash movie should advance >> proportionally from frame 1 >> to frame 60 as the loadratio of the app advances from 0 to 1. Then, >> the splash movie should advance from frame 60 to frame 100 >> proportionally >> as the percentcreated of the app goes from 0 to 1. > > The second half of this is false - we always had to manually add > code to move from frame 60 onwards. Is there any reason to change that? I _could_ probably add some code to preloader.done so that when it is persisted and has a ratio it gets hooked to canvas.percentdone for the remaining ratio. Or, I could just move the bug to be a documentation bug and document in <splash> how to add that hook manually. My only concern with the auto-hook is that there would be no way to override it if you wanted some other event to drive the second-phase progress. I think that the preloader should be fairly automated. A developer should not need to add an onpercentcreated handler to manually push the animation along.
Remember also that when using the default <splash> tag you don't have access (or at least it's not directly exposed/documented) to the default loading/progress indicator, in order to push the animation along. r2432 | ptw | 2006-11-08 10:57:34 -0500 (Wed, 08 Nov 2006) | 34 lines
Change 20061106-ptw-5 by ptw@dueling-banjos.local on 2006-11-06 17:57:44 EST in /Users/ptw/OpenLaszlo/trunk Summary: Note instantiation progress for splash if ratio < 1 Bugs Fixed: Technical Reviewer: max (Message-ID: <45512CE1.4070209@openlaszlo.org>) QA Reviewer: mamye (pending) Doc Reviewer: jsundman (pending) Documentation: The world was under the illusion that if they set the ratio for the <splash> tag to something less than one, the first phase of the splash animation noted load progress, while the second phase noted instantiation progress. This was apparently never true, and when lzpreloader was fixed to actually obey its ratio parameter, many were disappointed. Our illustrious Chief Architect has deemed that I should "make it so". This has been done. I have set some bleachers up in the sun... The documentation should be updated to reflect the folk wisdom. Details: lzpreloader: Update/remove stale comments. Pass ratio and totalframes to persisted views. If ratio is < 1, animate remainder of presisted views against canvas.percentcreated. amazon: Remove (now redundant) animation against canvas.percentcreated. Tests: demos/amazon/amazon.lzx animates it's splash all the way across This can be verified by (in a clean install, with empty browser cache) loading demos/amazon/amazon.lzx and noting that the progress bar animates all the way across. Prior to this fix, it would only animate 1/2 way.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
P1
Splash is still broken (with or without ratio)
http://www.openlaszlo.org/lps/demos/weather/weather.html?&src=/lps/demos/weather/weather.html&lzt=html
Mamye, can you confirm Antun's test case and perhaps look into what's different about it?