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
Related
I'm trying to implement a cross-platform UI library that takes as little system resource as possible. I'm considering to either use my own software renderer or opengl.
For stationary controls everything's fine, I can repaint only when it's needed. However, when it comes to implementing animations, especially animated blinking carets like the 'phase' caret in sublime text, I don't see a easy way to balance resource usage and performance.
For a blinking caret, it's required that the caret be redrawn very frequently(15-20 times per sec at least, I guess). On one hand, the software renderer supports partial redraw but is far too slow to be practical(3-4 fps for large redraw regions, say, 1000x800, which makes it impossible to implement animations). On the other hand, opengl doesn't support partial redraw very well as far as I know, which means the whole screen needs to be rendered at 15-20 fps constantly.
So my question is:
How are carets usually implemented in various UI systems?
Is there any way to have opengl to render to only a proportion of the screen?
I know that glViewport enables rendering to part of the screen, but due to double buffering or other stuff the rest of the screen is not kept as it was. In this way I still need to render the whole screen again.
First you need to ask yourself.
Do I really need to partially redraw the screen?
OpenGL or better said the GPU can draw thousands of triangles at ease. So before you start fiddling with partial redrawing of the screen, then you should instead benchmark and see whether it's worth looking into at all.
This doesn't however imply that you have to redraw the screen endlessly. You can still just redraw it when changes happen.
Thus if you have a cursor blinking every 500 ms, then you redraw once every 500 ms. If you have an animation running, then you continuously redraw while that animation is playing (or every time the animation does a change that requires redrawing).
This is what Chrome, Firefox, etc does. You can see this if you open the Developer Tools (F12) and go to the Timeline tab.
Take a look at the following screenshot. The first row of the timeline shows how often Chrome redraws the windows.
The first section shows a lot continuously redrawing. Which was because I was scrolling around on the page.
The last section shows a single redraw every few 500 ms. Which was the cursor blinking in a textbox.
Open the image in a new tab, to see better what's going on.
Note that it doesn't tell whether Chrome is fully redrawing the window or only that parts of it. It is just showing the frequency of the redrawing. (If you want to see the redrawn regions, then both Firefox and Chrome has "Show Paint Rectangles".)
To circumvent the problem with double buffering and partially redrawing. Then you could instead draw to a framebuffer object. Now you can utilize glScissor() as much as you want. If you have various things that are static and only a few dynamic things. Then you could have multiple framebuffer objects and only draw the static contents once and continuously update the framebuffer containing the dynamic content.
However (and I can't emphasize this enough) benchmark and check if this is even needed. Having two framebuffer objects could be more expensive than just always redrawing everything. The same goes for say having a buffer for each rectangle, in contrast to packing all rectangles in a single buffer.
Lastly to give an example let's take NanoGUI (a minimalistic GUI library for OpenGL). NanoGUI continuously redraws the screen.
The problem with not just continuously redrawing the screen is that now you need a system for issuing a redraw. Now calling setText() on a label needs to callback and tell the window to redraw. Now what if the parent panel the label is added to isn't visible? Then setText() just issued a redundant redrawing of the screen.
The point I'm trying to make is that if you have a system for issuing redrawing of the screen. Then that might be more prone to errors. Thus unless continuously redrawing is an issue, then that is definitely a more optimal starting point.
What does it mean, when you have slow frames (those ones indicated with red triangles) in Chrome Dev Tools' Timeline, but it doesn't show what causes that (script, render, composition, etc). It's like nothing really happens but you still have janks.
If you click on the time-span above the main thread, and then click on the Bottom-Up tab at the bottom, you can see all the individual activities going on that add up to that total time. I suspect there must be some other activities you can't currently see, but if you scroll vertically, you should see them - probably Rasterize Paint on another worker.
Update
I realised that the times in the Bottom-Up view do not add up to the total time shown for the frame. I did a little more playing and it looks as though the remaining time is 'Idle' time.
If you look at the screenshot below, I have adjusted the Timeline view to contain approximately one frame that has very minimal activity. It's a little bit more than one frame because you can see the dotted lines on either side are a little further in.
If you then look at the bottom Summary view, you can see the majority of time is listed as 'Idle'. If you pretend I more accurately filtered the Timeline view to be exactly one frame (by taking off a tiny bit of time from the summary values), you could probably fairly confidently come to the conclusion that the total frame time (shown just above the Main Thread bar) is the summation of the values shown in Summary, including the 'Idle' time.
I have a website with 3 full screen background images that use a custom parallax scrolling script utilizing requestAnimationFrame and transform:translate3d() for its animation. I did this because after a fair amount of research on the subject of visual performance this was the best alternative then using canvas.
My problem is that my page runs very smooth on Firefox 29.1 (*because it is most definitely using the computers GPU to render the page and composite layers) however for some reason, Chrome is has some major bottlenecks.
I am getting tremendous performance spikes (way less then 30fps) when I scroll down my page... but an interesting thing I noticed was that it happens specifically just as one of the background images that is being animated with the script (set as background-position:cover) enters into the viewport.
There is a repaint operation happening because the background image is being resized to fit the viewport width/height and that is causing a tremendous performance hit. Considering that the gpu isnt working correctly for my Chrome, but also that I would like to make my page perform super silky smooth when scrolling even without hardware acceleration, is there a method of preloading images/frames and having them already resized before they are scrolled onto screen? Like a frame buffering technique to ensure all the calculations and resizing is finished well before a user scrolls to that image on screen?
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.
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.