4

I have this situation and I am interested to know what can I do, in order to have a smooth menu sliding movement, all the way to the right (at menu-open) and to the left (at menu-close) without that jiggling interrupted-sticky effect at the beginning and the end of the movement that sometimes is covering the body site wrapper;

I've tried to apply a smooth transition but the issue is still there:

#responsive-menu-pro-button, #responsive-menu-pro-container, .edge-wrapper {    
  -ms-transition-timing-function: cubic-bezier(0.77, 0, 0.175, 1) !important;
  -moz-transition-timing-function: cubic-bezier(0.77, 0, 0.175, 1) !important;
  -o-transition-timing-function: cubic-bezier(0.77, 0, 0.175, 1) !important;
  -webkit-transition-timing-function: cubic-bezier(0.77, 0, 0.175, 1) !important;
  transition-timing-function: cubic-bezier(0.77, 0, 0.175, 1) !important;      
}

Also, setting transition-delay: .0s should make the slider translate in the same time with the wrapper but it doesn't apply. Maybe I am not selecting the right elements (?) OR there is a delay value set that interferes with this rule but even in this case, I didn't find any (searched with Agent Ransack the Responsive menu files).

@media screen and (min-width: 767px) {
    .edge-wrapper-inner, .edge-wrapper, .responsive-menu-pro-open, .responsive-menu-pro-close, 
    #responsive-menu-pro-wrapper, #responsive-menu-pro-container.push-left {
        -webkit-transition-delay: .0s !important;
        -moz-transition-delay: .0s !important;
        -ms-transition-delay: .0s !important;
        -o-transition-delay: .0s !important;
        transition-delay: .0s !important;
    }
}

Please watch the yellow menu container marked with red arrow using the about/close button, upper left corner in order to see the jiggling unwanted effect; Will be noticeable at the end of the movement at menu-open or menu-close, visible on right edge of the slider and left edge of the wrapper. In ideal conditions, with no delays, no jiggling, these 2 elements the slider + wrapper, should be like one single piece. But it looks like there are some kind of sticky-elastic(?) properties applied that call/react, introducing this delay/jiggling.

enter image description here

Tested in Win 10 64bit, 16GB RAM, AMD Radeon HD 7700, Chrome Browser 69.0.3497.81 Official Build 64-bit, default chrome://flags settings with hardware acceleration enabled and also Edge - where the issue is obvious, all the way of the movement but that's another story.

LE : Regarding the Browser Reflow,
The strange thing, using cache and minify html/js/css plugins, Gzip compress, html output pages in wordpress, and so on, doesn't help in achieving a smooth animation, even if I obtain a pretty nice score after optimization as follows:

PageSpeed Insights Chrome extension score (Lossless re-compresssion images checked)

enter image description here

Pingdom score for EU server

enter image description here

I've tried to analyze the animation sequence using Runtime Performance in Chrome console/ Performance but I'm not so sure what to looking for.

The question:
Is there any possibility to find the code/script/line/event responsible for the slider stuttering at menu-open/close and to tweak the code in order to make the animation smooth with no jiggling interrupted-sticky effect in Chrome latest version and the slider to translate in the exactly same time with the wrapper? The duration animation value I am interested to remain pretty much the same, not less.

Website testpage here.

Tip: If the above described unwanted effect doesn't shown, just set CPU 4x ...6x slowdown in Performance Tab (Chrome Console).

enter image description here

typo_
  • 141
  • 2
  • 14
  • 34
  • Looks smooth to me in Chrome, no jiggling what so ever – Jamie Buttons Coulter Aug 17 '18 at 15:56
  • Very strange... Win10 64bit, Chrome Version 68.0.3440.106 (Official Build) (64-bit)? Strange because I've tested on other PC as well and the issue is there. – typo_ Aug 17 '18 at 16:14
  • No lag / jiggling at all on Google Chrome (version 68.0.3440.106 - 64-bit), Windows 10 64-Bit, 16 GB of RAM. Same thing on Firefox Quantum (61.0.2 64-bit). It does stutters a lot on Microsoft Edge (42.17134.1.0). This might help: https://stackoverflow.com/questions/42242690/ms-edge-css-transition-flickering – cabrerahector Aug 17 '18 at 20:34
  • Thanks; hmm... now I'm pretty confused; On two different PC's I can see the issue, only me!? – typo_ Aug 17 '18 at 21:28
  • I've uninstalled Chrome, I've made a clean reg and so on, installed again (the latest Version) without addons/extensions, all the settings to default the same story; Disabled/enabled Hardware acceleration, as well, not sure what to do next, any hint will be much appreciated. – typo_ Aug 18 '18 at 07:05
  • You might check this https://developer.mozilla.org/en-US/docs/Web/CSS/will-change and this https://stackoverflow.com/questions/15605731/jerky-css-transform-transition-in-chrome . This issue seems to be a problem with the rendering engine itself. – www139 Sep 18 '18 at 02:50
  • Try editing the page and reload rather than the web inspector. Given the nature of the property, it may not take affect if you add it through the web inspector. – www139 Sep 18 '18 at 02:51
  • I've tried also like this editing the code (not just in console) adding `-webkit-transform: translate(0px, 0);` but it doesn't work. https://codepen.io/anon/pen/yxQpoz – typo_ Sep 18 '18 at 17:53

4 Answers4

3

Add this CSS - #responsive-menu-pro-container{top:0; position: absolute;}.

The issue here was browser reflow, you can read more here - https://developers.google.com/speed/docs/insights/browser-reflow.

