5 ms·

> how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? you don't need vdom to make this fas

> how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? you don't need vdom to make this fast. you compute your state in whatever data structure you like and then requestAnimationFrame updates the DOM if and where it is needed. VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW.

anonymoushn 4y ago
> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. It's funny to read this when Google Chrome has constant tearing on Windows.
- peoplefromibiza 4y ago
  Haven't used Chrome in years, but AFAIK screen tearing is caused by incorrect vsync settings. disabling HW acceleration can fix it because software rendering is synced to the screen refresh rate. if you rendered your web app in an animationFrame in the allotted time (60hz usually, 1/60 of a second) you won't notice any flickering or tearing even without double buffering. modern HW (screens and GPU) use complete frames, so flickering and tearing are not an issue if the writes are vsynced.
  - davrosthedalek 4y ago
    Vsync needs double buffering. You swap the buffers during vsync to kill tearing. You will have tearing whenever you update the currently scanned-out buffer (except when you do stuff like racing the beam).
Rapzid 4y ago
The vdom is the state that gets sync'd to the dom.
- peoplefromibiza 4y ago
  no, the VDom is a virtualization of the DOM structure in the form {tag, [attributes], [children]} but your application state could be whatever you want, it doesn't need to be in the same shape of the DOM the only problem VDom really helped with was DOM diffing, but browsers are fast enough nowadays that it's not a big issue anymore.
maccard 4y ago
> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. Double buffering still has a huge appeal on modern hardware - tearing. At 144Hz/fps, a single frame is 7ms, and at 30, a single frame is 33.3333ms - the margin for error is significantly lower. At high refresh rates, I'd rather an extra frames latency to tearing.
- peoplefromibiza 4y ago
  browsers have been doing smooth 60fps rendering for at least 5 years now, but you'll find stackoverflow threads about it dated 2015, they can do 144fps on much more powerful and better supported HW accelerated devices in 2022. or to make it more clear: VDom is unnecessary because the browser engines have adopted optimizations that made it obsolete, just like many rendering techniques are not used anymore because the HW implements them in a more efficient manner. For fast rendering speed in browsers, support for HW acceleration has done more than anything else combined.
  - PaulDavisThe1st 4y ago
    You're talking past the GP. Double buffering is still widely used by native code (e.g. inside the browser, inside video games, inside native toolkits). Ergo, "VDOM is obsolete the way that double buffering is" makes no sense. OTOH, "double buffering from code running in the browser is now obsolete" may make perfect sense, following changes in how the browser itself interacts with the HW.
    - peoplefromibiza 4y ago
      I think we're simply lost in translation, I'm no native speaker and sometimes I don't make myself clear. AFAIK (not worked on a game in years) double buffering, when I first heard about it, was used to overcome a limitation of the HW, we had graphic/video cards (when I started programming EGA was the standard), GPU did not exist, the amount of memory was limited, data transfers were slow, double buffering meant having two in memory buffers, the active one and the next one, being built in the background, that were alternatively sent to the graphic card. Then VGA added page flipping, you could write two buffers in the graphic card memory and instruct the card to swap the active page by flipping a bit in a register during vsync and then write the next frame in the inactive page. From then on things have improved exponentially, to the point that now GPUs can buffer multiple high res frames, so while frame N is being displayed, the CPU can elaborate frame N+1 or N+2 or even N+3 on some GPU. The framework configures the GPU to automatically swap frames (usually in a FIFO queue) on vsync. I think in Vulkan this workflow is called swapchain. HW implemented what was possible only in SW, double buffering is still in use of course, habits die hard, but the issue it solved is not remotely as bad as it used to be. VDom followed the same path, it was invented to overcome a browser's limitation: DOM access was painfully slow, especially on legacy browsers like IE. Now they are fast enough that VDom, even though technically still largely in use, is not an hard requirement to make fast DOM updates like it was 10 years ago. It stayed there in many frameworks, IMO, because you'll never know what HW/SW combination your users are running, backward compatibility, "if it ain't broke, don't fix it"

