<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Graphics on Nalar</title>
    <link>https://nalar.dev/tags/graphics/</link>
    <description>Recent content in Graphics on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 14 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/graphics/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Variable Refresh Rate Matches Display Timing to Frame Delivery</title>
      <link>https://nalar.dev/variable-refresh-rate-matches-display-timing-to-frame-delivery/</link>
      <pubDate>Mon, 14 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/variable-refresh-rate-matches-display-timing-to-frame-delivery/</guid>
      <description>&lt;p&gt;A fixed-refresh display updates on a regular clock. At 60 Hz, a new scan begins about every 16.7 milliseconds whether the graphics processor has completed a fresh frame or not. That regular schedule is simple, but rendered frames rarely arrive with perfectly regular timing.&lt;/p&gt;&#xA;&lt;p&gt;Variable refresh rate, commonly shortened to VRR, changes that relationship. Instead of forcing every display refresh to begin at one fixed interval, a compatible display can wait within an allowed timing range and start the next refresh when a completed frame is ready. The result can make changing frame rates look smoother while reducing visible tearing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Variable Refresh Rate and Frame Timing</title>
      <link>https://nalar.dev/variable-refresh-rate-and-frame-timing/</link>
      <pubDate>Sun, 13 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/variable-refresh-rate-and-frame-timing/</guid>
      <description>&lt;p&gt;A game can render one frame in 8 milliseconds and the next in 14. A conventional display running at a fixed refresh rate does not adjust its scan timing around those changes. The graphics source and the display therefore operate on separate schedules, and the mismatch can appear as tearing or uneven motion.&lt;/p&gt;&#xA;&lt;p&gt;Variable refresh rate, commonly shortened to VRR, changes that relationship. Within a supported operating range, a compatible display can vary the interval between refreshes so that new frames are presented closer to the time the source finishes them. The display is still refreshing one complete image after another; the timing between those refreshes is what changes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Display Refresh Rate and Frame Delivery</title>
      <link>https://nalar.dev/display-refresh-rate-and-frame-delivery/</link>
      <pubDate>Sat, 12 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/display-refresh-rate-and-frame-delivery/</guid>
      <description>&lt;p&gt;A 120 Hz screen can refresh twice as often as a 60 Hz screen, but that number does not mean every application produces 120 new frames each second. The display and the graphics system have separate jobs: one presents images at a refresh cadence, while the other prepares frames for presentation.&lt;/p&gt;&#xA;&lt;p&gt;That distinction explains several familiar effects. A high-refresh screen can make pointer movement and scrolling appear more continuous, yet a game rendering slowly can still look uneven. It also explains how variable refresh operation can reduce visible timing conflicts between frame production and display updates.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