Outsource WordPress
  • 3,567
  • 2
  • 7
  • 22
  • Thank you, for your time and effort; sometimes is fine, sometimes is still stuttering with the above code included. The strange thing is that the same browser is acting different on different machines. I suppose (I have to find out first) that is a System < > Browser related problem OR too much css in the menu code (unused lines) because for example a similar plugin (ShiftNav), it works so fine in the same conditions - specially in Edge, Responsive Menu stuttering so bad in Edge. – typo_ Aug 19 '18 at 16:22
  • 1
    Yes, may be, but I am unable to find better solution to this :) – Outsource WordPress Aug 19 '18 at 16:48
  • I see @sara_ added it to the source code but it still glitches for me in Chrome (macOS). – www139 Sep 18 '18 at 03:06
0

Try putting backface-visibility:hidden alongside with transitions

Stephen Rauch
  • 40,722
  • 30
  • 82
  • 105
khalvin nucom
  • 1
  • 1
  • Thank you for your suggestion, like this ? `#responsive-menu-pro-button,#responsive-menu-pro-container,#responsive-menu-pro-header,.edge-wrapper{-ms-transition-timing-function:cubic-bezier(.77,0,.175,1)!important;-moz-transition-timing-function:cubic-bezier(.77,0,.175,1)!important;-o-transition-timing-function:cubic-bezier(.77,0,.175,1)!important;-webkit-transition-timing-function:cubic-bezier(.77,0,.175,1)!important;transition-timing-function:cubic-bezier(.77,0,.175,1)!important;backface-visibility:hidden}` it doesn't work (implemented not just in console) – typo_ Sep 18 '18 at 17:40
0

From what I've found from this thread, the MDN will-change page, and my own reasoning, this issue is innate to the browser. There are a few things I suggest trying.

I noticed the glitch appeared as the console updated the inline style properties of the elements. The animation had already started before the browser updated the DOM. This suggests the DOM manipulation may be slowing down the browser at that instant and causing a "glitch" in the animation. I suggest adding a class change instead. I.e., instead of updating the inline style, try adding a class or attribute selector in your stylesheet and use the JavaScript to change the class or property name instead. Try some combination of selector changes to propagate the transformation instead of inline styles. Since the transform is the same for all the elements, you could also try adding the same class to all three. That might help.

You might also try adding the will-change: [property name]; to all the elements receiving the transformation. I do not recommend testing this in the web inspector but add it to the page source code and refresh as the web inspector may not reflect the change since the page would have already loaded and rendered. Also note the MDN doc states to use will-change very sparingly as it consumes hardware resources more so than normal transformations.

These suggestions aren't really feasible for me to implement since I only have access to your source code through the web inspector.

Let me know what you find.

www139
  • 4,141
  • 2
  • 25
  • 53
  • Thank you for your suggestions. Could you be so kind and write a piece of code regarding one of your suggestion? not so sure that I have the knowledge to implement having only these guides. Anyway, I appreciate it! let's try with `will-change: [property name]` it looks easy how to approach this? should I add this line at the end of the transitions like I 've made in the below example using `backface-visibility:hidden`? – typo_ Sep 18 '18 at 17:44
0

Solved. It was not about browser reflow, backface-visibility:hidden or whatever, it was about matching the css transition settings; I've modified like this:

#responsive-menu-pro-button,
#responsive-menu-pro-container,
#responsive-menu-pro-header,
button#responsive-menu-pro-button,
.edge-wrapper {
    -webkit-transition: 2.6s ease;
    -moz-transition: 2.6s ease;
    -ms-transition: 2.6s ease;
    -o-transition: 2.6s ease;
    transition: 2.6s ease;
    -ms-transition-timing-function: cubic-bezier(0.96, 0, 0.13, 1);
    -moz-transition-timing-function: cubic-bezier(0.96, 0, 0.13, 1);
    -o-transition-timing-function: cubic-bezier(0.96, 0, 0.13, 1);
    -webkit-transition-timing-function: cubic-bezier(0.96, 0, 0.13, 1);
    transition-timing-function: cubic-bezier(0.96, 0, 0.13, 1);
    -webkit-transition-property: -webkit-transform;
    -moz-transition-property: -moz-transform;
    -ms-transition-property: -ms-transform;
    -o-transition-property: -o-transform;
    transition-property: transform;
}

#responsive-menu-pro-container.push-left,
#responsive-menu-pro-container.slide-left {
    -webkit-transform: translate3d(-800px, 0, 0);
    -moz-transform: translate3d(-800px, 0, 0);
    -ms-transform: translate3d(-800px, 0, 0);
    -o-transform: translate3d(-800px, 0, 0);
    transform: translate3d(-800px, 0, 0);
    -webkit-transform: translate(-800px, 0);
    -moz-transform: translate(-800px, 0);
    -ms-transform: translate(-800px, 0);
    -o-transform: translate(-800px, 0);
    transform: translate(-800px, 0);
}

.responsive-menu-pro-open #responsive-menu-pro-container.push-left,
.responsive-menu-pro-open #responsive-menu-pro-container.slide-left {
    -webkit-transform: translate3d(0, 0, 0);
    -moz-transform: translate3d(0, 0, 0);
    -ms-transform: translate3d(0, 0, 0);
    -o-transform: translate3d(0, 0, 0);
    transform: translate3d(0, 0, 0);
    -webkit-transform: translate(0, 0);
    -moz-transform: translate(0, 0);
    -ms-transform: translate(0, 0);
    -o-transform: translate(0, 0);
    transform: translate(0, 0); 
 }

Thank you for your time & interest!

typo_
  • 141
  • 2
  • 14
  • 34