Making a Clean Horizontal Parallax Gallery: From DOM to WebGL

Horizontal scroll galleries with parallax results have develop into a staple of recent net design. You’ve most likely seen numerous tutorials on this impact, and for good purpose. It’s visually hanging and provides depth to what would in any other case be a easy picture carousel.

However right here’s the factor: most implementations are purely DOM-based, utilizing CSS transforms and JavaScript to maneuver components round. Whereas this works tremendous for easy instances, it may well shortly develop into janky whenever you’re coping with a number of pictures, heavy parallax calculations, and {smooth} animations all working on the primary thread.

You’ve most likely come throughout Camille Mormal’s portfolio a surprising instance of how fluid and performant a horizontal gallery may be. What units it aside? It’s all rendered in WebGL. The smoothness comes from offloading the heavy lifting to the GPU, the place these operations thrive.

This acquired me considering: what if we may construct this impact step-by-step, beginning with a conventional 2D DOM method after which elevating it to WebGL? Not solely would this present the efficiency advantages, however it will additionally demystify how these results really work underneath the hood.

On this tutorial, we’ll create a horizontal parallax gallery in two methods:

The 2D method: utilizing HTML, CSS, and JavaScript with customized {smooth} scrolling and parallax transforms
The WebGL method: utilizing Three.js to render all the pieces on the GPU with shader-based parallax for buttery-smooth efficiency

We’ll maintain dependencies minimal (solely Three.js for the 3D half) and give attention to understanding the core mechanics: how {smooth} scrolling works, how parallax is calculated, and the way to synchronize DOM measurements with WebGL rendering.

Let’s dive in.

The Preliminary Setup

For this tutorial, we’ll maintain issues easy and targeted. No complicated construct instruments or heavy dependencies simply Vite for quick improvement and Three.js for the WebGL half in a while.

Venture construction

Right here’s what our undertaking appears like:

├── css/
│   └── base.css
├── public/
│   ├── 1.webp
│   ├── 2.webp
│   └── ... (10 pictures whole)
├── src/
│   ├── gallery/
│   │   └── gallery.css
│   ├── utils/
│   │   └── math.ts
│   └── principal.ts
├── index.html
└── package deal.json

Dependencies

{
  "dependencies": {
    "three": "^0.170.0"
  },
  "devDependencies": {
    "typescript": "^5.6.3",
    "vite": "^6.0.3",
    "vite-plugin-glsl": "^1.3.0"
  }
}

That’s it. We’re utilizing:

Vite for bundling and dev server
TypeScript for kind security
Three.js (we’ll add this later for the WebGL model)
vite-plugin-glsl to import shader information (additionally for later)

HTML Construction

Let’s begin with the markup for our gallery. It’s intentionally easy, a wrapper and a container with pictures:

<physique class="demo-1 loading">
  <principal>
    <div class="content material">
      <div class="gallery__wrapper">
        <div class="gallery__image__container">
          <image class="gallery__media">
            <img
              src="1.webp"
              alt="Picture 1"
              class="gallery__media__image"
              draggable="false"
            />
          </image>
          <image class="gallery__media">
            <img src="2.webp" alt="Picture 2" class="gallery__media__image" draggable="false" />
          </image>
          <!-- ... 8 extra pictures -->
        </div>
      </div>
    </div>
  </principal>
  <script kind="module" src="/src/principal.ts"></script>
</physique>

Just a few issues to notice:

The loading class on the physique, we’ll take away this as soon as pictures are preloaded
draggable="false" prevents the default drag habits
We’re wrapping pictures in <image> tags for flexibility (may add totally different sources later)

Base CSS

The CSS does many of the heavy lifting for structure. Right here’s the important construction:

.gallery__wrapper {
  peak: 100vh;
  width: 100vw;
  overflow: hidden;
  place: relative;
}

.gallery__image__container {
  show: flex;
  hole: 2rem;
  peak: 100%;
  width: max-content;
  will-change: remodel;
}

.gallery__media {
  place: relative;
  overflow: hidden;
  peak: 60vh;
  aspect-ratio: 4 / 3;
  flex-shrink: 0;
}

.gallery__media__image {
  place: absolute;
  high: 0;
  left: 0;
  width: 100%;
  peak: 100%;
  object-fit: cowl;
  will-change: remodel;
}

Key particulars:

.gallery__wrapper is our viewport, it hides overflow
.gallery__image__container makes use of show: flex and width: max-content so it expands primarily based on content material
will-change: remodel hints to the browser that we’ll be reworking these components (optimization)
Every picture wrapper (.gallery__media) has overflow: hidden that is essential for the parallax impact later. The pictures inside will transfer, however the container clips them.

Establishing TypeScript

We’ll create a easy utility file for math features we’ll want:

// src/utils/math.ts

export perform lerp(begin: quantity, finish: quantity, issue: quantity): quantity {
  return begin * (1 - issue) + finish * issue;
}

export perform clamp(min: quantity, max: quantity, worth: quantity): quantity {
  return Math.max(min, Math.min(max, worth));
}

These two features are important:

lerp (linear interpolation): easily transitions from one worth to a different. That is what makes our scroll really feel buttery {smooth} as an alternative of immediate.
clamp : restricts a worth between a min and max. We’ll use this to forestall scrolling past the gallery bounds.

For now, we must always have one thing like this :

Constructing the 2D Model

Now that we’ve our HTML and CSS in place, let’s carry this gallery to life with customized horizontal scrolling. We’re going to construct all the pieces from scratch to grasp precisely what’s taking place underneath the hood.

Customized Clean Scrolling

Right here’s the factor about default browser scroll: it’s both too snappy or not {smooth} sufficient, and you’ll’t simply management its habits. For a sophisticated gallery expertise, we want full management.

Let’s create our App class in principal.ts:

// src/principal.ts
import "./gallery/gallery.css";
import { clamp, lerp } from "./utils/math";

interface Scroll {
  present: quantity;
  goal: quantity;
  ease: quantity;
  restrict: quantity;
}

class App {
  container: HTMLElement | null;
  wrapper: HTMLElement | null;
  scroll: Scroll;

  constructor() {
    this.container = doc.querySelector(".gallery__image__container");
    this.wrapper = doc.querySelector(".gallery__wrapper");
    this.scroll = {
      present: 0,
      goal: 0,
      ease: 0.07,
      restrict: 0,
    };

    this.setLimit();
    this.addEventListeners();
    this.render();
  }

