Hi,
I have a question. A question about how Vuo manages (or will improve) the launch of exported apps.
Using “Fire on start”, I cannot get to make a clean launch for an exported app.
For example, a most simple app ; a background color in a custom sized window will always flickr from a black background and jump from the Vuo default window size to the custom one for me (see attached files).
So I was wondering :
-
Are there any plans to fix this ?
-
And how will this be done ?
-
Could some kind of a “Fire before launch” node be something ?
-
Or something that would analyze if the first events of some nodes would be completed before showing the application window ?
-
Should/Could I make a feature request for this ?
I don’t really know what would be the best way, but I really think professional looking exported apps or app prototyping should be rid of those startup glitches.
Of course, I might be completely using the nodes wrongly, perhaps there is already a solution for this, and I’d be glad to learn how to fix that.
Thanks to @jstrecker who already tried to teach me about this, but I couldn’t really get it, so I thought a separate thread for this with a most simple example could be easier.
Apps on Startup.vuo.zip (916 Bytes)
There are a couple different things that can cause a flicker when a composition first starts…
-
The window for Render * to Window nodes always appears before any events are fired. As you pointed out, @Bodysoulspirit, this means that the window will always pop up at the default size before any nodes like Change Window Aspect Ratio have a chance to change the size.
-
The events fired from Fire on Start are not coordinated in any way with other events that might fire shortly after the composition starts, such as from Requested Frame ports. That isn’t the problem with the “Apps on Startup” composition, but it’s come up in other discussions. The symptom is that the graphics flicker as different parts appear at slightly different times.
For #1, maybe we should change how windows work, so they don’t appear until they get an event? And/or maybe we need some input editors for window properties (size, aspect ratio, etc.), so that they could be set as constant values and therefore take effect immediately when the window appears?
For #2, there’s Allow First Event node, which can be substituted in place of Fire on Start. (See the “Spin Kaleidoscope” example composition.) Maybe we should also change how Fire on Start works? Right now, to quote the documentation, “There is no guarantee that this node will be the first to fire within a composition. For example, a rapidly firing Fire Periodically node may fire first.” Maybe there should be a guarantee.
Hi @jstrecker
2 - Yes I got that part. Yeah perhaps some improvements could be made for fire on start to be the very first to fire, but for now, I think as long as I use the same event distributor (On start, Periodically or Allow first requested frame) for every nodes of the composition, they show quite simultaneous, so that’s ok.
1 - That’s what I wanted to point out here.
Like I said, some input editors for windows would fix the window size glitch, but not the color one, so I think a more general solution would be better.
So yeah, I don’t know the best way to do it, but someway we need to analyze wether some (several) nodes received their event and outputted their data before the window show up.
For example with my composition above, we need to analyze if BOTH the “Make color layer” + the “Change window size” Nodes ran complete, and ONLY then launch the window with the correct size and chosen color !
For example with my composition above, we need to analyze if BOTH the “Make color layer” + the “Change window size” Nodes ran complete, and ONLY then launch the window with the correct size and chosen color !
Sure. The way that Vuo handles event flow would be perfect for doing this kind of analysis — making sure that certain nodes finish before other nodes start. It would be easy to make sure that Make Color Layer and Change Window Size both happened before the window appeared — if there were just some node/port to control when a window appears.
I was just about to create a feature request for this when I found there already is one — Nodes for showing/hiding windows, and to enable the window’s close button. Yay! I encourage you to vote for it.
@jstrecker
Ok. I’m gonna vote for that request !
To analyze, to block and to fire events in Vuo is not the most simple to me (In QC I used to connect whatever generic outputs to boolean logic patches like “Are All True” and it used to switch to “true” when the node happened.
I just tried to modify the above composition and analyze when both Make Color Layer + Change Window size got their events and analyze that using “Spin Off Events” + to delay a “Done” text layer showing after 3 seconds using an interpolation curve.
But
1 - Does it analyzes wether the nodes ran complete, or just when they received their events ?
2 - How could we make this better ?
Thanks
Analyze & Delay Events.vuo (4.94 KB)
I actually had something simpler in mind —
What happens when you run this composition:
-
Render Layers to Window displays the window at its default size and color (black).
-
Fire on Start Started port fires an event.
- Concurrently…
-
Make Color Layer executes, creating a white layer (not yet rendered).
-
Change Window Size executes, creating a window property (not yet applied to the window).
-
Render Layers to Window executes, both rendering the white layer and changing the window size.
Since the same event is going through Make Color Layer and Change Window Size and on to Render Layers to Window, Render Layers to Window won’t begin executing until both Make Color Layer and Change Window Size have finished executing.
MakeColorAndChangeSize.vuo (1.86 KB)
@jstrecker yes ok but how will Render Layers to Window know it should not execute until all its attached nodes are done executing ?
Because that’s one of the basic rules/guarantees built into Vuo. When you run a composition, Vuo (specifically, the Vuo compiler) makes sure that the the nodes execute in the proper order. In the case of an event splitting (to Make Color Layer and Change Window Size) and rejoining (at the drawer of Render Layers to Window), all of the nodes on the split part have to finish executing before the node at the rejoin point can begin executing.
(There’s more information about this in the Vuo Manual under How events and data travel through a composition.)
@jstrecker but then I don’t understand why actually “Render Layers to Window” displays the window at a default size before Make color layer and change window size have done their job ?
Doesn’t it mean Render layers to window executes before the previous nodes are done ?
Ah, good question. The (somewhat confusing) answer is that Render Layers to Window displaying its window doesn’t count as “executing”. I’ll try to explain…
When a composition is first launched, each stateful node has the opportunity to do some setup. For example: The Count node initializes its count to the number in the Set Count input port. The Play Movie node opens the movie file in its URL input port and gets ready to play it. The Receive Mouse Moves node starts tracking mouse movements… And the Render * to Window nodes display a window.
What I’ve been calling “execution” happens after this setup phase, once the composition has begun running in earnest. Each time the node receives an event, it “executes”. In the case of Render * to Window, when it executes, it displays graphics on the window and/or modifies the window properties.
If you’re thinking it’s weird that Render * to Window nodes display a window as part of their setup… well, it is. I think the window nodes are the only ones whose setup has a really noticeable effect (popping up a window). Compare that to Play Movie, which doesn’t have any noticeable effect until its Play input port gets an event.
Nodes for showing/hiding windows, and to enable the window’s close button is a chance to make this less weird.
@jstrecker
Ok, thanks for the answer. I hope to understand the main Idea. So if that request is implemented, it would somehow need to remove that Setup State am I right for “Render * to Window” ? And then it would await all its attached ports to be done executing fully right ? It would await for the Make layer to be done and the change Window size to be calculated ?!?
Ok, I voted for that one. I even think it more feels like some update rather then some feature request.
I can hardly imagine some UI prototyper guy showcasing his app UI at a meeting is going to love those start/launch glitches ;)
Can’t wait ;)
So if that request is implemented, it would somehow need to remove that Setup State am I right for “Render * to Window” ?
Remove it or at least make it optional, yes.
And then it would await all its attached ports to be done executing fully right ? It would await for the Make layer to be done and the change Window size to be calculated ?!?
Yep.
@jstrecker that’s great ! ;)
