I have a huge code execution with many loops and pre-rendering processes and I was wondering if there is a way to tell the flash player to take a little pause on the code side and do a render.
Basically I have my execusion that takes a while, and on each step I make a call to a screen and then modify the scale of a loading bar. Now the problem is that the user only sees the progress at the end, I know this is due to the fact that flash does code execution and then render, i tried to make calls to stage.invalidate to force a render but it wouldnt work until the whole execusion if finished either. Is there a way to force flash to render between two lines of code?
I encountered a similar problem in which my AS code would be running for a long time and the UI was getting unresponsive. So I implemented my logic as a Green Thread.
Check out this link for an as3 implementation and examples.
UIComponent has a rendering "framework" built into it. All display objects extend from it.
This will allow you to optimize your code, by using the invalidate methods.
You will want to familiarize yourself with pseudo-threads.
Related
Let me give you a little explanation of what I'm trying to do first. I'm working on a new AS3 based architecture and I'm trying to fix some issues I had in the past with AS2. Each screen has its own FLA, and multiple screens reference certain components; a Button for example. The problem occurs when something in Button changes. Every single screen that uses Button has to be republished or else it has a chance that it won't pick up the change due to how Flash class definitions work: The first Button definition that loads at runtime is the one that everything uses. So if a screen using the old Button loads first then everything will be using the old definition and things will break. It can take an hour or more to figure out which FLA needs to be exported to fix it since there are so many and the connection between them isn't always obvious. So as you can see, this is a major time sink that needs to be fixed.
I've learned that in AS2 you can use an exclude.xml file to exclude class definitions from the SWF when the FLA is published. In this way, I figured out an architecture I can set up where there is a Shell SWF that is the only place where the Button class is defined. Shell then loads in all of the other screens that all have Button excluded so that they only pick up the Shell version. This makes sure that if anything in Button changes, the only thing that needs to be republished is the Shell and then everything else picks up the change at runtime.
This is all well and good, except that when using AS3 the exclude.xml file no longer works. Because of this I've turned to MXMLC, which can mimic the exclude.xml functionality by using the -link-report compiler option to build the exclude.xml when compiling the Shell SWF, and then pass that XML to -load-externs on every other screen to exclude everything that is built by the Shell. The only way I've found to do this is by publishing everything as a SWC from Flash and then using -include-libraries to build the SWF from the SWC along with the -load-externs to exclude everything I don't want to be there. This does the trick just fine, except that publishing as a SWC does not include anything defined on the timeline or, more specifically, the stage. A lot of design work is done on the timeline in Flash by layering on the different parts and dropping in named MovieClips all over the place that are then referenced in ActionScript, but the SWC doesn't pick up any of this information as far as I can tell.
So now we come to my question. Is there some way to compile all of the information in a FLA using MXMLC so that I can exclude everything while still being able to design out everything on the timeline/stage?
I sent an email to Grant Skinner and he basically said the only way he knew of to do excludes with AS3 was with RSL or SWC. He wasn't entirely sure which method worked since it had been a long time, so I don't have a definitive answer. I spent a while trying to figure it out using SWCs, but I didn't really get any decent results from it so I'm giving up for now.
The important part to note is that it is indeed impossible to run MXMLC to build a FLA. Or at least if it is possible, it requires very complex knowledge that not many people know.
I just recently switched from doing timeline code to documentclass and I am having some trouble figuring this out...
I am making a choice based game so I have a lot of choices that needs to take place...
in the time line what I did was had each frame with choice. if the user picked a choice it would assign that choice a variable and at the end of the game it would run a switch case to pick out the one with that variable and adds it to the screen...
but as soon as I got to the document class to try to do the same things just using code; I couldn't figure out what to do...
I mean i couldn't operate it the same way, otherwise I would have if loops with in if loops with in if loops and I would have to write down each possibility manually. so I decided to use the bitmap screenshots instead but now I can't figure out...that how do I exactly sequence things inside the document class?...I mean how do I tell it to show me these choice after the previous ones are done? and not have to gointo never ending if loops. with timeline I was able to sequence things using frames but without accessing frames how can I sequence things based on, if a choice is clicked, remove those objects and add new ones but not getting locked within functions of functions? can somebody show me the light by providing a clear example please? I am really new at this and really lost,too...
I am developing a jQtouch app and each request done via ajax creates a new div in the document for the loaded content. Only a single div is shown at any one time.
How many div's can I have before the app starts getting unresponsive and slow?
Anyone have any ideas on this?
EDIT: Its an iPad app running on Safari, and it would be less than 1000 div's with very basic content
I've had tens of thousands, maybe even a hundred thousand divs, on screen at once.
Performance is either fine, or bad, depending on:
Parsed from HTML or generated Dynamically in JavaScript?
Parsed from HTML means you have a LARGE html source, and this can make browsers hang. Generated in JS is surprisingly fast, even on Internet Explorer, which is the slowest of all browsers for JS.
To be honest, if you really need an absolute answer to this question, then you might want to reconsider your design.
No answer given here will be right, as it depends upon many factors that are specific to your application. E.g. heavy vs. little CSS use, size of the divs, amount of actual graphics rendering required per div, target browser/platform, number of DOM event listeners etc..
Just because you can doesn't mean that you should! :-)
As others have said, there's really no answer.
However, in this talk about the Google Maps API version 3, the speaker brings up the number ten thousand several times, as a basic threshold for browser unhappiness.
http://code.google.com/apis/maps/documentation/javascript/
Without defining a particular environment, it's not possible to answer your question.
And even then, anything anyone tells you is just a guess. You need to do your own testing on real-world configurations with different browsers and hardware. You'll also need to establish some performance benchmarks to decide what "too slow" even means.
I've been able to add several thousand divs without a problem. Depends on what you'll be doing afterwards, of course, and the memory on the client machine. Everyone else is right about that.
As Harpo said, 10K is probably a good ceiling. At one time, I noticed speed problems starting at about 4K divs, but hardware has improved since then.
And, as Neil N said, adding the divs via scripting is better than having a huge HTML source.
And, to answer Harpo's comment, one way to "break it up" so that JS doesn't lock the page and produce a "page is running slowly" error is to call a timer at the end of each "add a div" routine, and the timer in turn calls your "add a div" function again.
Now, MY question is: is it possible to "paint" so that you don't need to add thousands of divs? This can be done with the canvas tag with some browsers, but I don't think it's possible with VML (the excanvas project) on IE. Or is it? I think VML "paints" by adding new elements to the DOM, at which point you may as well use DIVs, unless it's a simple shape.
Is it possible to alter the source of an image via scripting? (the image in the DOM, of course -- not the original image on the server.)
I have a flex/actionscript based project. The project has various view stacks and tab navigators and a few popup windows. The whole thing is managed in pureMVC framework.
When transitioning between various view states, opening a popup, switching a tab, etc, I find the app to exhibit various redraw glitches. Parts of views will be partially drawn or flicker in odd ways. I am fairly confident that the code is working correctly, just seems to be an issue with the overall heaviness of the UI.
Is this a common issue? Are their tried and true techniques to optimize this problem?
In particular what event handlers are available to delay the drawing of view components until the last moment when everything is ready to quickly display to the screen?
Say for example I have a VBox inside a viewstack, and inside this VBox I have a fairly complex datagrid. Can I prepare the datagrid and/or delay the viewstack change until all subview components are in fact ready to be quickly drawn.
What are some possible symptoms to this kind of glitchiness?
just a guess, but this might be related to the flex framework ... i experienced this kind of behaviour too ... i guess it is related to the way flex framework works when carrying out ui tasks ... a lot of deferred instantiations/calls and so on ... when there is a lot going on, the framerate drops and since deferring is framebased, that is probably when the resulting delays become noticable ...
greetz
back2dos
Not sure if this applies to you, but in Firefox/OSX there is a known bug when you make too many javascript calls, and the result is similar as you say... the whole interface shows various glitches and flickers... The solution was to delay the JS calls a bit, so they don't get called too often... this was a serious issue with swfaddress for instance (I think it still is).
http://www.bigspaceship.com/blog/labs/mac-firefox-30-flash-javascript-random-artifacts/
I assume you need the datagrid already attached to its parent container and you are loading data while it's being shown so it constantly updates and renders its content.
Have you simply tried setting its visibility to false until everything is loaded while keeping includeInLayout true and giving it a fixed size?
Is there any significant performance/load time impact if single web page will load, say, 10 identical flash objects? 20? 30?.. any evidential data on sustainability of such kind of setup?
This would be the same flash app, each instance serving its own stream.
There's definitely going to be some overhead in size as there is a certain amount of code that is contained in every swf regardless of it's developer created content.
I'm almost certain there would be speed issues as well, which would see frame rates drop right down the more swfs you add to the page.
To be honest the concept smells a little fishy and i would think there must be a better solution to your problem.
EDIT
Also there is a restriction on having two steams coming over http per domain. Sure you could get around this but it will definitely be an issue.
I found this post which might help. The trick is to use SWFObject to embed your swf files.
I ran into a strange problem today. On the music charts page on Muziboo, I was displaying a list of songs and a playlist on the right. Each song has a small button player done in OpenLaszlo. In firefox everything was fine and in IE (not unusually), the page would freeze for sometime. This would happen once and repeat only if I delete cache and try again. I googled a bit and learnt that it's a good idea to embed give each swf a unique id otherwise the browser misbehaves. I then went ahead and used swfobject to embed the swf files and everything started working great!
Yes, it'll likely nuke the browser if you go too far down that road.
If you want to deal in multiple streams, perhaps combining all your would-be applets into one giant one might work better. It'll certainly offset the serious overhead you'd have with 10-40 of the little blighters.
If this is a music player, you want to have a serious look at doing some JavaScript remoting. It's fairly trivial to control a flash app via JS so you could have standard HTML/CSS controls without having to load up a billion flash instances.
Design-wise this just sounds like a bad idea. You'd be running multiple instances of the Flash player inside a browser, each of which has an individual cost, and the host (in this case the browser) will run all of them on the same thread (with the exception of certain elective asynchronous processes), so you're almost surely going to run into problems of various kinds -- jittery playback, UI blocking, processor burden, memory bloat, consequent instability of the host, etc.
Unless the SWFs are very tiny, and doing very little work, it seems like a design that's just asking for trouble. Indeed you could test such a thing fairly easily; have you run any tests yet? Just curious.
Also curious as to the requirements; we might be able to offer more constructive alternatives if we knew a little more about what you were aiming for. Have you considered simply loading all the SWFs into a single container SWF requiring only a single browser-hosted instance of the Flash player?