I have no idea what causes this, so I'll refine tags as some answers/comments start to guide me in the right direction.
Sometimes, images with monochrome stripey parts (whether the whole image is colour or not), exhibit a strange flashy effect as I scroll past them.
This is where I most recently saw it, in an article on Dezeen:
As I scroll past that image (with Chrome on OS X 10.9) the wall on the right goes darker and brighter, according to my rate of scroll.
If I get just the right scroll speed, it doesn't flicker - but it is in the 'dark mode', like someone in the scene has turned the lights off. If I speed up or slow down, it begins to flicker again - so I'm pretty sure it's not an optical elusion!
I saw it before with a couple of .gifs, I thought maybe it was a strange property of them. But the image above a is a .jpg.
What causes this effect?
I just tried to scroll this image down with my screen refresh rate at 60 Hz then 75 Hz: it seems to flicker more at 60 Hz... Maybe it's also due to display lag.
PS: You may have more precise answers here: http://physics.stackexchange.com
I think this is a Moiré optical illusion due to the wall's thin, closely put together horizontal lines, not anything to do with scrolling or display at all.
#SkipR's reply should have been the accepted answer.
Related
During a touch scroll (scroll triggered then released to not introduce noise in the velocity decay) the scroll isn't always very smooth.
By analyzing the performances we can see sporadic gaps (empty frames). It seems nothing is going on during that time (see the screen capture attached).
What can be the root cause of such issue?
capture of gaps during a single touch scrolling
I am trying to find a way to specify some antialiasing settings in three.js/WebGL to try and improve the results.
The thing is that with the exact same code, if I load a model on a Retina Display, the antialiasing works quite fine (even if I move it to my non-retina external monitor afterwards), but it's all pixelated if I load it first on a non-retina screen.
Here is a screenshot (both on Chrome, both displayed on a retina display). Left was loaded on a non-retina, right on a retina: https://i.imgur.com/krNavZU.png
What I get from this is that three.js somehow uses the pixel density when initializing the antialiasing. Is there anyway to tweak this so that I can force it to something better?
Thanks a lot in advance for your help :)
Side note: For the record, it seems that the antialiasing works much better on Firefox as well, anyone knows why?
Just in case someone is looking to do the same kind of tweaking I was trying, I'll answer my own question.
Based on WaclawJasper's comment, I found some documentation in Three.js related to my issue. From http://threejs.org/docs/#Reference/Renderers/WebGLRenderer:
.setPixelRatio ( value )
Sets device pixel ratio. This is usually used for HiDPI device to prevent blurring output canvas.
I was using renderer.setPixelRatio( window.devicePixelRatio ); in my initialization, which was the reason why the rendering was depending on where the page was first loaded.
Related to the antialiasing, I now artificially raise the pixel density using renderer.setPixelRatio(2); on non-retina screens. This results in a much more effective antialiasing, at the cost of increased computation.
I have noticed that when I view a image in a browser using either the zoom provided in the setting or on a webpage using style attributes the pixelation is either negligible or un noticable. But when you use programs such as paint or photoshop or windows picture viewer you start to notice pixelation. Does anyone know how the browser zoom its image contents?
Here is a sample image the one on right is from paint while one on left is when viewing in chrome. The zoom is set at 500%.
For fonts, I believe it has to do with font sizing. Okay, so say you are in a word processor and type something up you increase the font size the text gets bigger. A similar thing happens in a web browser when you zoom in.
On the other hand when you take an image the resolution is set so as you zoom in the the pixels become larger and more noticeable this is called aliasing. Many times a program or browser, etc. will try and smooth the edges in the image to make the pixels look less blocky to the eye, this is called anti-aliasing.
As far as the actual algorithms behind behind paint or a web browser go, I am unsure. It may take some more research to find out.
I would like to make a div move down on scroll but at a faster rate (i.e. if the user scrolls 200px down the div will smoothly scroll 400px down.)
Basically a fixed div that moves up and down at 2x (maybe less) rate of the scroll speed
I have searched a lot for an answer but no luck so I hope one of you bright minds can help me.
If you need me to be more specific I can make a video or an illustration that clarifies what I'm trying to do.
You are looking to do a parallax scrolling effect. There are lots of js libraries that can do this, one of them is: Stellar.js
Nike also made a temporary site (Better World) that had this effect.
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.