  setLimit()  !this.wrapper) return;
    this.scroll.restrict = this.container.scrollWidth - this.wrapper.clientWidth;
  

  onWheel(e: WheelEvent) {
    this.scroll.goal += e.deltaY;
  }

  onResize() {
    this.setLimit();
  }

  addEventListeners() {
    window.addEventListener("resize", this.onResize.bind(this), {
      passive: true,
    });
    window.addEventListener("wheel", this.onWheel.bind(this), {
      passive: true,
    });
  }

  render() {
    this.scroll.goal = clamp(0, this.scroll.restrict, this.scroll.goal);

    this.scroll.present = lerp(
      this.scroll.present,
      this.scroll.goal,
      this.scroll.ease,
    );

    if (this.container) {
      this.container.model.remodel = `translateX(${-this.scroll.present}px)`;
    }

    requestAnimationFrame(this.render.bind(this));
  }
}

new App();

Breaking it down

The Scroll object:

scroll: {
  present: 0,    // The place we're proper now
  goal: 0,     // The place we need to be
  ease: 0.07,    // How briskly we interpolate (decrease = smoother however slower)
  restrict: 0,      // Most scroll distance
}

That is the guts of {smooth} scrolling. As a substitute of leaping on to the scroll place, we regularly transfer present towards goal utilizing lerp().

Setting the scroll restrict:

setLimit() {
  this.scroll.restrict = this.container.scrollWidth - this.wrapper.clientWidth;
}

This calculates how far we are able to scroll. scrollWidth is the entire width of all pictures plus gaps, and we subtract the viewport width to get the utmost scroll distance.

Capturing wheel occasions:

onWheel(e: WheelEvent) {
  this.scroll.goal += e.deltaY;
}

Once you scroll your mouse wheel, we add the delta to our goal place. Discover we’re utilizing deltaY (vertical scroll) however making use of it horizontally, this feels extra pure than forcing customers to scroll sideways.

The render loop:

render() {
  // Clamp goal to legitimate vary
  this.scroll.goal = clamp(0, this.scroll.restrict, this.scroll.goal);

  // Easily interpolate present towards goal
  this.scroll.present = lerp(
    this.scroll.present,
    this.scroll.goal,
    this.scroll.ease,
  );

  // Apply remodel
  if (this.container) {
    this.container.model.remodel = `translateX(${-this.scroll.present}px)`;
  }

  requestAnimationFrame(this.render.bind(this));
}

This runs 60 instances per second (or at your monitor’s refresh charge). Every body:

We clamp the goal to forestall scrolling out of bounds
We lerp present towards goal by the convenience issue (7%)
We apply the remodel to maneuver the gallery

Why lerp makes it {smooth}: Let’s say goal is 1000 and present is 0. With ease = 0.07:

Body 1: present = 0 + (1000 - 0) * 0.07 = 70
Body 2: present = 70 + (1000 - 70) * 0.07 = 135.1
Body 3: present = 135.1 + (1000 - 135.1) * 0.07 = 195.6
…and so forth

It begins quick and slows down because it approaches the goal that’s the sleek, eased movement you are feeling.

The outcome

At this level, you might have a completely practical horizontal scroll gallery with buttery {smooth} interpolation. Strive scrolling, discover the way it glides as an alternative of snapping? That’s the facility of lerp.

However we’re not achieved but. Let’s add the parallax impact to make it actually particular.

Including the Parallax Impact

Now comes the magic half. Parallax creates depth by making pictures transfer at totally different speeds relative to the scroll. However right here’s what most tutorials don’t clarify effectively: parallax requires each CSS and JavaScript working collectively, and understanding how they join is important.

The CSS Setup (Vital!)

Right here’s the CSS that makes parallax really doable:

.gallery__media {
  place: relative;
  overflow: hidden;  /* Clips the outsized picture */
  peak: 60vh;
  aspect-ratio: 4 / 3;
  flex-shrink: 0;
}

.gallery__media__image {
  place: absolute;
  high: 0;
  left: -12.5%;      /* Begin offset to the left */
  width: 125%;       /* Make picture BIGGER than container */
  peak: 100%;
  object-fit: cowl;
  will-change: remodel;
}

That is the muse of all the impact. Let me clarify why every worth issues:

Making the picture bigger:

width: 125%;

The picture is 25% wider than its container. This further area is what permits the picture to maneuver. Consider it like this: if the picture was precisely 100% width, there’d be no room for it to shift left or proper with out displaying empty area.

By making it 125%, we’re making a “buffer zone”, 12.5% on all sides that the picture can slide into.

Offsetting the beginning place:

left: -12.5%;

We place the picture 12.5% to the left of its container’s left edge. This facilities the additional width we created. With out this, the picture would begin flush left, and we’d solely be capable of parallax in a single route.

With this offset:

The picture has 12.5% hidden on the left
The picture has 12.5% hidden on the correct
The seen portion is centered
We will now transfer the picture each instructions because it scrolls via the viewport

Why these particular values?

The mathematics is straightforward: in case your picture is 125% broad (25% further), you break up that further area in half: 25% / 2 = 12.5%. This creates equal motion vary in each instructions.

Desire a stronger parallax impact? Improve each values proportionally:

width: 150% and left: -25% → extra dramatic motion
width: 115% and left: -7.5% → extra refined impact

Simply bear in mind: left ought to all the time be (width - 100%) / 2 to maintain it centered.

The clipping container:

overflow: hidden;

With out this, you’d see the outsized picture bleeding out of its container, breaking all the structure. The mum or dad acts as a “window” that clips the picture to the supposed measurement, whereas the picture itself can shift round inside that window.

How CSS and JavaScript Work Collectively

Right here’s the important thing connection:

CSS units up the playground → The picture is 125% broad with a -12.5% offset, giving it room to maneuver inside its clipped container
JavaScript strikes the picture inside that area → As we scroll, we calculate every picture’s place and apply transforms
The outcome → The picture shifts horizontally inside its fixed-size container, creating the parallax phantasm

With out the CSS sizing and positioning, the JavaScript would have nowhere to maneuver the picture. With out the JavaScript, the CSS would simply present a static, offset picture.

The JavaScript Implementation

Now let’s add the parallax impact to our App class:

import './gallery.css';

export class Gallery {
  container: HTMLElement | null;
  wrapper: HTMLElement | null;
  pictures: NodeListOf<HTMLElement>;

  constructor() {
    this.container = doc.querySelector('.gallery__image__container');
    this.wrapper = doc.querySelector('.gallery__wrapper');
    this.pictures = doc.querySelectorAll('.gallery__media__image');
  }

  non-public clamp(v: quantity, min: quantity, max: quantity) {
    return Math.max(min, Math.min(max, v));
  }

