The screen has two origins, and they never agreed

Eugene Egoroff — Thu, 30 Jul 2026 11:58:51 +0000

Every programmer hits this moment. You draw your first rectangle, nudge it "up" by increasing Y, and it slides down instead. You flip the sign, it works, and you move on. Almost nobody stops to ask why the screen disagrees with every math class they ever took.

Here is the answer, and it is older than you think.

In a math class, the origin sits where the axes cross and Y climbs upward. Open almost any graphics API and (0, 0) is the top-left corner, with Y falling as you move down the screen. Beginners assume someone made a bad call. Nobody did. The screen has carried two different origins for decades, and both are still in use, because they come from two different machines.

Why the screen counts from the top-left

The top-left origin is a fossil of the cathode-ray tube. A CRT draws a picture by sweeping an electron beam across the glass one line at a time, starting at the top-left, moving left to right, then dropping to the next line down. That is a raster scan, and video memory was laid out to match it: the first byte is the top-left pixel, the next is the one to its right, and the last is the bottom-right.

So the "first" pixel is top-left, and Y grows downward because that is the direction both the beam and the memory travel. Text terminals inherited the same idea: line 1 is at the top, and the cursor moves down. The convention is not a preference. It is the shape of the hardware.

The other lineage: math kept its origin

Meanwhile, the mathematical world never gave up the Cartesian origin: bottom-left, Y up. Pen plotters drew like a person doing geometry on graph paper. And the systems built on top of that math kept it. PostScript and PDF place the origin at the lower-left of the page with Y increasing upward. OpenGL's window coordinates put (0, 0) at the bottom-left.

The best part: PDF's device space, the actual pixels, flips back to the top-left with Y down. One file format quietly carries both conventions, one for the page and one for the screen.

The myth, gently corrected

It is tempting to say early computers used Cartesian coordinates and then everyone switched to top-left. That is not quite what happened. There were two lineages from the start: raster displays, which count from the top-left because that is how they physically scan, and the math and vector world, which counts from the bottom-left. Top-left won for everyday UI and 2D graphics because raster displays won. Bottom-left survived wherever staying aligned with mathematics mattered.

Why you still feel it

This split is why you flip Y so often without thinking about where the habit came from. Load an image, whose rows run top to bottom, into OpenGL, whose window origin is bottom-left, and the picture is upside down until you flip a texture coordinate. OpenGL and DirectX disagree on which way texture Y runs. A game engine keeps screen space and world space pointing opposite ways and translates between them on every frame. The two origins never merged. Your code just negotiates between them, forever.

So the next time Y points the "wrong" way, it is not a bug, and it is not a bad decision from 1975. It is a standing disagreement between a cathode-ray tube and a geometry textbook, and your code is the treaty that keeps the peace.

by Eugene Egoroff · egoroff.me

Most website checkers give everyone ~80/100. So I built an honest security scanner.

Eugene Egoroff — Wed, 15 Jul 2026 16:15:00 +0000

I've been building web, SaaS and enterprise systems for 25+ years. Somewhere along the way I got tired of "website checker" tools.

You know the ones. You paste a URL, wait, and get a friendly ~80 out of 100. Their idea of "security" is a green check next to "HTTPS". And the report is really a funnel — give us your email, book a call with our agency.

So I built the opposite: CheckWeb — a free website security scan with no sign-up, an honest score, and real CVE detection. Here's what I learned building it.

Quick definition, because I'll lean on it all the way through: a CVE (Common Vulnerabilities and Exposures) is a publicly catalogued security flaw, filed under an ID like CVE-2024-4439. If a library on your site carries one, the write-up is public — and usually so is the exploit.

1. Aggregate CVE counts lie

The first thing I got wrong: counting CVEs per package instead of per version.

jQuery has accumulated 8 CVEs over its lifetime. But if your site runs jQuery 1.8.2, only 5 of them actually affect that version — the rest were introduced later, or fixed before it.

Reporting "jQuery 1.8.2 — 8 known CVEs" is technically a lie, and exactly the kind of thing that destroys trust the moment a developer checks. So the scanner cross-references the detected version against the version ranges published by OSV (Open Source Vulnerabilities, Google's open database) and NVD (the US government's National Vulnerability Database) and counts only the CVEs whose affected range actually includes that version — with max severity computed over that same subset.

A scanner that cries wolf is worthless. Accuracy isn't a nice-to-have here; it's the whole product.

2. Honesty is a feature, not a liability

Every checker I tried handed almost every site something in the high 70s. It feels good. It says nothing.

I went the other way: an honest 0–100 score with hard gates. A broken or untrusted certificate caps the overall score at 50, no matter how fast and well-optimized everything else is. No HTTPS at all caps it lower. A blacklisted domain caps it too.

That means my scores are sometimes ugly. That's the point — a low score is the product's own argument. And if your site is clean, I'll tell you straight instead of inventing problems.

3. Passive-only is a hard line

The scanner reads only what your site shows any visitor: response headers, returned HTML, DNS, the TLS certificate, the library versions a page loads. It never probes hidden paths, scans ports, or sends payloads.

Partly that's a legal line — actively probing someone else's domain isn't something you get to do because you're curious. But it's also trust: I want anyone to scan any site without me doing something I'd have to apologize for. The deeper active checks only make sense on a domain someone has proven they own.

What it actually finds

Outdated JS libraries and CMS versions with known CVEs, missing or weak security headers, TLS and certificate problems, mixed content, insecure cookies, email spoofing gaps (SPF and DMARC — the DNS records that stop strangers sending email as your domain), blacklisting and Safe Browsing flags.

The most striking find so far: a live site running a WordPress core old enough to carry 158 known CVEs.

Where it stands

Early, free, no revenue. The passive scan stays free forever. Later I plan a paid deep audit + monitoring for people who verify their own domain — that's where the active checks (exposed files, open ports, admin panels) belong.

The ask

Scan a site you know well: https://chkweb.com

Then tell me: are the findings accurate? Does the score feel fair? Anything confusing or missing?

I'd rather hear it's wrong now than after a thousand people trust it. Brutal feedback very welcome.

DEV Community: Eugene Egoroff