So I've got some native elements (divs) with various effects applied to them (border-radius, box-shadow and transform: scale()). When I animate them, two weird things happen:
Even though I'm not trying to animate the scale, if I don't put the scale in the animation, it is ignored.
When I put the scale in the animation, Webkit blurs the elements
See the example here: http://jsfiddle.net/trolleymusic/RHeCL/ - the buttons at the bottom will trigger the issues.
The first issue happens in Firefox too, so I'm guessing that it's because that's how the animation spec is supposed to work. Not what I wanted, but ok, I'll live with it.
The second issue is just weird. I know it's to do with 3d transform because if I (just for testing purposes) declare -webkit-perspective or -webkit-transform-style: preserve-3d; on the circle elements, it causes the blur issue as well. My confusion is that I'm not trying to transform the z index as all, and I have also tried the animations using purely translateY instead of translate.
It happens in Chrome (18), Chrome Canary (20) and Safari (5.1.2 & 5.1.4).
So, am I right in what I think is happening? And how can I avoid the blurriness?
Worst-case scenario: I can just use different sizes for the elements instead of scaling them, that's not really a problem - but I thought this would be a more elegant solution and now this issue has cropped up.
Refer to this answer as to why it's blurring the element: https://stackoverflow.com/a/4847445/814647
Summary of the above: WebKit is taking the original size/CSS before animating, and treating it as an image, THEN scales it up, producing the blurriness.
Solution: Make initial size the largest scale you're going to, and start it initially with a lower scale (so in your case you'd want to up the size by 5, and set the initial scale to 0.2)
UPDATE
The reason it ignores the current scale from what I understand is because you're not specifically setting JUST the translate (I'm looking up the CSS for it now). When you run -webkit-animation, it's resetting all your current transforms (scale), so you need to make sure that you have your scales in there. I'm looking up the css to change so it only changes just the position:
The best way I found is to wait the animation is complete, then apply the transforms directly to the element and remove the animation class. Something like this works for me, producing no glitches:
$m.bindOnce($m('win-text'), 'webkitAnimationEnd', function(){ //avoid blurred problem with animating scale property in webkit
$m('win-text').style.webkitTransform = 'scale(1.5) translateY(-60px)';
$m.removeClass($m('win-text'), 'final');
});
I'm using a different library than jQuery, but you get the idea.
Related
I'm working on a project that uses a lot of lines and marks with the camera at a very low angle (almost at ground level). I'm also using an outline effect to highlight selected objects in different ways (selection, collisions, etc.).
Native AA is lost when using postprocessing effects (eg: outline effect). This causes jagged lines on screen, more noticeable when the camera is closer to ground level.
I have created this jsFiddle to illustrate the issue (using ThreeJS r111):
https://jsfiddle.net/Eketol/s143behw/
Just press mouse/touch the 3D scene to render without postprocessing effects and release mouse/touch to render with it again.
Some posts suggest using an FXAAShader pass will solve it, but I haven't had any luck with it. Instead, I get some artifacts on the scene and in some cases the whole image is broken.
So far my options are:
Get a workaround to get the outline effects without postprocessing effects:
The ones I've seen around (eg: https://stemkoski.github.io/Three.js/Outline.html) duplicate the meshes/geometries to render a bigger version with a solid color applied behind the main object. While it may be ok with basic static geometries like a cube, it doesn't seem an efficient solution when using complex 3D objects that you need to drag around (objects with multiple meshes).
Increasing the renderer.pixelratio value to get a bigger frame size: This is not an option for me. On my test it doesn't make a big difference and also makes the rendering slower.
Try to get FXAAShader working without artifacts: As I said, it doesn't seem to fix the issue as well as the native AA does (and it is not as compatible). Maybe I'm not using it correctly, but I just get antialiased jagged lines.
Question 1: It may sound silly, but I though there would be an easy way to send the antialiased image directly to the composer or at least there could be some extra pass to do this, keeping the native AA. Is this possible?
Question 2: Maybe using Scene.onAfterRender to get the image with native AA and then blending the outline effect somehow?
Question 3: Googling around, it seems this issue also affects to Unity. In this post, it says this won't be an problem with WebGL2. Does this also apply to ThreeJS?
i am looking for a way to draw alot of paths fast in JavaFx8, the thing is I want to animate the paths.
I tried the standard path, polyline, I also tried drawing in an graphic context/canvas. But everything is just too slow.
In a test I am rotating around 200 Rectangles 1px wide and this works perfect, if I look in the pulselogger output I see that everything gets renderd within 16ms. In comparison if I draw 200 straight lines with the path node (same visual Output as 1px Rectangles) and animate this, i am getting very bad results and the paint task in the pulselogger shows 200ms.
I guess the problem is that the path is not drawn via OpenGl instead it falls back to SW renderning.
I use alot of lineTo() in the paths I want to render, so a very unelegant way would be to draw only the round stuff with the Path node and place a rectangle over the parts where I usualy use lineTo(). I guess this would speed things up alot, but this is very unflexible and hackish.
Is there anything else I can do to get the Paths rendert fast?
I already used setSmooth(false), caching is not an option as the paths get animated.
Final plattform should be Linux now developing on Mac
Thanks Robi
Currently JavaFX does all its path rendering in software and not in hardware and there is not much you can do about this especially if caching is not an option for you. The only possibility I see for you is to have a look at the 3D stuff. Maybe you can use a triangle mesh for your purposes. That's something I always wanted to try but never had the time to do :-)
In a design that I'm working on, there is a recurring image background shape that appears several times in different sizes throughout the site. For example, one page uses it as a huge background images, where the top and bottom part of this image is cut off by the browser edges.
It's not an easy pattern to create with canvas, but as far as I know it's possible. Here's what it looks like.
Am I better off making several images of this same pattern or is this background image easy to recreate through canvas? If it is appropriate for canvas, how do I go about recreating it in the various sizes? I wish I knew how to begin something like this using canvas but it's above my skillset.
I've converted your shape to an SVG shape here: https://gist.github.com/1321653 — use it as you'd like.
According to caniuse.com, SVG is supported on all common browsers except for IE8 and earlier.
For IE8 and earlier you might be able to combine canvg, a SVG-to-canvas library, with explorercanvas, a canvas emulator for IE8 and earlier. Or you could display a rectangle with a background color — IE users might not miss the splat.
Edit: You could also get creative with CSS3 background gradients, ala http://www.ecsspert.com/ (famous logos created with only CSS), but compatibility is low across browsers.
On the left is the original PNG and on the right are versions reduced to roughly half the original size using width and height.
Why does the resized image look so fuzzy in Firefox? Is there anything I can do about it without changing the image file? The fuzziness is particular annoying if the image contains large amounts of math or text.
I know this is late, but you can trick firefox into rendering the image better by applying a oh-so-slight rotation. I tried to translate() the image to get the same effect... to no avail.
CSS
.image-scale-hack {
transform: rotate( .0001deg );
}
Javascript
if( "MozAppearance" in document.documentElement.style ) {
$('.logo img').addClass('image-scale-hack');
}
I avoid browser sniffs at all cost. I borrowed this sniff from yepnope.js and I don't feel bad about it.
Also noteworthy, this same trick can be used to force sub-pixel image rendering in both webkit and firefox. This is useful for very slow animations - best explained by example:
http://jsfiddle.net/ryanwheale/xkxwN/
There is a longstanding bug ticket filed in Bugzilla related to Firefox image downscaling. You might like to keep an eye on the ticket to track its eventual resolution or contribute a patch yourself if you feel able to.
The best workaround is to use the transform CSS property to apply a tiny rotation to the problem image and force sub-pixel rendering, as detailed in Ryan Wheale's answer.
The image-rendering documentation linked from the Firefox blurs an image when scaled through css or inline style answer which Su' referenced includes instructions for using image-rendering:optimizeQuality (which corrected the issue in my testing on FF4) - example:
I think your answer is in the link from above https://developer.mozilla.org/En/CSS/Image-rendering:
'Currently auto and optimizeQuality are equal by default, both result in bilinear resampling.'
'default value IE8+: bicubic (high quality)'
Next see:
http://www.codinghorror.com/blog/2007/07/better-image-resizing.html
'When making an image smaller, use bicubic, which has a natural sharpening effect. You want to emphasize the data that remains in the new, smaller image after discarding all that extra detail from the original image.'
I can think of a couple of possible workarounds, but neither are simple:
Resize the image on the server. Either serve it up at half size, and allow Firefox to scale it up to full (which presumably it will be ok at), or have different URLs for the different sizes of image.
You may be able to make this work in the browser with plugins (but the example I found doesn't actually do what you need, so I've removed it).
TL;DR: Image scaling is not likely to be fixed soon. About anywhere.
Longer version:
Eris Brasseur has a page that deals nicely with the broader question "Why is just about any image scaling software so bad?"
http://www.ericbrasseur.org/gamma.html
Since W3C's position on this matter is roughly that it's better to have an incorrect but equally incorrect implementation everywhere, they shun any proper dealing with Gamma (which would complicate matters slightly). Thus anyone accustomed to web standards is likely to continue ignoring Gamma, leading to the effects described by Eric and in this thread. This ensures that even downscaling is far from being well-defined, as Jeff Atwood puts it in an Article linked in another answer.
In such an environment, methods like Lanczos thrive whose claim to fame is mostly that they perform quite well even if implemented incorrectly.
In other words, browsers are the software equivalent of McDonald's burgers, and that fact will stay. Its implications need not, but the odds are skewed.
Now (2017) the bug is closed 2 years ago. A short Test:
FF, 50%:
FF, 25%:
A workaround for this issue is just to resize the original image with an image editor to the desired size and to use the image as it is, without defining it's width and height in the style sheet.
By browser rendering performance I mean things like: scrolling, moving elements in animated fashion, z-order changes.
In particular I get tremendous slowdown in Firefox 3.6 and IE8 when I move an image with top, left styles over my page. I have no problems with Chrome 8.
With firebug I tried hiding page elements one by one and the largest improvent by far came from the page wide background Jpeg that I use. I wonder how is it affecting performance as the image is moving above another element that obscures the background. This another element is partly transparent PNG (but not in the part the movement happens), maybe this has something to do with it? I use a lot of transparency and CSS3 effects and somehow they slow down everything, even things that look completely unrelated.
Overall I get the impression that the browser is rerendering the whole page when something is moving, instead of only the affected pixels.
Any educated guess as to why all this happens?
EDIT Any picture or text that sits below my moving image causes it to slow down a lot when passing over it. The moving image itself is with transparent background, but changing it to opaque had almost no effect.
Moving a transparent element (particularly an element with a shadow) over a fixed background forces it to be recomposited every frame. Opaque shadowless elements on the other hand can be moved with a simple blit.
If you want to see a huge slowdown in most browsers, make a page with a bunch of elements with border-radius and box-shadow, then set the background of the page to background-attachment:fixed.