Hacker News Reader

Comment by jws | Hacker News Reader

He touches on line graphics as having the same problem rendering. I run into that when making strip charts.

In general, the higher level your graphics API, the harder it is to get horizontal and vertical lines to draw on the physical pixels. At the frame buffer level it is trivial. Cocoa and UIKit it is possible with some effort. SwiftUI it is impossible (you will end up using the escape hatch to Cocoa or UIKit). HTML is hopeless.

When printing meant writing some Postscript it was a little work, but doable. Getting it onto a printer through a modern printer API is essentially impossible.

Fundamentally this is why most graphs you see online look like they were drawn with a worn out felt tip marker. It hides the sins at the expense of limiting data density and precision.

View on HN

Reminds me of this: http://www.ericbrasseur.org/gamma.html?i=1

This was fun, at first I was wondering why none of the examples were working properly until I remembered I was using a 4k screen on a windows machine, which set the scaling to 150% by default. After setting the scaling to 100% the demos suddenly made sense. Also, interesting how changing the gamma setting on my screen also changed the results...

It's hard in HTML due to the clunky way it handles density scaling. You wont have any issue doing razer sharp pixel alignment on systems that are natively density aware, like Android, as then the rendering stack can just work in actual pixels like it should, and density handling is done by the layout system instead.

So it's not about the number of layers of abstraction or general "high level"ness, but rather if those abstractions are trying to cover up mistakes made elsewhere.

Sounds like you want font hinting but for vector graphics.

Thank you for your report. I have to represent scaled graphs also online via browsers and had been curious about the implementation of scaling through APIs and ultimately browser based drivers. My concern is that the human brain is very much better at comprehending spatial dithering, critical for e.g. price trend extrapolation, than the open literature gives credit. Vital research by CSERIAC at Wright Patterson was declassified to sell the post SDI COTS reboot, but heavily reclassified after 9/11. This has been to the great detriment of the human computer interaction research community which really didn't survive into this century.

Can you unacronym this?

I think you know what APIs are, CSERIAC is the Crew System Ergonomics Information Analysis Center, SDI is the Strategic Defence Initiative, and COTS means Commercial Off The Shelf, as in literally buying equipment from regular commercial vendors rather than doing the whole massive DoD contract thing.

And DoD is the Department of Defense ;)

About acronyms, I remember a company that won a bid for a company I worked with. Part of the reason they won is that their proposal was very clear, and one of the stated reason was the lack of acronyms.

To this day, I try to avoid using acronyms as much as possible. I also remember an argument at another company, someone was complaining of problems on the "VMS", the other was calling bullshit. It took a few minuted before they realized they were talking about two different things with the same acronym. There are only 17576 3-letter acronyms, if 200 of these are used, the chance of a collision is about 2/3 (see: birthday paradox), and that's assuming a uniform distribution, in reality, it is worse. Misunderstandings are inevitable.

It’s even worse tham that. Many letters can easily be confused for different letters, hence the reason for phonetic alphabets. I had one company who had an external system known as OAS, and some manager who maybe should have known about OAS, but had never worked with it decided to create an acronym OIS. Luckily the two systems were rarely talked about in the same context, but it still took me lots of mental effort to know which of the 2 systems various individuals were talking about in meetings when either were mentioned.

I don't quite understand this (not a graphics dev) -- if you have the ability to get the viewport size in a browser, and if the display is running at its native resolution, why do you not have pixel-perfect accuracy?

Floats get rounded to an off-by-one pixel.

I'd be amazed to see a resolution/dpi combo that results in a 1 pixel error from rounding and equally amazed that it isn't far from the same combo that would cause a rounding error outside of a browser.

I find it to more about a thin line being rendered as a little bit of color in two adjacent lines of pixels. The result is a messy blur instead of a crisp line. If any layer of the libraries and APIs doesn’t pass up the coordinate system mappings, like say a window doesn’t report its exact screen space position to its content, then you lose access to the information to register the pixels precisely.

That can definitely happen between but as a loss of information between layers that don't support DPI fully (e.g. Windows 7 type DPI information which isn't per screen aware) or are intentionally ignoring physical pixel information (e.g. percentage based sized/positioned elements) not float precision loss. Float precision loss is definitely a thing but even a 32 bit float is integer perfect to 8,388,608 meanwhile a 7,640 pixel screen (1,000 times smaller) is considered extraordinarily large. Fractions close to 0 (such as APIs that use a 0-1 range for the screen or DPI represented a a percentage of a standard value) have a similar accuracy.

I'm not even sure on Windows there is a way to render anything

The issue in a browser is that you have a default zoom that is often not 100% and you can also "zoom" in/out of web pages which by will cause blurriness or overly sharp images. If you decide to ignore that in favor of the native resolution, then the content size is likely too big or small for what the user expects and it's not clear what the user wants it to look like or scale to even if you did implement that too because of the huge variety in screen sizes and ratios the content could be viewed from.

A native application does not generally have these issues because by nature of being native it was built for the form factor it is being used on.

Be it macOS, Windows, iOS, or Android they all have the same problem with native apps. There is nothing about code being native that changes the user wanting content on their device to be larger or smaller.

It depends on what the various different layers in between you and the gfx hardware are doing.

For instance, see the discussion on this "monitor calibration" shader: https://www.shadertoy.com/view/NsS3Rw

In that case, FireFox does not 100% provide some of the needed APIs in order to get pixel-perfect rendering. There's nothing you can do to fix that yourself.

   "...Anyways, long story short, we need Firefox to implement 'devicePixelContentBoxSize' before we can have pixel exact rendering, deterministically, in that browser."

That's just one example.

For something delicate like pixel-perfect rendering, every layer in the chain from hardware to OS -> libraryX -> libraryY -> libraryZ -> browser -> your code, all need to handle coordinates and thigs _perfectly_. If any one of those links in the chain messes things up, or doesn't provide the correct rounding, etc. then you are stuck.

It's not so terribly hard to do, but it has subtleties and edge cases, and everyone involved must handle them correctly. Also, if they handle them not-correctly, the result is still "good enough" for many purposes, so the fix doesn't get prioritized.

FWIW Firefox has supported that for a ~year now and you could fix it yourself it was just more work than the prebuilt way.

Ah, good to know. I'm not involved in that project, just had the link handy as a relevant discussion. I'll wait for the ShaderToy devs to fix it, I guess (:

> When printing meant writing some Postscript it was a little work, but doable. Getting it onto a printer through a modern printer API is essentially impossible.

Brother printers (at least some) support BR-script which is Postscript without the trademark violation. It's supported at the driver level, I think, which would render the PS on the PC then send the rendered document as one of the hardware-supported languages like PCL.

I mention this as an interesting bit of info, and not to refute anything you said

If you netcat a ps file to the ip of the printer that should still work yes?

Reply on news.ycombinator.com