We already have plenty of techniques that are fast enough for classic UI rendering. There is no conceivable bottleneck for the kind of stuff that is on your screen right now. It's not a matter of "doing something quickly" imo, that's an issue specific to the games industry, and largely caused by the need to make entirely custom, animated, textured UIs as a feature for a single product.
What projects like Slug and Vello rather show is that GPU coding remains so obtuse that you cannot tackle an isolated subproblem like 2D vector rendering, and instead have to make apple pie from scratch by first creating the universe. And then the resulting solution is itself a whole beast that cannot just be hooked up to other API(s) and languages than it was created for, unless that is specifically something you also architect for. As the first slide shows, v1 required modern GPUs, and the CPU side uses hand-optimized SIMD routines.
2D vector graphics is also just an awkward niche to optimize for today. GPUs are optimized for 3D, where z-buffers are used to draw things in an order-independent way. 2D graphics instead must be layered and clipped in the right order, which is much more difficult to 'embarrassingly' parallelize. Formats like SVG can have an endless number of points per path, e.g. a detailed polygon of the United States has to be processed as one shape, you can't blindly subdivide it. You also can't rely on vanilla anti-aliasing because complementary edges wouldn't be fully opaque.
Even if you do go all the way, you'll still have just a 2D rasterizer. Perhaps it can work under projective transform, that's usually pretty easy, but will it be significantly more powerful or extensible than something like Cairo is today? Or will it just do that exact same feature set in a technologically sexier way? e.g. Can it be adapted to rendering of 3D globes and maps, or would that break everything? And note that rasterizing fonts as just unhinted glyphs (i.e. paths) is rarely what people what.
My wish is for a fast SVG renderer in the browser. At the moment, basic vector drawing is fast, but almost any use of filters or effects lags the browser. Theres a lot that SVG could do for (web) UI, but won't because it's so slow. Here's a small thought experiment I made a while ago for using SVG for more unconventional webdesign. Sadly it lags a lot.
> We already have plenty of techniques that are fast enough for classic UI rendering. There is no conceivable bottleneck for the kind of stuff that is on your screen right now.
I disagree, you either have the old object-oriented toolkits, which are fast enough but very unpleasant to, or the new reactive frameworks, that offers much better developer ergonomics (and that's why pretty much everybody uses them right now) but have pathological performance characteristics and requires lots of additional work to be fast enough when the number of items on screen is high enough.
By the way you are missing the forest (Xilem) for the tree (Vello) here: the foundational work Raph has been doing isn't just a 2D renderer (Vello), this is just a small piece in a bigger UI toolkit (Xilem) that is aimed at addressing the problem I mention above.
Xilem originally started using the native libraries for 2D rendering (through a piet wrapper he discusses quickly in the video) but ended up being disappointed and switched to making his own, but that's just one piece of the puzzle. The end goal is a fact reactive UI framework.
>assuming that vaccination would indeed prevent transmission was a good guess based on prior vaccinations.
It wasn't.
First of all, they didn't need to guess, because immunology already knew that there is a difference between immunity in the mucus membranes (which is where respiratory infection has to be fought) versus in the blood. The latter is where the immune response is generated if you get an intramuscular injection. This turns out to be have been immunology 101, as testified by e.g. immunologist Liliane Schoofs to my government. You will also note subsequent efforts put into a nasal version of the vaccine that wouldn't have this design problem. There were, in fact, lies.
Second of all, the net effect of getting "vaccinated" was that people got a green pass to go out during winter time, sit across each other in bars and restaurants, and breathe each other's air, while explicitly believing they were immune, even though they were not. The argument that this was still a net positive seems preposterous and a form of magical thinking, where the people who got the ineffective shot were still somehow better off, even though they were engaging in far riskier behaviors.
The people who didn't get the shot meanwhile were forced to stay inside unless they were recently tested. So the hypothesis that the shots reduced illness by reducing transmission is likely also false. There is ample evidence now of spike protein being produced far longer than was ever promised in some patients, and also signs of immunodeficiency, which means the shots themselves were also not an unalloyed good.
What this thread mostly shows is that "anti-vax" remains a magical word, a dividing line between the Good People Who Believe Science and the Bad People Who Dismiss it. The actual details of the vaccine science are not known, and the story many people tell in retrospect does not hold up to basic scrutiny. They are willing to admit to individual instances of error, overstatement or deception in the management of COVID, but they are rarely willing to put them all together and see how this radically changes the entire picture.
Because what it looks like is an insane lobbying effort of governments and influencers, enormous amounts of public money being spent on shots we didn't need, a huge propaganda effort to silence any dissent as "anti-vax" and "anti-science", and all this because likely it did escape from a lab, and the people responsible for developing and funding it were terrified of being held accountable, and having their field shut down as the irresponsible LARP it was. Following some of these star virologists (e.g. Marion Koopmans) online is quite hilarious, because it is very obvious none of their excuses hold up.
Putting AI disclaimers at the end of your post seems like the wrong way to do it. If you feel the need to put a disclaimer, put it at the top. Otherwise, what's the point?
Notice how many of these were created after 2000, when efforts to get women into IT were already in full swing (certainly at my university).
Women have had two decades now to demonstrate that it was the fault of gatekeeping that certain parts of programming remain almost exclusively male (with the giant asterisk of MtF-trans being an oddly prevalent archetype, and thus, really a false signal).
It's sad, but the feminist perspective is to start from the assumption that sexism is the cause, and work backwards from that.
As someone else pointed out: there is no substitute for just doing the work, especially in a field where all you need to do is show up and publish. The barriers couldn't be lower, compared to virtually every other field, but that objective measure is irrelevant because the motivation is to validate a subjective feeling of collectivized mistreatment. The implication is that we are sorely missing out on some unique insights and contributions, and yet, everyone would welcome those insights, if they were there.
If you go look, you can find endless casual declarations about how women are better at communicating, empathizing, judgement and taste... but if there is even a single thing that it would appear men are always going to be better at, then that's treated as a Problem to be solved by complaining about it. This mainly serves to attract attention and resources so they can turn complaining into their job, or at least, a lucrative source of leads and income.
The feminist perspective is rooted in the massive amount of sexism and misogyny that necessitated the development of a feminist perspective.
If you'd like to know about CS in specific, here's a good paper from one of the few women who made it through to be a CS professor: https://dspace.mit.edu/handle/1721.1/7040
I happened to meet her at the 20 year anniversary of the paper and asked her if she was planning an update. As I recall it, she said that not much had changed, so she didn't see the point.
The idea that nothing has changed is by itself pretty preposterous. The gender ratio of college students is a big one, for instance, which keeps shifting in women's favor.
Plus, we just came out of a decade and a half of focused and persistent activism. If none of that changed anything, then a big lesson ought to be not to listen to the activists or their suggestions.
If you look at the outline of the paper, something should also stand out. Despite the fact that this claims to be science which examines the nature of how men and women are treated in CS, the ultimate focus is purely on confirming the pre-existing conclusions:
- that when women and men are being treated differently, this is always biased against women and in favor of men
- that it is the fault of men and male attitudes
- that is never the fault of women or female attitudes
In fact, feminism has a great sleight-of-hand that they consistently use for this. When they can blame men, they blame men. But if logic and evidence would require them to blame women, then it's suddenly the fault of "society", "unconscious biases" and "attitudes" whose origin is a mystery.
Just one example. While the paper dedicates a lot of ink to the ills of the "male environment", it does note that women communicate differently, e.g. with more "hesitation", "excessive qualifiers" and "excessively polite and deferential".
If you then go look at what the paper's recommendations are for women to "build confidence" it is to:
- attend classes with other women
- find female role models
- join women's groups
At no point is it considered that maybe women in a masculine environment should instead start acting and talking more like men, if they want the men to include them in their discussions and feel like she is one of them.
So yeah. Not much has changed. Not much will change. Because they keep entering a field full of people who are not like them, and expecting that mere complaints will feminize the whole lot.
I don't really see this as a productive perspective.
AS the paper says, there is no overt sexism and misogyny. Computer science lacks social appreciation in general. All you need to do to experience this is be a male software developer in Germany. Germany is a horrible country to be a software developer in. The silicon valley types and maybe the new yorkers have a strong prestigious tech culture, but go away from these tech hubs and you will encounter that software development is pretty much low status work. The envy comes from cherry picking the most successful men working in the most successful locations. A lot of men get into software because they play a lot of video games and want to make their own video games. They don't get paid very much, because they trade passion for less money. These days men get harassed for playing video games. They get harassed for their primary motivation to sit in front of the computer.
The paper also goes into the fact that men are pressured to perform and be successful. They don't have the luxury to sit things out because things are biased against them. If there is bias, then they are expected to overcome it through their own strength and to not rely on others. Take parts like this
"Singly, these behaviors probably have little effect. But when they occur again and again, they give a powerful message to women: they are not as worthwhile as men nor are they expected to participate fully in class, in college, or in life at large"
This seems incredibly outdated. These days things are swinging the exact opposite. Men are not considered as worthwhile as women, nor are they attending college and life at large as much as women, but here is the thing. Men are supposed to figure it out and face adversity themselves, whereas women often simply ask for help and support and they can often count on it. This means the pressure to perform simply isn't as high. Calling this "a bias" is essentially the same as begging for handcuffs and forced labor. The rat race must develop to a higher level.
I've written a similar `useDerivedState` hook before, which is basically formalizing the lastValue !== value / setLastValue pattern that the docs teach you.
But there is a major blind spot. The reason you want the dependencies is to reset the state when the outside demands it. But only way you can reset such a state is if the dependency _changes_. So it's not possible to reset the state back to the _same_ value as before.
To do that, you either need to manually manage the component lifecycle with a `key={..}` on the outside, or, you need to add e.g. a `version={N}` counter as an extra prop, to handle the edge case. Except, at that point, it makes more sense to rely on `version` entirely.
The 'proper' solution I've found is to actually write code to do what the policy and etiquette demands. E.g. for a number input, you can't aggressively reformat the contents because that's unusable, but you can check if the current text parses to the same value as before (if it is a valid number). There is no way to hide this sort of nuance with a generic state hook, it's too context-specific.
What is most useful is to treat the bridge between controlled and uncontrolled state as its own wrapper component, e.g. called <BufferedInput>, which has a render prop to actually render the <input> itself. It accepts a `value / onChange` on the outside, but passes on a different `text / onChange` to the inside. Give it a `parse`, `format` and `validate` prop that take functions, and you can clean up a lot of messy input scenarios.
This is the virtual DOM mental model of react, and it is pretty much entirely wrong.
- React doesn't really distinguish between DOM components and your own components in how it evaluates. It's all part of the same "VDOM" tree. Creating and updating HTML tags doesn't flow differently from updating the props on your own components.
- React does sparse updates, starting at the topmost component(s) whose state changed. Frequently this is just one widget or a button. Full tree re-evaluation is rare.
- If a component has the _exact_ same `children` prop as before (`===`), as is often the case with e.g. context providers, because it was assigned by a parent, then React will skip re-rendering the children entirely with no effort from the developer.
- If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before. This means even if your state lives high up in the tree, judicious use of memo can make it zippy af.
TLDR: If your react app is re-calculating the entire tree, you suck at react and you never bothered to learn it. Skill issue, git gud, etc. You're welcome.
> If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before
This works only with immutable data structures. Am I wrong? Because a modified array will pass the identity test (=== operator). If you are using mutable data structures, you cannot use identity operator to detect changes.
Also if "memo" optimization is that good why does one have to add it manually?
> If your react app is re-calculating the entire tree, you suck at react
The point of UI framework is to do the optimization for me and not require me to use some special style of coding like immutable structures or manually write functions like componentShouldUpdate. What I write is how UI variables depend on model variables and the rest is framework's job. I don't want to use weird patterns like a function with a giant switch that processes update events and clones the whole model graph to change a single variable.
Vue of course has its own set of issues, caused by using proxies (for example when adding on object to the set you must "unwrap" it manually to prevent adding a proxy to the set).
Yes, immutability is a requirement. And if you think that's a "special style of coding" then you probably haven't run into situations where that is a necessity, like optimistic updates with rollback, or undo/redo systems.
Mutable code is code that destroys the paper trail of what happened.
>The point of UI framework is to do the optimization for me
No, the point of the UI framework is to allow you to build applications that work correctly and perform well. The React style of coding is designed to scale up to large applications of e.g. a Figma or Excel caliber, while eliminating entire categories of subtle bugs. If you've never coded something like that, React will seem like it is getting in your way.
>Also if "memo" optimization is that good why does one have to add it manually?
Because the compute vs memory trade-off isn't always free, especially in a world where CPU computations are much faster than accessing uncached memory.
I would call this behavior solipsistic: the maker only engages with a caricature of their audience that happens to perfectly confirm their preconceptions, while handwaving away very simple and logical objections from the people in the room.
The weirdest part is them dressing it up as "you deserve better" when they are clearly ignoring their existing paying customers and retroactively stealing back content that was published and paid for.
The excuse that people didn't discover the toggle to skip disturbing scenes is ridiculous: just show it on first launch.
I suspect and wonder whether superhot vr was simply forced to remove this content to get first party promotion on certain platforms, and the reason it sounds illogical is because of Sinclair's maxim: they act like they don't understand because their income depends on not understanding it.
With all due respect to Dave, no. Please stop rewriting history without the relevant details.
CSS Zen Garden is a project that demonstrated that "progressive enhancement" and "semantic HTML" were nonsense. The only reason something like CSS Zen Garden worked at all is because all the markup is fixed, all the content is static, and the designs are not really responsive.
There is no CMS with a theming system that offers the flexibility that CSS Zen Garden claims one can have with a single .css, independent of the HTML. And this is because web developers were huffing the HTML/CSS gospel too much, fussing over not having extra divs in their source and what not, and celebrating "semantic HTML" without ever running their website through a screen reader.
The reason people stopped using table layout when they were doing CSS is because CSS1 did not support the _most common way of doing layout at the time_, and IE6 held the web hostage for a decade. This is a remarkable thing because it means everyone hopped on this bandwagon despite it being very obviously ill-informed and not ready for production. The CSS Zen Garden era designs can be expected to be full of float/clear tricks, requiring careful layout dependency between elements so everything gets pushed down just far enough. And it looks exactly like the table-based layouts they were replacing, except they will scale improperly or not at all.
The "status quo" attitude has also not vanished, as witnessed by CSS variables, custom properties and all the other epicycles that keep getting added on to CSS instead of actually just scrapping the parts that are dumb. None of these CSS experts have the vision or depth of experience to really know what it takes to implement what they spec, or what is even still relevant today and what isn't.
I actually implemented my own web layout system for Use.GPU from scratch, with flexbox and blackjack and hookers, and it's remarkable how much of HTML/CSS you don't need, and also, how many parts of it are still laughably inadequate (like text-ellipsis).
Dave did not win the argument. The people who celebrated CSS Zen Garden were cargo culters who confused a pretty design for a structurally sound layout, and who honestly just wanted something they could feel good about while dealing with pre-Firebug / pre-Dev Tools CSS development.
There is a really easy way to test this too, and I would challenge Dave to do it: translate all the content to another language. See how many of those beautiful CSS-only designs fall apart.
This sounds less like you want to correct something I have said that was inaccurate and more like you have a fundamental disagreement with the design of CSS.
Where in your comment did you mention the IE angle? The effect of lack of dev tools? Where did you mention the boondoggle of CSS2 tables and how everyone had to learn a whole new way of making floats behave? Where did you mention the laundry lists of named hacks that people used to get around browser parser differentials?
You didn't. You wrote the story as it is being told instead of how it happened.
I didn’t mention any of that because none of it is relevant to the point I was making about design.
> You wrote the story as it is being told instead of how it happened.
I did the opposite of that. I was very clearly and specifically recounting an aspect of the situation that is not being told today. When was the last time you heard somebody talk about how CSS could only create “boring, boxy” designs? It’s got to be about twenty years for me. It’s practically forgotten. Pointing that out was the whole purpose of my comment.
Both of your replies to me in this thread are about that chip on your shoulder, not about what I am saying. You should post your own thoughts as a top-level comment like I did, not get angry with me for not talking about what you want to talk about.
Pop quiz: make a 3 columns layout with fixed width header and sidebars, with a sticky footer at the bottom of the page, and which reaches full height even if the main content is shorter than the sidebar, or vice versa... even if the whole page is shorter than the browser. It must work in IE6-8.
>We lionized those who hurt others in the name of vision and made excuses for behavior that, in any other context, would be called what it is: toxic.
We wrapped cruelty in clever quotes and pointed to output as if it justifies everything that comes before it.
>[...]
>Genius doesn’t look like domination. It looks like collaboration. It looks like the humility to know you’re not the smartest person in every room, and the strength to make space for those who are. If someone needs to belittle, berate, or break others to feel powerful, they’re not a genius—they’re a tyrant in a hoodie, a bully with a pitch deck, a tantrum in search of a title.
>And we should stop fucking clapping.
Did... they read their own post? It's an arrogant rant that pre-assumes the entire stereotypical "toxic" frame, without questioning a single premise. This is always implicitly denouncing men and masculine behaviors. It has been repeated ad nauseam and used to beat people over the head with to "just fucking shut up" and let the queen bees "civilize" the icky nerd club.
The feminine counterpart behaviors, namely Mean Girlsing, emotional blackmail, smurfette syndrome, the accountability musical chairs, ... are always absent from the discourse.
When actual tech disasters happen, the emphasis is then on managing appearances instead of addressing root causes. I wrote a different take a while back, which highlights these patterns in the Crowdstrike discourse:
Despite wanting to talk, despite wanting to have "conversations", these sorts of arguments never get engaged with. Because the reason to critique "toxic" behaviors wasn't to get rid of them, but to demand a different set of toxic behaviors should take precedence.
The tech industry is going through a difficult time now with neurodivergent people. They really want to make use of the gifts of neurodivergent people to make them money but the neurodivergent often struggle to deal with the ever changing social rules of the modern workplace. Training programs tend to be ineffective because the rules are in constant flux and are often non-specific as to allow them to be interpreted in whatever way benefits those enforcing them.
Companies are slowly discovering that their ability to produce and operate is decaying from the inside by these types of policies. Rather than course correcting, many instead want to enshrine their hostile policies into law so all companies will be similarly hobbled. There have even been attempts to get companies delisted from stock exchanges for not going this route. It seems like there is some awareness in companies that this is harmful to the ability to function but there's no desire to undo the errors, with spreading the errors to all being the preferred solution.
This whole rant presents a false dichotomy, that you either communicate technical information with zero effort at interpersonal style, or you communicate with interpersonal style with no, or false, technical details. You frame turning criticism into constructive criticism as sugar coating or fluff. That interpersonal skill is the opposite of technical skill, rather than two different skills.
> Complaints that tech is too "male dominated" and "notoriously hostile to women" are often just this. Tech was always full of types who won't preface their proposals and criticisms with fluff, and instead lean into autism. When you're used to being pandered to, neutrality feels like vulgarity.
Communicating with other humans effectively is learned skill like any other. You just refuse to learn because it is more difficult for you than neurotypical people. But the funny thing is that women are harder to diagnose with autism because girls are pushed more to learn to socialize than boys, so they learn how to “mask” better. Boys are pandered to and not pushed to learn a difficult but much needed skill. They are given a pass in a way girls are not, so the neutrality of being told it is an important skill, just like every other field where humans communicate with other humans, feels like vulgarity.
The answer is not to pretend interpersonal communication is a pointless skill. The answer is to acknowledge and work with both sides, understanding that it is a skill that cannot just be ignored, and understanding that skill levels vary and we should account for, and work with, those various skill levels. You know, inclusivity rather than pandering to the entrenched culture.
> But they start from the conclusion and work their way backwards. This is what the rewritten statement does: it tries to fix the relationship before fixing the problem… The people who build and maintain the world's infrastructure prefer the masculine style for a reason: it keeps civilization running, and helps restore it when it breaks.
The irony of this is that you work from the conclusion, that masculine style is what “works”. That the relationship of masculine style and “civilization” are causal. Instead of fixing the problem, that industries that are male dominated have been restricted to women for most of human history. Women are 50% of the population but anything “feminine” is treated as some sort of weird small minority that should adapt to live in “real” society or stay out.
What projects like Slug and Vello rather show is that GPU coding remains so obtuse that you cannot tackle an isolated subproblem like 2D vector rendering, and instead have to make apple pie from scratch by first creating the universe. And then the resulting solution is itself a whole beast that cannot just be hooked up to other API(s) and languages than it was created for, unless that is specifically something you also architect for. As the first slide shows, v1 required modern GPUs, and the CPU side uses hand-optimized SIMD routines.
2D vector graphics is also just an awkward niche to optimize for today. GPUs are optimized for 3D, where z-buffers are used to draw things in an order-independent way. 2D graphics instead must be layered and clipped in the right order, which is much more difficult to 'embarrassingly' parallelize. Formats like SVG can have an endless number of points per path, e.g. a detailed polygon of the United States has to be processed as one shape, you can't blindly subdivide it. You also can't rely on vanilla anti-aliasing because complementary edges wouldn't be fully opaque.
Even if you do go all the way, you'll still have just a 2D rasterizer. Perhaps it can work under projective transform, that's usually pretty easy, but will it be significantly more powerful or extensible than something like Cairo is today? Or will it just do that exact same feature set in a technologically sexier way? e.g. Can it be adapted to rendering of 3D globes and maps, or would that break everything? And note that rasterizing fonts as just unhinted glyphs (i.e. paths) is rarely what people what.
reply