# Subpixel GUI

DevFeed: [Subpixel GUI](<https://devfeed.tech/articles/subpixel-gui-22384.md>)

Original publisher: [Read original article](<https://www.red-lang.org/2023/08/subpixel-gui.html>)

Author: Nenad Rakocevic (noreply@blogger.com)

Published: 2023-08-09T13:32:00Z

Content type: article

Language: en

Sources: [Red](<https://devfeed.tech/sources/red.md>)

Topics: [Red](<https://devfeed.tech/topics/red.md>), [GUI](<https://devfeed.tech/topics/gui.md>), [floating-point](<https://devfeed.tech/topics/floating-point.md>), [API](<https://devfeed.tech/topics/api.md>), [test](<https://devfeed.tech/topics/test.md>)

Tags: [3d](<https://devfeed.tech/tags/3d.md>), [4k](<https://devfeed.tech/tags/4k.md>), [components](<https://devfeed.tech/tags/components.md>), [floating-point](<https://devfeed.tech/tags/floating-point.md>), [gui](<https://devfeed.tech/tags/gui.md>), [pairs](<https://devfeed.tech/tags/pairs.md>), [points](<https://devfeed.tech/tags/points.md>), [precision](<https://devfeed.tech/tags/precision.md>), [scale](<https://devfeed.tech/tags/scale.md>), [subpixel](<https://devfeed.tech/tags/subpixel.md>)

## AI overview

The article explains how Red/View addressed a GUI dragging glitch caused by converting integer coordinates to floating-point values on displays using scaling above 100%. It introduces point2D! and point3D! datatypes to represent decimal positions and sizes.

## Source excerpt

Maybe you didn't notice, but Red/View, our GUI engine, has subpixel precision from the beginning! Unfortunately, that level of precision was not directly accessible to end users, until now. Actually, it would be more accurate to say that we had subpixel resolution only so far. The guilty part is the pair! datatype being limited to integer components only, while subpixel precison requires decimal numbers. So we have recently introduced new datatypes to cope with that. What urged us to make those changes now was a very peculiar visual glitch caused by that dissonance. That glitch happens during face dragging operations. Here is an example using our View test script: As you can see, on some positions, the face starts shaking while the mouse cursor remains still. This affects any type of face. The shaking is about ±2 pixels. It is caused by the difference in precision between the /offset facet expressed in integer numbers and the backend API, which only deals with floating point numbers. The accumulated error when converting integer->float->integer gives a 2 pixels difference. Such error happens on displays where the scaling factor is different from 100%. With the rise of 2K, 3K and 4K displays, a scaling factor > 100% has become the norm, making this glitch more frequent. You might think that this is not a big issue until you start building custom scrollbars and see your entire scrolled content shaking massively... New point datatypes In order to provide decimal positions and sizes for View faces, extending the existing pair! datatype was considered, though, the pair syntax can hardly scale up for such needs: 2343.122x54239.44 2343.122x54239.44x6309.332 2343.122x54239.44x6309.332x442.3321 2.33487e9x54239.44 2.33487e9x54239.44x9.83242e17 2.33487e9x54239.44x9.83242e17x5223.112 1.#infx1.#infx1.#inf As you can notice there, it quickly becomes difficult to read and identify the individual components. So we opted for adding a new literal form (hence a new datatype) that matc