I have set up a scroll depth tracker in GTM to track how much visitors scroll down a webpage.
The code seems to work fine, but I don't understand the results.
For example, it shows:
10% scroll depth = 949 (14,34%)
20% scroll depth = 901 (13,61%)
30% scroll depth = 861 (13,01%)
40% scroll depth = 813 (12,28%)
A screenshot is attached below.
How should these lines be interpreted? First I imagined that only 14,3% of all visitors would scroll down 10%, but that would be literally only the header (which consists of a picture), so it's rather unlikely that people would leave that early.
How should these lines be interpreted?
Thank you!
Edit: Here is what the GA event looks like:
There are two things to consider. First, the behavior of the scroll tracking trigger in Google Tag Manager. Based on the support article:
The trigger will only fire once per threshold per page.
So the event will be generated for all thresholds reached, not just the lowest one. You should also be aware of this behavior:
If a specified scroll depth is visible in the viewport when the page
loads, the trigger will fire even though the user has not physically
scrolled the page.
Second, the behavior of the Google Analytics reports. The percentage you see, is the share of the current row's quantity compared to the total quantity, for a given column. So on your first image, 949 (number of events for 10 percent threshold) is 14,34% of all tracked scroll events, which is 6620.
Therefore, 100 percent threshold was reached 145 times, which is ~15,3% of 10% events. (It's not clear, if these are global figures for your site, or only a specific page was included, but you can filter your data accordingly.)
Related
I want to be able to display and close an image within a few miliseonds.
I generally understand how to do this for a few seconds, but how can I achieve accurate milisecond rendering?
What is the approach to ensure that I can be certain an image has only been open for 10 miliseconds or even 5 milisecond and that my monitor has indeed displayed this image (assuming I have for example a 240hz monitor).
From my limited understanding of a monitors refresh rate, a 240hz monitor may refresh the display 240 times a second which is around every 4 miliseconds. If I want to display something for 5 miliseconds, it's possible that more than half that time my monitor hasn't really been refreshing (therefore not displaying). Under that logic is it correct that I would need to display the image for around 4 or 8 miliseconds? Is there a way to synchronize my displays refresh rate with the output of my program?
I'm planning to do this in c++ although the language isn't too critical provided the problem can be solved. I haven't managed to find any sources on how to approach this sort of problem. Is there any direction to a solution for this sort of problem?
This sync'ing is known as V-sync (Vertical Sync), since displays are typically oriented in horizontal lines. That means an entire screen is shown after the last line is drawn, just before the next line at the top of the screen will be drawn. I.e. the V-sync event is the vertical wrap-around.
You need a game-oriented API like DirectX or OpenGL
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 started looking into the client side performance of my app using Chrome's Timeline tools. However, whilst I have found many articles on how to use them, information on how to interpret the results is more sparse and often vague.
Currently I am looking at scroll performance and attempting to hit 60FPS.
This screenshot show's the results of my most recent timeline recording.
As can be seen most frames are over 60 FPS and several are over 30 FPS.
If I zoom in on one particular frame - the one with duration 67.076ms I can see a few things:
the duration of the frame is 67ms, but aggregated time is 204ms
201ms of this time is spent painting BUT the two paint events in
this frame are of duration 1.327 ms and 0.106 ms
The total duration for the JS event, update layer tree and paint events is
only 2.4 ms
There is a long green hollow bar (rasterize Paint)
which lasts the duration of the frame and in fact starts before and
continues after it.
I have a few questions on this:
the aggregated time is far longer than the frame time - is it
correct to assume that these are parrallel processes?
the paint time for the frame (204ms) far exceeds the time for the two paint events (1.433ms) - is this because it includes the
rasterize paint events
why does the rasterize paint event span multiple frames?
where would one start optimizing this?
Finally can someone point me to some good resources on understanding this?
This is somewhat unfortunate result of the way the 'classic' waterfall Timeline view coalesces multiple events. If you expand that long "Rasterize Paint" event, you'll see a bunch of individual events, which are going to be somewhat shorter. You may really want to switch to Flame Chart mode for troubleshooting rendering performance, where the rasterize events are shown on appropriate threads.
I'm working with mouse events, specifically OnMouseWheel. Many code samples refer to distance the view changes (or zoom f.i. in 3D application) as Distance = Sign(WheelDelta)*Constant or Distance = WheelDelta / WHEEL_DELTA or something of that kind - assuming that WheelDelta is always a multiple of 120 (WHEEL_DELTA constant = 120).
I already found that in touch interfaces / tablets input may depend on scrolling length.
I was wondering why Microsoft has set default WheelDelta to 120, why not 100 or 10 or anything else? In what other cases wheel delta may be something different from 120?
The Qt Documentation elaborates a bit more on why it is actually 120:
QPoint QWheelEvent::angleDelta() const
Returns the distance that the wheel is rotated, in eighths of a degree. A
positive value indicates that the wheel was rotated forwards away from the
user; a negative value indicates that the wheel was rotated backwards toward
the user.
Most mouse types work in steps of 15 degrees, in which case the delta value is
a multiple of 120; i.e., 120 units * 1/8 = 15 degrees.
However, some mice have finer-resolution wheels and send delta values that are
less than 120 units (less than 15 degrees). To support this possibility, you
can either cumulatively add the delta values from events until the value of 120
is reached, then scroll the widget, or you can partially scroll the widget in
response to each wheel event.
https://doc.qt.io/qt-5/qwheelevent.html#angleDelta
WHEEL_DELTA is not fixed anymore to 120. As I understand it this constant was chosen to allow for finer resolutions in the future, which obviously is NOW.
See this article from MSDN
The question is marked as answered already I thought I might provide some more information.
If I understand correctly, WHEEL_DELTA is actually 40 not 120, the 120 comes from the mouse driver multiplying the raw WHEEL_DELTA value by the number of lines to scroll, which is by default 3. You can obtain the scroll line number using
My.Computer.Mouse.WheelScrollLines
This can most easily be seen using a NumericUpDown control, which on scroll adjusts the value by the increment multiplied by that line count.
Just messing with my wheel mouse, there are 18 detents in a full revolution, being 20 degrees per detent (Sure I know that's a small sample size of mouses in the world...!). 40 suggests they felt half degrees were fine enough though this last paragraph is supposition.
EDIT: Not one to spread misinformation, on further study WHEEL_DELTA is in fact 120, NumericUpDown proved to be a false positive. Nonetheless, the rest of the discussion is valid, if one can apply a factor of three to the logic.
As you have noticed laptop Touchpads can scroll (either two-finger or scroll zone on right hand size), in which case there can be lots of events with very small wheelDelta values (either needing integration, or perhaps timeouts to prevent too many redraws).
Also different OS's or configurations or devices can have different meanings for scrolling - pixels, lines, or pages. e.g. DOM event.deltaMode
Finally some devices (mice and touchpads) also allow horizontal scrolling.
The above is more specific to browser DOM events, but the same issues may apply to Win events too.
Edit:
From the Firefox MDN docs there are three events you are probably interested in: WM_MOUSEWHEEL, WM_MOUSEHWHEEL, and WM_GESTURE (panning on touch devices).
A search of the Mozilla Bugzilla database shows a variety of problems with some Symantics and ALPS touch drivers sending WM_VSCROLL instead of WM_MOUSEWHEEL (may be relevant if supporting touchpads).
If you want horizontal mouse scrolling support, this article from a flash dev says: [mousewheel support] was added in Vista so if you are using XP or 2000 you need IntelliType Pro and/or IntelliPoint installed for WM_MOUSEHWHEEL support.
#Krom: more speculations and loose facts but maybe useful to others :-)
Is there a standard Aqua way to handle a practically infinite document?
For example, imagine a level editor for a tile-based game. The level has no preset size (though it's technically limited by NSInteger's size); tiles can be placed anywhere on the grid. Is there a standard interface for scrolling through such a document?
I can't simply limit the scrolling to areas that already have tiles, because the user needs to be able to add tiles outside that boundary. Arbitrarily creating a level size, even if it's easily changeable by the user, doesn't seem ideal either.
Has anyone seen an application that deals with this problem?
One option is to essentially dynamically expand the area as the user scrolls through it - any time the user scrolls within X units of an edge, add another unit in that direction. Essentially, you'll never be able to scroll "all the way" to an edge, because the closer you get the farther it will expand.
If the user scrolls back away from the edge, contract it to back to no more than X units beyond where there is actually content.
Have you seen what Microsoft Excel does for this problem? It has to represent an unbounded space with scrollbars, as well.
One solution is to define a reasonable space for the original level size, and when the user scrolls to one tile away from its bounds, add another row or column of tiles, and adjust the scrollbar accordingly. This way, the user never reaches the actual bounds.
If the user decides to cut down on the level size, you could also add code that shrinks the "reasonable space" once an unused row consists only of empty tiles. This saves the user from being stuck with a huge level that they scrolled through, with no way to shrink it.
Edit: Same as Dav's answer. :)