For .waitForElementNotVisible(selector, 2000), supposedly, it can test whether the element is fading out in 0.75 second.
But what if our code has a bug, and it is doing the wrong thing and the element is not visible and is fading in?
Now, won't .waitForElementNotVisible() actually still succeed (and pass the test), because at time = 0, it really is not visible (because it is fading in).
In other words, .waitForElementNotVisible() can succeed no matter what?
(There can be two situations, one is JavaScript adjusting the opacity every 33ms, for example, and the other case is CSS transition).
I think this is an assertion so you should use expect/assert api instead:
browser.waitForElementNotVisible(selector, 2000)
be
browser.expect.element(selector).to.not.be.visible.after(2000);
Related
I’m working on a complex project in threejs.
Trying to cut the corner:
I have to load an obj, create some pivot point to use as parent of the mesh inside this obj, let the user move and rotate the pivots.
It takes somewhere about 10 to 15 seconds to load due to its complexity.
My problem is that it is working flawlessly if I load the page and don’t change the focus, but if I change the browser tab or collapse the browser window I got a very specific problem:
geometry.computeBoundingBox() gives different results.
Is there someone who can help me figure out what’s happening?
To help you better understand the situation: at loading time I have to rotate the obj to -90° on the X axis (inverting Y and Z as a consequence); I think it’s relevant because the boundingBox calculation somehow inverts Y and Z and changes its min and max also, but as I said only if I switch tab or collapse the browser.
p.s. No matter the OS nor the browser. It’s a super consistent bug
Ok, I somehow solved the issue, but take it with a grain of salt:
the problem can be tracked back to the execution stack of javascript:
the first function computes the bounding box, the second uses this computation, but if the first function is somehow slower to execute, the second could not have what it needs.
What I did is to force javascript to execute functions in a given order and only when the previous is finished.
The problem occurred only when changing the tab because browsers optimize resources of non visible tabs, but the code I wrote was anyway too much entropic to work properly.
I hope what I found will be understandable and useful to someone else in future.
I am trying to make an animation that will fill a tube with liquid and then start moving the liquid inside. I am using an SVG with 3 main paths, the first one is liquid with short height, which then I morph to become the liquid with long height, then I want to "repeat" the morph between the other 2 paths to make it look like the liquid is moving, however when i move from one path to the other using morphSVG, I can't go back to the previous path, so my other morphSVG statement isn't executed.
Here's link to my code:
https://codepen.io/BrittanyR/pen/rJvOyX
As can be seen, I am able to move from one path to the other using:
TweenMax.to("#redSecondary", 2, {morphSVG: "#redPrimary", delay: 2})
But I can't then use this: TweenMax.to("#redPrimary", 2, {morphSVG: "#redSecondary"})
Any idea will be helpful.
Thanks.
It seems like it was just a logic issue in your code - your setTimeout() was alternating between animating #redPrimary and #redSecondary (targets), but you never changed what they were animating TO. So it worked the first time...and that's it. Every subsequent call was just duplicating the exact same movement (tweening to the current values...thus no motion).
I wonder if this is what you were looking for: https://codepen.io/GreenSock/pen/gvzMLG?editors=0010
Note: as a convenience, MorphSVGPlugin automatically records the original path data for the element so that if you ever want to animate back to it (like to("#redPrimary", 2, {morphSVG:"#redPrimary"}), it knows to grab that. It's all automatic :)
So if you want to repeatedly bounce between those morphs, a simple TimelineMax is probably the easiest way. Get rid of all that setTimeout() stuff and just do this:
var tl = new TimelineMax({repeat:-1, delay:2});
tl.to("#redPrimary", 2, {morphSVG:"#redSecondary", ease:Power1.easeInOut})
.to("#redPrimary", 2, {morphSVG:"#redPrimary", ease:Power1.easeInOut});
Does that help? I'm not entirely sure that I understood your goal properly with the animation, but hopefully this nudges you in the right direction.
Happy tweening!
I have a stacked bar chart that shows values either for month or year.
It is composed of a series of columns (1 or 12), and rects within each column (9 individual values).
You can see it here: (Note - this is a valid web page, currently running on AWS.)
http://54.245.225.47/stackedbar_ex_good
When I go from months to year view, I want to move all the positions to the yearly value, then fade them out as the year values .enter().
The problem is that the rects (where I would normally do the .exit().transition().attr("y", new_val) never gets called since the column gets deleted (.exit()). And when I tried referencing the child .rects from the svg.selectAll(".col").exit().transition(), they seemed to disappear all at once. I'm guessing this is the wrong way.
Sorry this is so confusing! I'm sure this sort of thing is answered elsewhere, but I don't even know the language to describe it properly (and hence search for it). Any tips / pointers would be appreciated.
(There is a lot of code - I don't know how to simplify in order to even post it.)
Yeah, kinda hard to understand the problem... As I understand it, you want to animate the exiting rects to some position before they're removed from the SVG. But your problem is that the rects' parents –– col in your code –– are removed immediately, and so the nested rects never have a chance to animate. Right?
If so, one way around it is to delay the removal of the exiting col's in order to give the rects animation time to play. So, rather than doing:
col.exit().remove()
apply a the delay like so:
col.exit().transition().delay(2000).remove()
There's no actual, visible transition here; it's just a way to delay the call to remove().
Nearly every example I see of OpenGL ES involves it updating every frame, even if the image itself is not moving in any way.
I did some tests and I see it works quite fine to just render (using drawArrays etc) and then present the render buffer (these two actions, together) just once and then not do either again until you have something change onscreen.
Is this "normal" ? I just don't see this really done much. Once drawn, the graphics stay on the screen without additional constant rendering.
Is this acceptable?
Yes, it is acceptable and completely valid. You also need to take account to render again when the context is lost. To give you an example, using Android standard OpenGL helper classes there is an option to only draw when needed, not in loop (RENDERMODE_WHEN_DIRTY).
I've made an animation with SVG. It's like a slowly changing wallpaper. The idea is that you should barely notice it is changing.
It's purely decorative, and I don't want it to drain any resources. Is there a way to set the frame rate in SVG? I thought setting it to a very low number might do the trick? I'm using Raphael, by the way.
Deep in Raphael's guts, you will find the logic that controls the frame rate for non-keyframe animations:
animationElements[length] && setTimeout(animation);
By omitting an actual timeout value, Raphael is basically telling the browser to run the method as fast as it can (within scheduling constraints provided by the DOM specification and the browser implementation). You could either tweak that function to use a user-supplied parameter (or put a number there, though that will affect all animations), or use Peter's suggestion.