#932·mactype

Generic Subpixel Algorithm for Triangular-Structure QD-OLEDs / Pentile / WOLED / Others

Author: mdrejhonCreated Apr 20, 2023Updated Jun 1, 2026

NOTE: Not the same as #720 -- because this is a generic system that applies to all odd-pixel displays including triangle-pixel displays that are sometimes found on MiniLED Jumbotrons, Samsung QD-OLED, etc.

As founder of TestUFO/Blur Busters, I have a suggestion for an OPTIONAL custom subpixel algorithm to be added to MacType, useful for the new OLED computer monitors hitting the market: The same MacType antialiasing can still be kept, except it is "pushed" through a subpixel filter.

There is Unfixable Color Fringing even with MacType

MacType is unable to fix the OLED color fringing on Samsung QD-OLED displays. ClearType Tuner can't fix it either. We're looking for a solution because there a giant boom of OLED monitor announcements for year 2023.

There is Lot of Demand

A way to recruit donations for MacType? Lots of duplicates in Feedback Hub with over 100 upvotes on the brand new Samsung QD-OLED computer monitors.

Starter Generic Subpixel-Aware Supersampling Algorithm

A small mask bitmap is created for the subpixel structure (what the subpixel structure looks like for one real software-based pixel), which the user can specify. Or the bitmap could be represented as rows of base-4 numbers (0=transparent, 1=red, 2=green, 3=blue) so that it makes visual sense. Or it could be a transparent PNG with alpha channels (adjustable transparent edges), with transparent, red, green, blue. Etc.

Optional: For rare odd screens, such as ASUS Vivabook, you have weird structures for 2x2 groups of pixels. Therefore, you might need to use one bitmap for a 2x2 group of onscreen pixels, for slight further improvements to subpixel rendering. So mask can be configurable dimensions 1x1, 2x1, 1x2, and 2x2 for oddball displays -- one can photograph an OLED screen macro lens, then crop, then downconvert to just red/green/blue, and save the bitmap as a mask bitmap for subpixel rendering.

For every time one font glyph is rendered onscreen:

  1. Check if the glyph is already in the subpixel-scaled glyph cache (for a specific glyph at a size with all combining marks etc) If yes, skip to step 5.
  2. Render a single character (font glyph) in-memory at high scaling factor (e.g. 16x size).
    Example: If it's a 16point character of Arial, draw it at 256point size within GPU memory
  3. Downscale the supersized font letter through the subpixel-structure bitmask Example: Use a GPU shader to push the large font letter through the subpixel-structure bitmask during downsample
  4. Cache the resulting downsampled bitmap (for faster run at step 1)
  5. Draw the glyph onto the screen The bitmaps should be transparent with an alpha channel, to be compatible with overwritten text / overlay on complex background / linked letters like Arabic / etc).

Basically, pushing a supersized version of the glyph through the subpixel mask during downsample. This is very simple ultra-fast GPU shader code.

Or you could use layering of existing DirectWrite/Direct2D APIs instead (e.g. bitmap scaling and bitmap-combining mathematics similar to ADD, SUBTRACT, AND, OR, XOR, alpha-blend operations etc) instead of GPU shader code. (And many of these APIs compile as shaders anyway when GPU acceleration is enabled). Various settings can be done to adjust.

There should be a "Contrast" setting adjustment like ClearType APIs, which is metaphorically an alphablend between subpixel rendered and not subpixel-rendered.

ClearType Contrast can be simply an alphablend/math between a non-subpixel-compensated glyph and a subpixel-compensated glyph. And configurable supersample size (6x, 8x, 10x, 12x, 14x, 16x, [...]) for quality experiments.

One consideration; there will be loss of OpenType/TrueType "hinting" for small-size fonts (due the large-glyph rendering step) but the resulting correct subpixel render (up to ~3x more resolution possible) without hinting, will look superior to hinted-but-incorrect/blurrier. In other words, the nonstandard-subpixel-structure sharpness improvement outweighs the loss of "hinting" support for the vast majority of fonts -- even for complex fonts such as Mandarin, etc, that goes very soft/blurry on WOLEDs.

Either way, while it sounds difficult at first -- the generic algorithm is actually absurdly simple to a shader programmer or bitmap-mathematics programmer, once they're trained to understand ClearType better (e.g. treat the subpixels like additional pixels spatially)

LG WOLED Pixel Structure

image Note: The subpixel mask will have to omit the white pixel, showing only R-(blank)-G-B

Samsung QD-OLED Pixel Structure

image

ASUS Vivabook Pro 15 OLED Screen

image

Contrast Setting (Subpixel Blending)

The Contrast (a sort of alphablend) setting is very important.

The Contrast setting will blend between pure MacType (no subpixel rendering) versus full subpixel-rendered MacType.

This can be made adjustable to user preference; from absolutely no subpixel rendering (normal MacType) to full blatant color-fringy subpixel rendering. Also, this will need to be rotation-compensated (e.g. detect current screen rotation and automatically rotate the bitmask accordingly), linked to the rotation of the primary monitor.

In my experience, in turning on/off subpixel rendering, a default blend of very roughly 25%:75% alphablend between the full-contrast subpixel rendering and the non-subpixel (original MacType antialiasing) rendering, will likely look like a fantastic "ClearType 2" upgrade for OLEDs.

Don't forget to gamma-compensate subpixel rendering

Remember not to forget gamma-correction during your alphablending, as correct subpixel tinting is based on the real-lumens ratio, not the R,G,B numbers of whatever colorspace you use.

Remember! Due to gamma curve, pure RGB(200,100,100) or #804040 or #402020 is more than twice as many red photons as green photons and blue photons. Despite the red programming representation being numerically double the number of green and blue in such formatting -- it follows a gamma curve (2.2 by default for most monitors). So you need to gamma-correct your subpixel rendering for best results, with the standard gamma formula. Or use existing APIs that already does the alphablending correctly, e.g. many alphablend algorithms (mathing two bitmaps together) already has built-in gamma correction, but you should verify.

More Photos And Images at https://github.com/microsoft/PowerToys/issues/25595