  applyParallaxEffect() {
    const vw = window.innerWidth;
    const viewportCenter = vw * 0.5;

    this.pictures.forEach((picture) => {
      const mum or dad = picture.parentElement as HTMLElement;
      if (!mum or dad) return;

      const rect = mum or dad.getBoundingClientRect();
      const elementCenter = rect.left + rect.width * 0.5;

      // -1 (far left) .. 0 (heart) .. 1 (far proper)
      const t = this.clamp((elementCenter - viewportCenter) / viewportCenter, -1, 1);

      // For 125% picture width, protected max translate ~= 10% of picture width
      const MAX_SHIFT = 10;
      const shift = -t * MAX_SHIFT; // damaging for counter-motion depth

      picture.model.remodel = `translate3d(${shift}%, 0, 0)`;
    });
  }

  render(container: HTMLElement, scroll: quantity) {
    container.model.remodel = `translateX(${scroll < 0.01 ? 0 : -scroll}px)`;
    this.applyParallaxEffect();
  }
}

Breaking Down the Parallax Calculation

Let’s dissect applyParallaxEffect() line by line and see the way it connects to our CSS:

applyParallaxEffect() {
  const vw = window.innerWidth;
  const viewportCenter = vw * 0.5;

  // With CSS: picture width = 125% => further = 25% => 12.5% all sides.
  // translateX(%) is relative to IMAGE width (125%), so protected max ≈ 12.5/125 = 10%.
  const MAX_SHIFT = 10; // %

  this.pictures.forEach((picture) => {
    const mum or dad = picture.parentElement as HTMLElement;
    if (!mum or dad) return;

    const rect = mum or dad.getBoundingClientRect();
    const elementCenter = rect.left + rect.width * 0.5;

    // -1..1 because the aspect strikes throughout the viewport
    const t = (elementCenter - viewportCenter) / viewportCenter;
    const clamped = Math.max(-1, Math.min(1, t));

    // Counter-motion: aspect proper => picture shifts left, and so forth.
    const shift = -clamped * MAX_SHIFT;

    picture.model.remodel = `translate3d(${shift}%, 0, 0)`;
  });
}

Step 1: Get the container’s place in viewport

const rect = mum or dad.getBoundingClientRect();

getBoundingClientRect() tells us the place every picture container sits relative to the viewport, and we use it to compute the aspect’s heart place.

Getting into from proper: rect.left is giant (e.g. > viewport width)
Centered: the aspect’s heart is close to the viewport heart
Exiting left: rect.left turns into damaging

Step 2: Compute distance from the viewport heart

const elementCenter = rect.left + rect.width * 0.5;

We use the viewport heart because the reference level, so the parallax is strongest close to the middle and naturally eases towards the sides—with out counting on an arbitrary 25% offset.

Step 3: Calculate and apply the parallax

picture.model.remodel = `translate3d(${shift}%, 0, 0)`;

Right here’s the place the magic occurs:

We compute a normalized place t within the vary [-1, 1] primarily based on the aspect’s heart relative to the viewport heart
The damaging is essential: because the aspect strikes proper, the picture shifts left (counter-motion), creating depth
We map t to a bounded share shift (e.g. ±10%) so the impact is constant throughout viewports
The certain ensures the motion stays contained in the CSS buffer, so that you received’t reveal empty area

Connecting again to CSS:

Bear in mind, our picture is:

125% broad
Positioned at -12.5% left
Has 12.5% hidden on all sides

The JavaScript remodel shifts the picture inside that further 25% of width. Since translateX(%) is relative to the picture width (125%), translateX(-10%) strikes the picture by 10% of its personal width, which is 12.5% of the container width—precisely the hidden buffer on all sides.

Adjusting the impact depth:

Wish to modify the parallax energy? Change MAX_SHIFT (the utmost translate in %):

MAX_SHIFT = 4 → refined
MAX_SHIFT = 8 → medium
MAX_SHIFT = 10 → max-safe for width: 125%

If MAX_SHIFT is just too excessive on your CSS sizing, you’ll reveal the feel edges—so both decrease MAX_SHIFT or improve the CSS buffer (e.g. wider picture).

What’s Truly Taking place

Let’s hint via an instance:

Think about a container at left = 800px (proper of heart):

Compute normalized place: t = (elementCenter - viewportCenter) / viewportCenter
Clamp to [-1, 1]
Apply bounded shift: shift = -t * MAX_SHIFT

Instance (1920px broad viewport):
If the aspect’s heart is 320px proper of the viewport heart:

t = 320 / 960 = 0.333
shift = -0.333 * 10% ≈ -3.33%
Remodel: translate3d(-3.33%, 0, 0)

As a result of the picture is 125% broad and positioned at -12.5%, this -3.33% remodel shifts it barely left inside its container, creating the phantasm that it’s on a distinct depth aircraft.

Because the container strikes left (scroll will increase):

Because the aspect strikes throughout the viewport, t strikes towards 0 (heart) and modifications signal previous heart, so shift easily strikes in the wrong way (counter-motion).
This counter-movement at a distinct charge creates the parallax depth impact

The Full Image: CSS + JS

The parallax impact is unattainable with out each layers:

CSS creates the bodily area → 125% width + -12.5% offset = 25% room to maneuver
CSS clips the outcome → overflow: hidden hides the additional width
JavaScript calculates place → Makes use of viewport place to find out how a lot to shift
JavaScript applies remodel → Strikes the picture throughout the area CSS created

Take away the CSS sizing? No room to maneuver, no impact. Take away the JavaScript? Static picture, no parallax. Take away overflow: hidden? Structure breaks utterly.

They’re inseparable.

Efficiency Concerns

You would possibly surprise: “Isn’t calling getBoundingClientRect() and setting types in a loop each body costly?”

Sure and no. Right here’s why this method works effectively:

What makes it performant:

will-change: remodel tells the browser to optimize for remodel modifications, typically selling the aspect to its personal compositor layer. This implies the browser prepares for frequent remodel updates.
remodel is GPU accelerated and operates on the composite layer. Not like properties like high, left, or margin, transforms don’t set off structure recalculations or repaints, solely compositing, which is extraordinarily quick.
getBoundingClientRect() is comparatively low-cost whenever you’re not inflicting structure thrashing. Since we’re studying all positions first, then writing transforms, we keep away from the read-write-read-write sample that forces synchronous structure.

Once you would possibly have to optimize:

For 10-15 pictures (like in our gallery), this method runs buttery {smooth} at 60fps. Nevertheless, when you had been coping with 50+ pictures or concentrating on low-end cellular gadgets, you’d need to optimize by:

Solely calculating parallax for pictures at the moment in or close to the viewport
Utilizing Intersection Observer to trace which pictures are seen
Debouncing or throttling calculations on slower gadgets

