Products > Test Equipment

Most (Digital-)Scopes are freezing while vertical adjustement...

<< < (10/10)

tooki:

--- Quote from: nctnico on November 15, 2022, 11:50:30 am ---
--- Quote from: JPortici on November 15, 2022, 07:03:08 am ---As i wrote in another thread
"like the "zoom out quirk"

it's really incredible what people fixate on. It's just another non issue.

--- End quote ---
I don't think you fully understand what is going on. What the Rigol seems to be doing is wait until the DSO thinks the user is done adjusting the vertical position for so long that it is perceived as lag. The magic number for humans to experience something without delay is somewhere between 100ms and 200ms. Wait longer, and it is perceived as laggy. So for a fluent user experience (which isn't a non issue!) it is better for a DSO to just try to put traces on the screen while the vertical position is adjusted. This helps both giving visual feedback to the user and prevent perceived lag.

Actually, this makes me wonder whether there is a similar lag / delay on the Rigol when you change the trigger level.

--- End quote ---
100-200ms are the absolute rock-bottom response times for a UI to not feel sticky like taffy. But if the intent is smooth motion, then sub-10ms response times are desirable. For example, when scrolling on a touch screen. It’s ok if tapping a button then takes 100ms to display the next screen. But if you use a finger to scroll, 100ms is an eternity. A stylus responding in 10ms instead of 100ms is the difference between it feeling like a pen vs feeling artificial. There’s a reason high end mobile touchscreen devices use 120Hz displays (8.3ms). (We can easily see the difference over 60Hz when tracking a fast object around the screen, like during scrolling.) It’s also why mobile OSes don’t rely on re-rendering in real time during pinch-to-zoom: they scale a screenshot (easily done with the scaler in the GPU) and then re-render any time you stop moving. Admittedly with recent models, rendering is so fast that they can keep up in most situations. The transition from GPU-scaled-bitmap to the re-rendered page happens so seamlessly we don’t even notice. (You can provoke this on iOS in Safari by pinch-to-zooming in as close as possible. Then try to zoom in more: it won’t re-render at all beyond the maximum zoom, and you can see some blurriness as it scales the bitmap of the maximum zoom level.) But I remember on the original iPhone (which had less than 1% the raw CPU power of the latest ones), operating on the bitmap “proxies” and other tricks (like tiled rendering) were absolutely critical to UI responsiveness, which is why they wrote an entirely new graphics engine focused on user interface responsiveness.

People “obsess” over it because it matters.

2N3055:

--- Quote from: tooki on November 23, 2022, 12:00:18 am ---
--- Quote from: nctnico on November 15, 2022, 11:50:30 am ---
--- Quote from: JPortici on November 15, 2022, 07:03:08 am ---As i wrote in another thread
"like the "zoom out quirk"

it's really incredible what people fixate on. It's just another non issue.

--- End quote ---
I don't think you fully understand what is going on. What the Rigol seems to be doing is wait until the DSO thinks the user is done adjusting the vertical position for so long that it is perceived as lag. The magic number for humans to experience something without delay is somewhere between 100ms and 200ms. Wait longer, and it is perceived as laggy. So for a fluent user experience (which isn't a non issue!) it is better for a DSO to just try to put traces on the screen while the vertical position is adjusted. This helps both giving visual feedback to the user and prevent perceived lag.

Actually, this makes me wonder whether there is a similar lag / delay on the Rigol when you change the trigger level.

--- End quote ---
100-200ms are the absolute rock-bottom response times for a UI to not feel sticky like taffy. But if the intent is smooth motion, then sub-10ms response times are desirable. For example, when scrolling on a touch screen. It’s ok if tapping a button then takes 100ms to display the next screen. But if you use a finger to scroll, 100ms is an eternity. A stylus responding in 10ms instead of 100ms is the difference between it feeling like a pen vs feeling artificial. There’s a reason high end mobile touchscreen devices use 120Hz displays (8.3ms). (We can easily see the difference over 60Hz when tracking a fast object around the screen, like during scrolling.) It’s also why mobile OSes don’t rely on re-rendering in real time during pinch-to-zoom: they scale a screenshot (easily done with the scaler in the GPU) and then re-render any time you stop moving. Admittedly with recent models, rendering is so fast that they can keep up in most situations. The transition from GPU-scaled-bitmap to the re-rendered page happens so seamlessly we don’t even notice. (You can provoke this on iOS in Safari by pinch-to-zooming in as close as possible. Then try to zoom in more: it won’t re-render at all beyond the maximum zoom, and you can see some blurriness as it scales the bitmap of the maximum zoom level.) But I remember on the original iPhone (which had less than 1% the raw CPU power of the latest ones), operating on the bitmap “proxies” and other tricks (like tiled rendering) were absolutely critical to UI responsiveness, which is why they wrote an entirely new graphics engine focused on user interface responsiveness.

People “obsess” over it because it matters.

--- End quote ---

Yeah but confused what is being talked about here. Screen elements are being refreshed at very fast rate with a frozen capture... Full real time movements. And then you lift finger and then if it restarts capturing new data in 100 ms you won't see the difference. ANd even if there is a fractional perceptive delay, on order of 200-400 ms before it goes on it is not a problem because your attention needs some time to start thinking about what you are doing...
That is the delay we are talking about. At least I am.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod