I would like to know a way to stop the swiperjs transition at the exact spot while it's transitioning.
What I currently have is a continuous autoplay loop combined with transition-timing-function : linear; on the swiper wrapper. This makes it look like it's constantly sliding one way in a fluent motion. On the background it is however always transitioning from slide to slide (and the transition-timing property makes it look fluent). What I would like to implement is when I hover the swiper, it stops at the exact position and when I leave the mouse it starts again. I have already implemented a fix to make it stop at the exact position using this link. When hovering out though, it moves too fast to the next translate3d point. This is because when starting it again, it takes the stopped position as the starting position of the transition, which is of different length so it moves at a different speed.
I've already gone as far as implementing an interval with the same speed count as the slider property to determine the progress of the animation from point to point so to from there be able to determine the transition-duration. For example when the slide transition is half way (in my case 3.5 seconds later as the speed I set is 7 seconds), I set the transition duration to 3500 on the swiper wrapper so that it moves at the same speed to the next point when hovering out.
This however is very buggy and relies on a continuous counter that starts upon loading the page (in mounted()), which isn't correct anymore after hovering a few times.
It's maybe a bit of a complex story but I would like to know if there are other ways of implementing this functionality, or how to somehow be able to know the current progression of the transition.
I'm building this in Nuxt 3 (vue.js framework) using the vue swiperjs library.
Thanks in advance
Are there more than brush and opacity settings for a stylus in photoshop?
I recently hooked up a Huion 24" 4k display tablet to run with photoshop on my Windows PC. Works great so far but when adjusting values in the toolbars using the slider, the values have large steps. When i use the mouse it is normal. the steps are increments of one with the mouse but huge when using the stylus. It also varies depending on the toolbar slider. for example the
Clone Source toolbar (under the Window dropdown) when adjusting the values with the stylus the smallest % increment i can do is %80. so if i slide it all the way to 1 then move the slider over the next number is %81 then 161 and so on in increments of 80. Another toolbar, the brush angle, slides at %7 increments using the stylus and single digit increments when using the mouse.
I dont see it being a sensitivity or resolution issue as the steps are consistent within the slider but different depending on the slider. Anyone got any ideas?
Thanks in advance
Well, I was behind on one update for photoshop. updated and I am no longer having the issue.
I have a div that uses:
-webkit-clip-path: polygon(0 0, 100% 7%, 100% 100%, 0 100%);
clip-path: polygon(0 0, 100% 7%, 100% 100%, 0 100%);
And there is an image inside this div inside another div. Is there a reason why this specific code causes chrome performance to drop - scrolling becomes choppy too. In Firefox everything looks normal.
Strangely enough, it only affects scrolling when view is on that element, once you scroll past it looks fine again
Clip-Path GPU Rendering
clip-path uses the GPU for rendering, so it is likely to be a graphics card/driver issue or that your system was out of resources and unable to render it effectively.
Try viewing on other machines to see if the same problem exists.
To understand the performance issues and how to debug them these articles will help
Debugging a Canvas Element
Chrome allows you to profile and debug canvas elements from the
Developer Tools. It can be used for both 2D and WebGL canvas projects.
To be able to do this, you need to have enabled the "Experiments" tab.
If you haven't already, navigate to chrome://flags and enable the
option marked "Enable Developer Tools experiments". You'll need to
press "Relaunch Now" button at the bottom of the page to apply your
changes. Go to the Settings panel of Chrome Developer Tools by
clicking the cog on the bottom right. Click the "Experiments" tab and
check the option "Canvas inspection".
Now visit the "Profile" tab and you will see an option called "Capture
Canvas Frame". The Developer Tools may ask you to Reload the page to
use the canvas. Pressing "Start" captures a single frame of the canvas
application. Alternatively, you can click the box below to switch to
"Consecutive Frames" which allows for capture of multiple frames.
Chrome creates a log of each call to canvas, providing a list of each
call to the context and a screenshot. You can click one of the log
items to replay the frame in the Developer Tools and see which
commands were called in the order they were called and from which
line.
Firefox has Canvas and WebGL Shader debugger, giving you features to
inspect frames, fps, modify shaders and more.
In order to enable these tools, go to Devtools settings (the cog icon
in devtools) and check "Canvas" and "Shader Editor".
Picking Your Properties
Animation is not selecting a syntax, it’s designing the animation for
fast rendering. The difference between a smooth, life-like animation
and a janky, stuttery one is rarely as simple as CSS versus
JavaScript. Instead, it’s often determined by which properties or
attributes you animate, on which elements.
Regardless of whether you’re changing a style property with CSS or
with SMIL or with JavaScript, the browser needs to determine which
pixels on the screen need to be updated, and how.
If the DOM and style computation steps determine that no styles or SVG
rendering attributes have changed for any elements, the browser can
stop right there.
If the changed styles don’t affect layout (only painting), or if
layout has changed for some elements but not for others, the browser
has to determine which parts it needs to repaint. This region is known
as the “dirty” rectangle of the screen. Elements elsewhere on the
screen can be skipped, their pixels unchanged for this update.
The changed element usually needs to be repainted, but also maybe
others. Did the changed element overlap another element, which is now
revealed? If so, the browser may need to redraw that background
element.
But maybe not.
It depends on whether the browser has the original pixel data for the
background saved in memory. The graphical processing units (GPU) in
most modern computers and smartphones can keep a certain number of
rendering layers in memory, not just the final version that appears on
screen. The main browser program may also save partial images in
memory.
Much of browser rendering optimization comes down to how it selects
which parts of the rendered document to divide into separately cached
(saved) layers.
GPUs can perform certain operations on the cached rendering layers,
and are highly optimized for the limited number of operations they can
do.
If browsers know that an element is going to change in a way that can
be efficiently calculated by the GPU, they can save that image’s pixel
data in a different GPU layer from its background (or foreground). The
animated changes can therefore be applied by sending new instructions
to the GPU for how to combine the saved pixels, instead of by
calculating new pixel values in the main processor.
Tip Most browser Dev Tools now have options to highlight the “dirty”
paint rectangles whenever they are updated. If your animation is being
GPU-optimized, you won’t see any colored rectangles flashing when you
run this Dev Tools mode.
Of course, all GPU-optimized pathways are conditional on having a
compatible GPU available—and on the browser knowing how to use it,
which may depend on the operating system. So browser performance, and
sometimes even browser bugs, will depend not just on the browser
version but also on the OS and hardware.
Most GPUs can adjust opacity of the saved layers, and translate them
to different relative positions before combining them. They can also
perform image scaling, usually including 3D perspective scaling—but
the scaling is calculated on a pixel level, not a vector level, and
can cause a visible loss in resolution. More advanced GPUs can
calculate some filter operations and blend modes, and masking of one
image layer with an alpha mask layer.
Some GPUs also have optimized vector rasterization, which can
calculate high-resolution vector shapes for use as clipping paths of
other vector levels. These “clipping paths” aren’t only used for
clip-path effects, though. Filling and stroking a shape is clipping
the paint image layer to the fill-region or stroke-region vector
outline. Similarly, CSS border-radius effects are vector clipping
paths on the content and background image layers.
But you currently can’t rely on your end users having these optimized
pathways.
The best performance, across a wide range of browsers and hardwares,
comes from animations that can be broken into layers (of elements,
groups, or individual graphics) that are animated in the
following ways:
opacity changes
translational and rotational transformations
Warning Currently, Chrome never divides an SVG graphic into different
GPU layers (although they do other optimizations).
To create a fully GPU-optimized animation in Chrome, you can sometimes
position separate inline elements over top of each other,
creating your own layers.
If you can’t define your animation entirely in translation and opacity
layers, consider the following guidelines:
Minimize the size of the “dirty” rectangle at each frame.
Solid-color objects are better than semi-transparent ones, since the
browser doesn’t need to calculate pixel updates for shapes that can’t
be seen behind a solid object. (Although this may not apply if the
browser is using GPU layers for optimization.)
Moving elements around is more efficient than changing what they look
like. (Although it depends on the browser whether “moving around” only
applies to transform movements or also to other absolute position
changes.)
Changing fill and stroke is more efficient than changing shapes and
sizes.
Scaling transformations are better than changing the underlying
geometry; browsers may be able to use GPU image scaling for an
animated scale effect, instead of recalculating the vector image at
the correct resolution at each frame.
Clipping is usually more efficient than masking.
Avoid rescaling gradient and pattern layers; this could mean using
user-space effects instead of bounding-box effects, if the bounding
box is changing.
Avoid any changes that require a filter to be recalculated. That
includes any change to the filtered element or its child content.
I have an electron app which contains a canvas. I read 1280x720p video frames from the array and use webgl to display it sequentially on the canvas.
Everything works fine on a 60Hz display. When I move the app to external display running at 30Hz (refresh rate of 30), things slow down considerably. I have a css animation on top of canvas. If I remove that css animation, things look good again.
I am relying on requestAnimationFrame callback to invoke webgl draw. From my understanding, on 30Hz monitor requestAnimationFrame callback should get invoked 30 times every second. So I expected drawing to work at 30 fps. But each draw operation is taking around 120 ms. Due to this, drawing fps drops to mere 12-13 fps.
I suspect some sort of interference in rendering due to presence of continuous CSS animation (its a fading icon) on a 30Hz display.
Can somebody provide some insight on it.
Thanks in advance !
I'd like to see if it's possible to animate the input[type="range"] element for example for short audio files so the progress seems less 'stuttery'
Here's a codepen with a short audio file that I've been using to try to come up with solutions
This question is specifically for input[type="range"], I do not want to use custom elements to build animated progress bars, I know that is possible but for this particular use case I'm stuck with the range element.
Any ideas?
As the input handle is a browser element it can not be animated. You would have to build a slider similar to the jQuerUI one and then animate the handle by updating its position on the range change input.
If you have longer audio files this will not happen (about 1s of audio per pixel)