However for many sensible use instances, this simple method is completely performant. The bottom line is understanding what triggers structure/paint/composite and sticking to GPU-accelerated properties.

Et voilà ! You now have a completely practical 2D parallax gallery with {smooth} scrolling and optimized transforms. The mix of correctly sized CSS containers and body by body place calculations creates a sophisticated, skilled impact.

However right here’s the factor: we’re nonetheless doing all of this on the CPU, manipulating the DOM each body, and calling getBoundingClientRect() for every picture. What if we may offload this to the GPU solely and make it even smoother? That’s the place WebGL is available in.

Elevating to WebGL

Alright, our 2D model works nice. However keep in mind that silky {smooth} feeling from Camille Mormal’s web site? That comes from rendering all the pieces on the GPU with WebGL. Let’s carry Three.js into the image.

First, let’s set up Three.js:

npm set up three

Now, let’s begin including WebGL to our principal.ts. We’ll want a renderer, a scene, a digicam…

import * as THREE from 'three';

class App {
  container: HTMLElement | null;
  wrapper: HTMLElement | null;
  pictures: NodeListOf<HTMLElement>;
  scroll: Scroll;
  
  // WebGL stuff
  renderer!: THREE.WebGLRenderer;
  scene!: THREE.Scene;
  digicam!: THREE.PerspectiveCamera;
  // ... and we'll want meshes for every picture
  // ... and supplies
  // ... and textures
  // ... and replace logic for every mesh

  constructor() {
    // ... all our current scroll code
    // ... plus all of the WebGL initialization
    // ... plus mesh creation for every picture
    // ... plus synchronization logic
  }

  applyParallaxEffect() {
    // Maintain this for 2D model
  }

  updateWebGLParallax() {
    // New parallax for 3D model
  }

  render() {
    // Deal with each 2D and 3D rendering
    // That is getting messy...
  }
}

Wait… our principal.ts is about to blow up. We’re mixing scroll logic, 2D DOM manipulation, WebGL scene setup, per-mesh updates, and rendering multi functional class. That is going to be unreadable.

Refactoring for Sanity

Let’s take a step again. We have to separate issues earlier than this turns into unmaintainable. Right here’s what we really want:

principal.ts → The orchestrator

Handles scroll state (works for each 2D and 3D)
Detects which model to load (DOM vs WebGL)
Coordinates all the pieces

gallery/index.ts → The 2D implementation

Takes a container and scroll worth
Handles all DOM primarily based parallax logic
Self contained, reusable

gallery/GL.ts → The WebGL scene supervisor

Units up renderer, scene, digicam
Creates all of the meshes
Handles resize

gallery/GLMedia.ts → Particular person WebGL picture

One occasion per picture
Manages its personal mesh, materials, texture
Handles its personal place and parallax updates

This separation means:

Every file has one clear accountability
We will work on 2D or 3D independently
The code is testable and maintainable
principal.ts stays clear and readable

Right here’s the refactored principal.ts:

// src/principal.ts
import { Gallery } from "./gallery";
import { GL } from "./gallery/GL";
import { clamp, lerp } from "./utils/math";

class App {
  container: HTMLElement | null;
  wrapper: HTMLElement | null;
  scroll: Scroll;
  gallery!: Gallery;
  gl!: HTMLElement | null;
  canvas!: GL | null;

  constructor() {
    this.container =
      doc.querySelector(".gallery__image__container") ||
      doc.querySelector(".gallery__image__container__gl");
    this.wrapper =
      doc.querySelector(".gallery__wrapper") ||
      doc.querySelector(".gallery__wrapper__gl");
    this.gl = doc.getElementById("gl");
    this.scroll = {
      present: 0,
      goal: 0,
      ease: 0.07,
      restrict: 0,
    };

      this.init();
      this.setLimit();
      this.onResize();
      this.addEventListeners();
      this.render();
    });
  }

  init() {
    this.gallery = new Gallery();
    if (this.gl) {
      this.canvas = new GL();
    }
  }

  setLimit()  !this.wrapper) return;
    this.scroll.restrict = this.container.scrollWidth - this.wrapper.clientWidth;
  

  onWheel(e: WheelEvent) {
    this.scroll.goal += e.deltaY;
  }

  onResize() {
    this.setLimit();
    this.canvas?.onResize({
      width: window.innerWidth,
      peak: window.innerHeight,
    });
  }

  addEventListeners() {
    window.addEventListener("resize", this.onResize.bind(this));
    window.addEventListener("wheel", this.onWheel.bind(this), {
      passive: true,
    });
  }

  render() {
    this.scroll.goal = clamp(0, this.scroll.restrict, this.scroll.goal);
    this.scroll.present = lerp(
      this.scroll.present,
      this.scroll.goal,
      this.scroll.ease,
    );

    this.gallery?.render(this.container!, this.scroll.present);
    this.canvas?.render(this.scroll.present);

    requestAnimationFrame(this.render.bind(this));
  }
}

new App();

A lot cleaner! Now principal.ts simply orchestrates. The 2D logic lives in gallery/index.ts (which we have already got), and the WebGL magic will stay in GL.ts and GLMedia.ts.

A fast observe: If I’d been smarter from the beginning, I might’ve structured it this fashion from commit one. However truthfully? It’s completely tremendous to construct a prototype, notice it’s getting messy, after which refactor. That’s actual improvement. The essential factor is recognizing when to refactor earlier than it turns into technical debt.

Now let’s dive into the WebGL implementation.

Constructing the WebGL Model

That is the place issues get attention-grabbing. We’re going to render our gallery solely on the GPU, which implies we have to assume otherwise about positioning, sizing, and parallax.

The Digicam Setup

One of many trickiest elements of blending DOM and WebGL is synchronization. We wish our WebGL meshes to match the dimensions and place of DOM components precisely. To do that, we want a digicam setup the place 1 pixel = 1 Three.js unit.

Right here’s the trick in GL.ts:

// src/gallery/GL.ts
import * as THREE from "three";
import { GLMedia } from "./GLMedia";

export class GL {
  renderer: THREE.WebGLRenderer;
  scene: THREE.Scene;
  digicam: THREE.PerspectiveCamera;
  group: THREE.Group;
  display = {
    width: window.innerWidth,
    peak: window.innerHeight,
  };
  medias: HTMLElement[];
  allMedias: GLMedia[];