anonymoushn 4y ago

> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. It's funny to read this when Google Chrome has constant tearing on Windows.

peoplefromibiza 4y ago
Haven't used Chrome in years, but AFAIK screen tearing is caused by incorrect vsync settings. disabling HW acceleration can fix it because software rendering is synced to the screen refresh rate. if you rendered your web app in an animationFrame in the allotted time (60hz usually, 1/60 of a second) you won't notice any flickering or tearing even without double buffering. modern HW (screens and GPU) use complete frames, so flickering and tearing are not an issue if the writes are vsynced.
- davrosthedalek 4y ago
  Vsync needs double buffering. You swap the buffers during vsync to kill tearing. You will have tearing whenever you update the currently scanned-out buffer (except when you do stuff like racing the beam).

Rapzid 4y ago

The vdom is the state that gets sync'd to the dom.

peoplefromibiza 4y ago
no, the VDom is a virtualization of the DOM structure in the form {tag, [attributes], [children]} but your application state could be whatever you want, it doesn't need to be in the same shape of the DOM the only problem VDom really helped with was DOM diffing, but browsers are fast enough nowadays that it's not a big issue anymore.

maccard 4y ago

> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. Double buffering still has a huge appeal on modern hardware - tearing. At 144Hz/fps, a single frame is 7ms, and at 30, a single frame is 33.3333ms - the margin for error is significantly lower. At high refresh rates, I'd rather an extra frames latency to tearing.

peoplefromibiza 4y ago
browsers have been doing smooth 60fps rendering for at least 5 years now, but you'll find stackoverflow threads about it dated 2015, they can do 144fps on much more powerful and better supported HW accelerated devices in 2022. or to make it more clear: VDom is unnecessary because the browser engines have adopted optimizations that made it obsolete, just like many rendering techniques are not used anymore because the HW implements them in a more efficient manner. For fast rendering speed in browsers, support for HW acceleration has done more than anything else combined.
- PaulDavisThe1st 4y ago
  You're talking past the GP. Double buffering is still widely used by native code (e.g. inside the browser, inside video games, inside native toolkits). Ergo, "VDOM is obsolete the way that double buffering is" makes no sense. OTOH, "double buffering from code running in the browser is now obsolete" may make perfect sense, following changes in how the browser itself interacts with the HW.
  - peoplefromibiza 4y ago
    I think we're simply lost in translation, I'm no native speaker and sometimes I don't make myself clear. AFAIK (not worked on a game in years) double buffering, when I first heard about it, was used to overcome a limitation of the HW, we had graphic/video cards (when I started programming EGA was the standard), GPU did not exist, the amount of memory was limited, data transfers were slow, double buffering meant having two in memory buffers, the active one and the next one, being built in the background, that were alternatively sent to the graphic card. Then VGA added page flipping, you could write two buffers in the graphic card memory and instruct the card to swap the active page by flipping a bit in a register during vsync and then write the next frame in the inactive page. From then on things have improved exponentially, to the point that now GPUs can buffer multiple high res frames, so while frame N is being displayed, the CPU can elaborate frame N+1 or N+2 or even N+3 on some GPU. The framework configures the GPU to automatically swap frames (usually in a FIFO queue) on vsync. I think in Vulkan this workflow is called swapchain. HW implemented what was possible only in SW, double buffering is still in use of course, habits die hard, but the issue it solved is not remotely as bad as it used to be. VDom followed the same path, it was invented to overcome a browser's limitation: DOM access was painfully slow, especially on legacy browsers like IE. Now they are fast enough that VDom, even though technically still largely in use, is not an hard requirement to make fast DOM updates like it was 10 years ago. It stayed there in many frameworks, IMO, because you'll never know what HW/SW combination your users are running, backward compatibility, "if it ain't broke, don't fix it"