Notices by Adrian Cochrane (alcinnz@floss.social), page 34

@steeph Yes, that is what I mean!

@steeph Ouch!

@steeph O.K., you can use the position property. Though that means I might rewrite your CSS.

I care more to see you avoid JS, & since you want to!

Yes, I'm talking non-functional mockups. I'd appreciate functional ones, but I'm not asking for them.

That decomposition is configured to call a methodtable defining how to handle moves, lines, conics, & cubics in Grays-specific ways. If compiled stand-alone buildflags use copy-pasted version of `FT_Decompose` to call these with appropriate numeric tweaks.

Move-to scales & sets the coordinates, initiating a new "cell" linkedlist.

Upon cubics it tweaks controlpoints checking shortcuts & repeatedly splits the cubic until it can render as a line & iterate to the next split.

4/5?

Splitting cubics involves some adds, halving, quartering, & 8th'ing. Via bitshifts. Though I'm not clear on what geometry on what geometry it's implementing.

Conics works similarly, but with step-count & dx precomputed, & using an innerloop with bittwiddling to split the curve. Ofcourse the split formula is simpler. May use compiler intrinsics for that precomputation, based on build flags.

Upon lines it applies clipping & handles special cases before iterating over Y axis.

5/6!

For each scanline, whether within that loop (& it's inner loop as it creates "cells") or in single-scanline fastpath, Grays checks some fastpaths (which they say happens surprisingly often) before iterating over X axis creating new "cells".

For vertical lines Grays iterates over Y axis adding new "cells".

---

Sweeping involves iterating over the inner Y axis & cells therein to appropriately call the span renderer, if it's not filling those bytes itself.

Cells have debug output.

6/6 Fin!

FreeType's smoother subsystem bundles its own "grays" rasterizer.

Aside from some minimal methods fullfilling the interface...

After validation it's render method consults flags & other parameters to compute the bounding box. Before (after some normalizing) iterating over the Y axis & "bands" therein pairing them up, filling intermediate space, decompose outline (with longjump error-handling & maybe no trace-debugging) & halving the width to validate & incorporating into the next bandpair.

3/

@steeph If you don't mind, I'd love to see some HTML mockups! So I can test against them, & later hook up to some local-server-side logic.

I'm thinking I'd hand off to this form engine when an <input> is selected!

@steeph Usually I would make this configurable, but for Haphaestus's design that would mean sacrificing browser features. Since that's where plenty of them would land!

To give some more context: I'm planning to have tree-history. Switch to a mode where you can navigate forward, backwards, & sideways in history. At the root would be this "Hearth" startpage, including an addressbar, bookmarks, settings link, etc.

P.S. I'm not planning to have any concept of windows or tabs.

To smooth outline overlaps (when they're not too big) it configures & defers to the rasterizer with a temporary scale, passing a callback tweaking the run-length rasterizer to avoid numeric overflows.

To preprocess LCD rendering it defers to the rasterizer at scale 3 on appropriate axis. With or without, depending on buildflags, multiple translation transforms.

There's a smoothing initializer, deferring to rasterizer's. Other methods defers to core infrastructure.

2/?

@steeph I have read that, yes!

@steeph Yes, that's definitely part of the answer. But there's several <input> types (including <select>) for which we can do better! And I'm imagining a sidebar listing what has been entered.

Also, what new input types would be handy to offer?

@steeph Those position fixed overlays would be even worse when not supporting JS means there's no way to dismiss them... But they'd be moved to inline text where they no longer obscure anything!

That said experimentation is needed to see how much I am breaking things... As I advocate for the new CSS features to be adopted!

FreeType includes a smoothing subsystem, exposed as a renderer. To ensure text looks good even on the worst monitors.

It's render method, after validation, computes x & y shifts considering the pixel mode, bitmap position, & maybe origin. This shift, if any, is temporarily applied before checking the mode & cleaning up. For `NORMAL` or `LIGHT` modes it considers specially rendering outline overlaps, or defers to the rasterizer. Otherwise it dynamically determines LCD filters to apply.

1/?

@dafne Or broaden your horizons to include artists who don't give you that ultimatum! That's my preference!

Counting the transistors in the 8086 processor: it's harder than you might think - Ken Shirriff: http://www.righto.com/2023/01/counting-transistors-in-8086-processor.html

The future needs files - Scott Jenson: https://jenson.org/files/

I just tooted that I want a document-centric TV OS I'd enjoy running Haphaestus on! As opposed to the app-centric status quo marketters love.

I don't care about Rusty Quill, I care about The Magnus Archives. I don't care about Decoder Ring Theatre, I care about The Red Panda Adventures.

(Well, I do care they continue making great shows...)

You may not recognize the names but I think you recognize the sentiment.

@steeph And since you're asking, there is help I'd appreciate!

How should webforms be filled when basically all you have for input are arrow buttons? Onscreen links? "Bureaucromancy"

What should be on the startpage beyond an addressbar? How to manage bookmarks & feeds? "Hearth"

I'd love a document-centric (as opposed to AppCentric status quo) TV OS to run Haphaestus upon! "TVle"

Plenty of UI design decisions to be made there I'd love input on... Any of these interest you?

@steeph Ironically, it's mostly the older features I'm avoiding! Most notably `position`! And I struggle whether how `float` interacts with inline text makes it worth implementing or too hard to implement... The newer layout modes are easier to implement for both browserdevs & webdevs!

1/2