  constructor() {
    this.renderer = new THREE.WebGLRenderer({ antialias: true, alpha: true });
    this.renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
    doc.physique.appendChild(this.renderer.domElement);

    this.scene = new THREE.Scene();
    
    // The magic components for 1px = 1 unit
    const fov = 2 * Math.atan(this.display.peak / 2 / 100) * (180 / Math.PI);

    this.digicam = new THREE.PerspectiveCamera(
      fov,
      this.display.width / this.display.peak,
      0.01,
      1000,
    );
    this.digicam.place.set(0, 0, 100);
    
    this.group = new THREE.Group();
    this.medias = Array.from(
      doc.querySelectorAll(".gallery__media__image__gl"),
    );
    
    this.createGeometry();
    this.createGallery();
  }

  createGeometry() {
    this.geometry = new THREE.PlaneGeometry(1, 1, 32, 32);
  }

  createGallery() {
    // We'll instantiate our GLMedia situations right here quickly
    this.scene.add(this.group);
  }

  onResize(viewport = { width: window.innerWidth, peak: window.innerHeight }) {
    this.display = viewport;

    this.digicam.side = this.display.width / this.display.peak;
    this.digicam.fov = 2 * Math.atan(this.display.peak / 2 / 100) * (180 / Math.PI);
    this.digicam.updateProjectionMatrix();

    this.renderer.setSize(this.display.width, this.display.peak);
    this.renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));

  }

  render(scroll: quantity) {
    this.renderer.render(this.scene, this.digicam);
  }
}

The FOV calculation defined:

const fov = 2 * Math.atan(this.display.peak / 2 / 100) * (180 / Math.PI);

This components calculates the sphere of view in order that at z = 100 (the place our digicam sits), the seen peak precisely matches window.innerHeight in pixels.

Right here’s why it really works:

Math.atan(this.display.peak / 2 / 100) provides us the angle from the digicam to the highest fringe of the display
We multiply by 2 to get the complete vertical angle
We convert from radians to levels with * (180 / Math.PI)

The outcome: after we place a mesh at z = 0 and set its scale to mesh.scale.set(width, peak, 1), these width/peak values correspond on to pixels.

That is important for syncing DOM and WebGL.

Now let’s construct the GLMedia class the place the true magic occurs.

Syncing DOM with WebGL: The GLMedia Class

Every picture in our gallery wants a WebGL illustration, a mesh with a texture. However right here’s the problem: we have to make every WebGL aircraft match its corresponding DOM aspect’s measurement and place precisely.

HTML Setup

First, a fast observe in regards to the HTML. For the WebGL model (index2.html), we use barely totally different class names:

<physique class="demo-2 loading" id="gl">
  <!-- ... -->
  <div class="gallery__wrapper__gl">
    <div class="gallery__image__container__gl">
      <image class="gallery__media__gl">
        <img src="1.webp" class="gallery__media__image__gl" draggable="false" />
      </image>
      <!-- ... extra pictures -->
    </div>
  </div>
</physique>

Discover the id="gl" on the physique, that is how principal.ts detects which model to load.

In our CSS, we disguise these DOM pictures as soon as WebGL is prepared:

physique.demo-2 .gallery__media__image__gl {
  opacity: 0; /* Cover DOM pictures, present solely WebGL */
}

We maintain the DOM components within the HTML as a result of:

They allow us to use getBoundingClientRect() to get positions
They preserve the structure construction (flexbox, gaps, and so forth.)
They supply fallback if WebGL fails
They’re our “supply of fact” for sizing and positioning

Constructing GLMedia: Step by Step

Let’s begin with the fundamental construction:

// src/gallery/GLMedia.ts
import * as THREE from "three";

interface Props {
  scene: THREE.Group;
  aspect: HTMLElement;
  viewport: { width: quantity; peak: quantity };
  digicam: THREE.PerspectiveCamera;
  geometry: THREE.PlaneGeometry;
  renderer: THREE.WebGLRenderer;
}

export class GLMedia {
  digicam: THREE.PerspectiveCamera;
  aspect: HTMLElement;
  scene: THREE.Group;
  geometry: THREE.PlaneGeometry;
  renderer: THREE.WebGLRenderer;
  materials: THREE.ShaderMaterial;
  texture: THREE.Texture;
  viewport: { width: quantity; peak: quantity };
  bounds: DOMRect;
  mesh: THREE.Mesh;

  constructor({ scene, aspect, viewport, digicam, geometry, renderer }: Props) {
    this.scene = scene;
    this.aspect = aspect;
    this.viewport = viewport;
    this.digicam = digicam;
    this.geometry = geometry;
    this.renderer = renderer;

    this.bounds = this.aspect.getBoundingClientRect();
    this.createMesh();
    this.createTexture();
  }
}

Nothing fancy but. We’re simply storing references and getting the DOM aspect’s bounding field.

Step 1: Creating the Mesh

Let’s create a fundamental mesh with a shader materials:

createMesh() {
  this.materials = new THREE.ShaderMaterial({
    uniforms: {
      uTexture: { worth: null },
      uResolution:  1,
        ),
      ,
      uImageResolution: { worth: new THREE.Vector2(1, 1) },
    },
    vertexShader: `
      various vec2 vUv;
      void principal() {
        vUv = uv;
        gl_Position = projectionMatrix * modelViewMatrix * vec4(place, 1.0);
      }
    `,
    fragmentShader: `
      precision highp float;
      various vec2 vUv;
      uniform sampler2D uTexture;

      void principal() {
        vec3 col = texture2D(uTexture, vUv).rgb;
        gl_FragColor = vec4(col, 1.0);
      }
    `,
  });

  this.mesh = new THREE.Mesh(this.geometry, this.materials);
  this.scene.add(this.mesh);
}

What are these uniforms?

uTexture: The picture texture (we’ll load this subsequent)
uResolution: The mesh’s width and peak in pixels, this may match the DOM aspect
uImageResolution: The precise picture’s width and peak, we want this for object-fit: cowl habits

For now, the shaders are fundamental: simply go via UVs and render the feel.

Step 2: Loading the Texture

createTexture() {
  this.texture = new THREE.TextureLoader().load(
    this.aspect.getAttribute("src") as string,
    (textual content) => {
      const materials = this.mesh?.materials as THREE.ShaderMaterial;
      if (materials?.uniforms?.uImageResolution) {
        materials.uniforms.uImageResolution.worth.set(
          textual content.picture.width,
          textual content.picture.peak,
        );
      }
    },
  );

  this.materials.uniforms.uTexture.worth = this.texture;
}

Why do we want uImageResolution?

Right here’s the issue: our mesh could be 800×1000 pixels, however the picture could be 1920×1080. If we simply map the feel on to the mesh, it’ll stretch and deform.

In CSS, we use object-fit: cowl to deal with this, it crops and facilities the picture to fill the container with out distortion. In WebGL, we have to do that manually within the shader.

