foxhill

the resulting topology is somewhat.. violent, no? that said, i wonder how much of an impact it actually has on rendering.

either way, neat stuff, and the write up itself is excellent.

i do wonder how something like this can be generally implemented. i presume this must only support a subset of SQL/plpgsql, as some things would be.. utterly insane to manage manually. e.g., if i have a table with a btree-gist overlap constraint, or some inclusion-exclusion check-constraint (or literally any constraint that requires multiple rows to be fully determined - there are quite a lot of them), how on earth does this work?

there's a reason why postgres writing is (mostly) serialised (asterisk) to a single writer (asterisk asterisk). something something ACID, but in short by having multiple writers improves availability, but weakens integrity.

that's a nice example. on my M4, i measured 3.4s vs. 0.42s. honestly surprised there's ~10x improvement to be found.

as you've pointed out, you've literally micro-optimised this - isn't this what you'd expect? :)

it probably shouldn’t be a “release” thing. actually, certainly. i do wonder how many bugs would never have seen the light of day, if someone’s “set” actually turned out to be a sequence (i.e. allowed duplicate values) resulting in a debug build raising an assert.

huh. very cute. in the past, i had an idea for terser lambda syntax, similar to C#'s expression body functions - which i did end up implementing in clang:

    auto sum = [](auto a, auto b): a+b;

but this is something else. i didn't think i'd like it at first, but actually i think i might be coming around to it. the.. dollar syntax is regrettable, although it's not a show stopper.

you can't be serious, surely?

yes, mozilla's TOS update is a bad thing, but switching to chrome (or chromium-based) for it is really cutting your nose to spite your face.

you’re conflating reaction times and latency perception. these are not the same. humans can tell the difference down to 10ms, perhaps lower.

if you added 200ms latency to your mouse inputs, you’d throw your computer out the of the window pretty quickly.

what a miss.

i’d consider myself a day-to-day c++ engineer. well, because i am. i like lots of things from rust. there’s a few things i don’t. c++ has a lot to learn from rust, if it is to continue to exist.

but really.. isn’t this the point of the language? you need to understand the borrow checker because.. that’s why it’s here?

maybe i’m missing something.

friends. you understand that you can just.. take it off, right?

fully unscrew the cap then just either continue twisting the cap over the the edge - honestly effortless - or just.. pull it off? the cap still functions as a cap, afterward.

apologies, but i don’t understand the furore over this change.

so, when do you want to die, then?

really, i’m not trying to be mean here. you assert life must be finite, and all i’m asking is how finite it should be.

apologies, i wasn't being specific; none of what i said necessitates a CRT display, it was only as an example of how an older technology had less latency.

if modern a modern 60Hz LCD/OLED display couldn't get beneath 16.6ms latency, then what exactly is tearing?

you don't need to "beam race" to achieve sub-frame latency - you don't need to be accurate. switching off vsync should, principally, be enough to achieve this.

otherwise, yes, modern APIs go out of their way to avoid the possibility of this (the dreaded "tearing" artifacts you see from the frame buffer being changed during the transmission of the video signal to the monitor). i don't believe older techniques like you've mentioned are at all possible today, and only really made sense to talk about when analogue displays were the norm.

> An application with 10 frames of latency will be faster on a 1 kHz display than a perfectly coded application on a 60 Hz display.

thats actually not true. you seem to be implying that the best a 60hz display can manage is 16.6ms of latency. indeed that is the worst case value, but you should consider that early graphics technologies involved changing display modes mid scan.

it’s actually not ridiculous to suggest that old platforms had sub-millisecond latency; they did. if the scanline was on, or just before, the line where you would interact (i.e., the prompt line), the text you enter would appear immediately.

of course, “vsync”, tear free, and such like approaches “fixed” this - necessarily by adding at least a frame’s worth of latency - but also adding perceptual latency.

it’s an oft-overlooked aspect of refresh rates. a 60hz CRT, without vsync, still has the lower bound of latency lower than a 120hz display. perhaps even 240hz.

i’ve used two 240hz displays for years now. i’ll never go slower than that.