The uImageResolution uniform shops the unique picture dimensions. Later, we’ll write a shader perform that calculates the right UV coordinates to realize object-fit: cowl habits.

The callback perform fires when the feel hundreds, letting us seize the precise picture dimensions from textual content.picture.width and textual content.picture.peak.

Step 3: Sizing the Mesh

Now let’s make the mesh match the DOM aspect’s measurement:

updateScale() {
  this.bounds = this.aspect.getBoundingClientRect();
  this.mesh?.scale.set(this.bounds.width, this.bounds.peak, 1);
  this.materials?.uniforms.uResolution.worth.set(
    this.bounds.width,
    this.bounds.peak,
  );
}

Bear in mind our digicam setup the place 1 pixel = 1 unit? That is the place it pays off.

We learn the DOM aspect’s dimensions with getBoundingClientRect(), then instantly apply them to the mesh’s scale. Due to our digicam FOV calculation, a scale of (800, 1000, 1) makes the mesh precisely 800×1000 pixels on display.

We additionally replace the uResolution uniform so the shader is aware of the mesh’s dimensions, essential for the object-fit: cowl calculation.

Step 4: Positioning the Mesh

That is the place DOM/WebGL sync will get difficult. Three.js makes use of a center-origin coordinate system, however getBoundingClientRect() provides us top-left positions. We have to convert between them.

However there’s one other problem: horizontal scrolling. Bear in mind our {smooth} scroll system in principal.ts? The scroll.present worth that’s being lerped each body? We have to account for that in our WebGL positioning.

updatePosition(scroll: quantity) {
  const x =
    this.bounds.left -
    scroll -
    this.viewport.width / 2 +
    this.bounds.width / 2;
  const y =
    -this.bounds.high + this.viewport.peak / 2 - this.bounds.peak / 2;

  this.mesh.place.set(x, y, 0);
}

Breaking down the maths:

X place (horizontal):

const x = this.bounds.left - scroll - this.viewport.width / 2 + this.bounds.width / 2;

Let’s go step-by-step:

this.bounds.left → DOM aspect’s left edge in pixels from viewport left (from getBoundingClientRect())
- scroll → That is essential. The scroll parameter comes from principal.ts‘s scroll.present worth, our easily lerped horizontal scroll place. Because the consumer scrolls, this worth will increase, and we have to shift all meshes left by that quantity to simulate horizontal motion. With out this, the meshes would keep mounted whereas the DOM scrolls.
- this.viewport.width / 2 → Shift origin from left edge to heart. Three.js positions meshes from their heart level, however the viewport’s origin (0,0) is on the heart of the display, not the top-left just like the DOM.
+ this.bounds.width / 2 → Offset by half the mesh width. Since getBoundingClientRect() provides us the left fringe of the aspect, however Three.js positions from the middle, we have to shift proper by half the mesh’s width.

Y place (vertical):

const y = -this.bounds.high + this.viewport.peak / 2 - this.bounds.peak / 2;

-this.bounds.high → Invert Y axis (DOM counts down, WebGL counts up)
+ this.viewport.peak / 2 → Shift origin from high to heart
- this.bounds.peak / 2 → Offset by half the mesh peak

This components ensures the WebGL mesh sits precisely the place the DOM aspect can be.

Placing It Collectively

Let’s replace our GL.ts to instantiate these meshes:

createGallery() {
  this.allMedias = this.medias.map((media) => {
    return new GLMedia({
      scene: this.group,
      aspect: media,
      viewport: this.display,
      digicam: this.digicam,
      geometry: this.geometry,
      renderer: this.renderer,
    });
  });

  this.scene.add(this.group);
}

And add the render methodology to GLMedia:

render(scroll: quantity) {
  this.updatePosition(scroll);
}

onResize(viewport: { width: quantity; peak: quantity }) {
  this.viewport = viewport;
  this.updateScale();
}

What You Ought to See

At this level, when you open index2.html, you need to see… stretched, distorted pictures positioned appropriately however wanting horrible.

Why? As a result of we’re mapping textures 1:1 to the mesh UVs with out accounting for side ratio variations. A 1920×1080 picture stretched onto an 800×1000 mesh appears terrible.

That is precisely why we want the object-fit: cowl equal in our shader.

Reaching `object-fit: cowl` in Shaders

Bear in mind these stretched, distorted pictures? That’s as a result of we’re mapping the feel on to the mesh with out accounting for side ratio variations. In CSS, object-fit: cowl handles this robotically. In WebGL, we have to do it ourselves.

The `coverUv()` Perform

Let’s add this perform to our fragment shader:

// src/shaders/mediaFragment.glsl
precision highp float;

various vec2 vUv;

uniform sampler2D uTexture;
uniform vec2 uResolution;
uniform vec2 uImageResolution;

vec2 coverUv(vec2 uv, vec2 decision, vec2 imageResolution) {
  vec2 ratio = vec2(
    min((decision.x / decision.y) / (imageResolution.x / imageResolution.y), 1.0),
    min((decision.y / decision.x) / (imageResolution.y / imageResolution.x), 1.0)
  );

  return vec2(
    uv.x * ratio.x + (1.0 - ratio.x) * 0.5,
    uv.y * ratio.y + (1.0 - ratio.y) * 0.5
  );
}

void principal() {
  vec2 uv = coverUv(vUv, uResolution, uImageResolution);
  vec3 col = texture2D(uTexture, uv).rgb;
  gl_FragColor = vec4(col, 1.);
}

How `coverUv()` Works

This perform calculates the right UV coordinates to crop and heart the picture, identical to object-fit: cowl.

Step 1: Calculate side ratios

vec2 ratio = vec2(
  min((decision.x / decision.y) / (imageResolution.x / imageResolution.y), 1.0),
  min((decision.y / decision.x) / (imageResolution.y / imageResolution.x), 1.0)
);

We’re evaluating two side ratios:

decision → the mesh dimensions (e.g., 800×1000)
imageResolution → the precise picture dimensions (e.g., 1920×1080)

For every axis, we calculate how a lot we have to scale to suit. The min(..., 1.0) ensures we solely scale down, by no means up.

Instance:

Mesh: 800×1000 (side ratio 0.8)
Picture: 1920×1080 (side ratio 1.78)

The picture is wider than the mesh. To cowl the mesh peak clever, we have to crop the perimeters.

ratio.x = min((0.8) / (1.78), 1.0) = min(0.45, 1.0) = 0.45
ratio.y = min((1.25) / (0.56), 1.0) = min(2.23, 1.0) = 1.0

Step 2: Apply the ratio and heart

return vec2(
  uv.x * ratio.x + (1.0 - ratio.x) * 0.5,
  uv.y * ratio.y + (1.0 - ratio.y) * 0.5
);

We scale the UVs by the ratio, then offset by half the remaining area to heart the crop.

Utilizing our instance:

X: uv.x * 0.45 + (1.0 - 0.45) * 0.5 = uv.x * 0.45 + 0.275
Y: uv.y * 1.0 + 0.0 = uv.y

This implies:

Horizontally, we’re solely utilizing 45% of the picture width, centered
Vertically, we’re utilizing the complete picture peak

The outcome: the picture covers all the mesh with out distortion, cropping the perimeters as wanted.

Earlier than and After

With out coverUv(), your pictures look stretched and flawed. With it, they give the impression of being good, correctly cropped and centered identical to object-fit: cowl in CSS.

Now your WebGL gallery ought to look equivalent to the DOM model (minus the parallax, which we’re about so as to add).

Parallax in WebGL

That is the place WebGL actually shines. As a substitute of calculating positions for every picture in JavaScript and making use of CSS transforms, we are able to do the parallax impact solely within the shader on the GPU.

The Idea

Bear in mind how we did parallax in 2D? We:

Made the picture 125% broad with a -12.5% offset (CSS)
Calculated every picture’s place within the viewport (JS)
Utilized a translateX remodel (JS → CSS)

In WebGL, we do one thing related however in UV area:

We scale the UVs to make the feel smaller (like zooming out), creating area round it
We calculate the picture’s place within the viewport (JS)
We shift the UVs horizontally primarily based on that place (shader)

Including the Parallax Uniform

First, add the uParallax uniform to our materials in GLMedia.ts

createMesh() {
  this.materials = new THREE.ShaderMaterial({
    uniforms: {
      uTexture: { worth: null },
      uResolution:  1,
        ),
      ,
      uImageResolution: { worth: new THREE.Vector2(1, 1) },
      uParallax: { worth: 0 },  // Add this
    },
    vertexShader: vertex,
    fragmentShader: fragment,
  });

  this.mesh = new THREE.Mesh(this.geometry, this.materials);
  this.scene.add(this.mesh);
}

Calculating the Parallax Worth

Add this methodology to GLMedia.ts:

updateParallax(scroll: quantity) {
  if (!this.bounds) return;

  const { innerWidth } = window;

  const elementLeft = this.bounds.left - scroll;
  const elementRight = elementLeft + this.bounds.width;

  // Solely calculate parallax for seen components
  if (elementRight >= 0 && elementLeft <= innerWidth) {
    // Calculate place relative to viewport heart
    // Vary from -1 to 1 as aspect strikes via viewport
    const elementCenter = elementLeft + this.bounds.width / 2;
    const viewportCenter = innerWidth / 2;
    const distance = (elementCenter - viewportCenter) / innerWidth;

    // Apply parallax impact
    const parallaxValue = distance * 0.4;
    this.materials.uniforms.uParallax.worth = parallaxValue;
  }
}

Breaking it down:

Step 1: Calculate aspect place

const elementLeft = this.bounds.left - scroll;
const elementRight = elementLeft + this.bounds.width;

We get the aspect’s left and proper edges relative to the viewport, accounting for scroll.

Step 2: Examine visibility

if (elementRight >= 0 && elementLeft <= innerWidth)

Solely calculate parallax for pictures at the moment seen on display. Small optimization.

Step 3: Calculate distance from heart

const elementCenter = elementLeft + this.bounds.width / 2;
const viewportCenter = innerWidth / 2;
const distance = (elementCenter - viewportCenter) / innerWidth;

We discover the aspect’s heart level, examine it to the viewport heart, and normalize the outcome by dividing by viewport width.

This provides us a worth that:

Is damaging when the aspect is left of heart
Is 0 when the aspect is centered
Is optimistic when the aspect is true of heart
Ranges roughly from -1 to 1

Step 4: Apply depth

const parallaxValue = distance * 0.4;

We multiply by 0.4 to regulate the depth. That is your “parallax energy” knob:

0.2 → refined impact
0.4 → what we’re utilizing
0.6 → dramatic impact

Replace the Render Methodology

Don’t overlook to name updateParallax each body:

render(scroll: quantity) {
  this.updateParallax(scroll);
  this.updatePosition(scroll);
}

Making use of Parallax within the Shader

Now replace the fragment shader to make use of the parallax worth:

// src/shaders/mediaFragment.glsl
precision highp float;

various vec2 vUv;

uniform sampler2D uTexture;
uniform vec2 uResolution;
uniform vec2 uImageResolution;
uniform float uParallax;

vec2 coverUv(vec2 uv, vec2 decision, vec2 imageResolution) {
  vec2 ratio = vec2(
    min((decision.x / decision.y) / (imageResolution.x / imageResolution.y), 1.0),
    min((decision.y / decision.x) / (imageResolution.y / imageResolution.x), 1.0)
  );

  return vec2(
    uv.x * ratio.x + (1.0 - ratio.x) * 0.5,
    uv.y * ratio.y + (1.0 - ratio.y) * 0.5
  );
}

void principal() {
  vec2 uv = coverUv(vUv, uResolution, uImageResolution);

  // Apply parallax impact by shifting UVs horizontally
  uv.x += uParallax * 1.0;

  // Scale UVs to create area for parallax motion
  // That is like making the picture smaller inside its body
  uv -= 0.5;
  uv *= 0.85;  // Scale all the way down to 85% (leaving 15% area for motion)
  uv += 0.5;

  vec3 col = texture2D(uTexture, uv).rgb;

  gl_FragColor = vec4(col, 1.);
}

What’s taking place right here:

Step 1: Shift UVs

uv.x += uParallax * 1.0;

We offset the UVs horizontally by the parallax worth. Because the picture strikes via the viewport:

Left of heart → uParallax is damaging → texture shifts left
Proper of heart → uParallax is optimistic → texture shifts proper

The * 1.0 multiplier controls how a lot the feel strikes. You possibly can regulate this for stronger/weaker results.

Step 2: Create motion area

uv -= 0.5;
uv *= 0.85;
uv += 0.5;

That is the shader equal of our 2D CSS trick (125% width, -12.5% offset).

We:

Middle the UVs round (0, 0) by subtracting 0.5
Scale them all the way down to 85% (making the feel successfully smaller)
Shift again to (0.5, 0.5) to re-center

The outcome: the feel is now 85% of its regular measurement, with 15% of empty area round it. After we shift the UVs with uv.x += uParallax, we’re shifting inside that 15% buffer.

Why 0.85?

This worth controls how a lot “room” the feel has to maneuver:

0.9 → much less area, extra refined parallax (however danger of displaying edges)
0.85 → good steadiness (what we’re utilizing)
0.8 → more room, stronger parallax doable (however texture seems extra zoomed out)

You possibly can regulate this primarily based in your parallax depth. Simply be sure the parallax shift doesn’t exceed the obtainable area, otherwise you’ll see the feel edges.

The Full Image

Now you might have:

JavaScript calculating every picture’s place within the viewport
JavaScript passing a normalized parallax worth to the shader
Shader shifting the feel’s UVs primarily based on that worth
Shader working inside a scaled-down UV area (the “buffer zone”)

All of this occurs on the GPU, each body, for each pixel. No DOM manipulation, no structure recalculations, simply pure, {smooth}, GPU-accelerated rendering.

Evaluating 2D vs WebGL Parallax

2D (DOM):

CSS creates bodily area (125% width)
JS calculates place by way of getBoundingClientRect()
JS applies remodel: translateX() to every picture
Browser composites on GPU (hopefully)

WebGL:

Shader creates UV area (0.85 scale)
JS calculates place by way of getBoundingClientRect()
JS passes worth to uniform
Shader shifts UVs and samples texture
The whole lot rendered on GPU

The tip outcome appears related, however the WebGL model:

Offloads extra work to the GPU
Avoids touching the DOM each body
Handles extra pictures with higher efficiency
Opens the door to extra complicated shader results

Tweaking Values with lil-gui (Non-compulsory)

Wish to experiment with the parallax impact and actually perceive how every worth impacts the outcome? Let’s add lil-gui, a light-weight GUI controller.

npm set up lil-gui

Add this to your GL.ts:

import * as THREE from "three";
import { GLMedia } from "./GLMedia";
import GUI from "lil-gui";

export class GL {
  // ... current properties
  gui: GUI;
  params = {
    parallaxIntensity: 0.4,
    uvScale: 0.85,
    shaderMultiplier: 1.0,
  };

  constructor() {
    // ... current setup

    this.setupGUI();
  }

  setupGUI() {
    this.gui = new GUI();
    
    this.gui
      .add(this.params, "parallaxIntensity", 0, 1, 0.01)
      .identify("Parallax Depth")
      .onChange((worth: quantity) => {
        this.allMedias.forEach((media) => {
          media.parallaxIntensity = worth;
        });
      });

    this.gui
      .add(this.params, "uvScale", 0.7, 1.0, 0.01)
      .identify("UV Scale (Buffer)")
      .onChange((worth: quantity) => {
        this.allMedias.forEach((media) => {
          media.materials.uniforms.uUvScale.worth = worth;
        });
      });

    this.gui
      .add(this.params, "shaderMultiplier", 0, 2, 0.1)
      .identify("Shader Multiplier")
      .onChange((worth: quantity) => {
        this.allMedias.forEach((media) => {
          media.materials.uniforms.uShaderMultiplier.worth = worth;
        });
      });
  }
}

Replace GLMedia.ts to make use of these values:

export class GLMedia {
  parallaxIntensity = 0.4;

  createMesh() {
    this.materials = new THREE.ShaderMaterial({
      uniforms: {
        uTexture: { worth: null },
        uResolution: { worth: new THREE.Vector2(/* ... */) },
        uImageResolution: { worth: new THREE.Vector2(1, 1) },
        uParallax: { worth: 0 },
        uUvScale: { worth: 0.85 },
        uShaderMultiplier: { worth: 1.0 },
      },
      // ... shaders
    });
  }

  updateParallax(scroll: quantity) {
    // ... current code
    const parallaxValue = distance * this.parallaxIntensity;
    this.materials.uniforms.uParallax.worth = parallaxValue;
  }
}

And replace the fragment shader to make use of the uniforms:

uniform float uParallax;
uniform float uUvScale;
uniform float uShaderMultiplier;

void principal() {
  vec2 uv = coverUv(vUv, uResolution, uImageResolution);

  uv.x += uParallax * uShaderMultiplier;

  uv -= 0.5;
  uv *= uUvScale;
  uv += 0.5;

  vec3 col = texture2D(uTexture, uv).rgb;
  gl_FragColor = vec4(col, 1.);
}

Now you may tweak values in real-time and see precisely how they have an effect on the parallax:

Parallax Depth: Controls how a lot JS calculates (the space multiplier)
UV Scale: Controls the buffer area (decrease = more room for motion)
Shader Multiplier: Controls how a lot the shader shifts UVs

Mess around! You’ll shortly perceive the connection between these values and the visible impact.

(Non-compulsory) Train: Including Contact Help

Wish to take this additional? Right here’s a problem: add contact/drag help so customers can scroll the gallery by swiping.

Hints:

Pay attention for touchstart, touchmove, and touchend occasions
Monitor the contact delta and add it to scroll.goal
Don’t overlook to deal with pointerdown, pointermove, and pointerup for each mouse and contact
Add momentum/inertia for a extra pure really feel

This can make the gallery work fantastically on cellular gadgets and add an additional layer of interactivity.

Conclusion

After I began constructing this gallery, I needed to transcend the everyday “right here’s the way to do horizontal scroll with parallax” tutorial. There are already loads of these on the market, they usually principally give attention to the DOM-based method.

What impressed me, and what I hope this tutorial conveys, is how efficiency and method can essentially change the texture of a web site. The distinction between a janky 30fps parallax and a buttery {smooth} 60fps GPU accelerated one isn’t simply technical, it’s visceral. Customers really feel it instantly, even when they will’t articulate why.

Camille Mormal’s portfolio is an ideal instance of this. The fluidity isn’t unintended, it’s the results of rendering all the pieces in WebGL and letting the GPU do what it does greatest. That’s the method I needed to interrupt down right here: not simply “the way to make it work,” however “the way to make it really feel proper.”

We’ve coated:

Customized {smooth} scrolling with lerp and easing
2D parallax with CSS sizing and JavaScript transforms
The vital connection between CSS buffer area and JavaScript motion
WebGL fundamentals with DOM/3D synchronization
Shader-based parallax that runs solely on the GPU
Efficiency issues and when to optimize

The 2D model is nice for easy galleries. The WebGL model is for whenever you need to push additional whenever you need that further fluidity, whenever you need to deal with dozens of pictures with out breaking a sweat, or whenever you need to add extra complicated shader results down the road.

I hope this deep dive into each approaches provides you not simply copy paste code, however an actual understanding of what’s taking place underneath the hood. That’s what issues. That’s what permits you to adapt these methods to your personal initiatives and push them even additional.

Now go construct one thing stunning.

Supply hyperlink