enum Node {
Group(Group),
Fill(Fill),
Stroke(Stroke),
Clip(Clip),
}| # Script to decompose components with mismatched 2x2 matrix | |
| # See https://github.com/googlefonts/fontmake/issues/595 | |
| for glyph in Glyphs.font.glyphs: | |
| #print glyph | |
| xforms = [] | |
| mismatch = [] | |
| for (i, layer) in enumerate(glyph.layers): | |
| for (j, component) in enumerate(layer.components): | |
| if i == 0: | |
| xforms.append(component.transform) |
Kenny Kerr posted My Rust adventure begins this morning, and I tweeted "This seems like a pretty big deal - Rust is uniquely able to bridge the gap between performant systems programming and the safe, high level abstractions needed to build applications." This was a strong statement, and sparked a little discussion, so I'd like to clarify a bit.
The main controversy was about whether Rust is truly unique in this regard, or whether other languages can possibly satisfy the requirement of being a solid foundation for operating systems while also avoiding the pitfalls of C and C++. I argue that this role requires a language to be suitable for a very wide range of problem domains. Latency-critical applications such as pro audio are a fairly minor niche, and the vast majority of things people do at computers don't require that kind of low-level control, but if supporting, say, pro audio is one of the requirements
| // | |
| // AppDelegate.m | |
| // Pasteboard toy | |
| // | |
| // Created by Raph Levien on 8/10/19. | |
| // Copyright © 2019 Raph Levien. All rights reserved. | |
| // | |
| #import "AppDelegate.h" |
| ======================== | |
| creating window... | |
| width: 1424 | |
| height: 704 | |
| tile_side_length_in_pixels: 8 | |
| per_tile_command_lists_num_tiles_per_tg_x: 32 | |
| per_tile_command_lists_num_tiles_per_tg_y: 1 | |
| num_tiles_x: 192 | |
| num_tiles_y: 88 | |
| canvas_quad_width: 1536 |
| pub trait Lens<T, U> { | |
| fn get<'a>(&self, data: &'a T) -> &'a U; | |
| fn with_mut<F: FnOnce(&mut U)>(&self, data: &mut T, f: F); | |
| } |
| layout | post | ||
|---|---|---|---|
| title | The smooth resize test | ||
| date | 2019-06-17 07:26:42 -0700 | ||
| categories |
|
When I was young, as we traveled my dad had a quick test for the quality of a Chinese restaurant: if the tea wasn't good, chances were the food wouldn't be great either. One time, we left before ordering, and I don't think we missed out on much.
Today is an exciting point in the evolution of native GUI in Rust. There is much exploration, and a number of promising projects, but I also think we don't yet know the recipe to make GUI truly great. As I develop my own vision in this space, [druid], I hope more that the efforts will learn from each other and that an excellent synthesis will emerge, more so than simply hoping that druid will win.
| // Sketch of new widget scheme for druid. Some pseudocode within. | |
| /// Base of a widget. | |
| /// | |
| /// Name should likely change, this name is chosen to express | |
| /// what's actually in it. | |
| pub struct Base<W: WidgetInner> { | |
| state: BaseState, | |
| inner: W, |
This crate contains an implementation of Radial Basis Function multidimensional interpolation. For an excellent introduction to the topic, see the [SIGGRAPH 2014 course notes].
The input is a set of datapoints, each of which has coordinates in some multidimensional
space, and a value, also provided as a vector. For example, for the colorfield images below,
the coordinates are 2D, and the values are a 3-vector, one each for red, green, and blue.
The result is a Scatter struct that can then be evaluated at any coordinate. The idea
is that the values vary smoothly with the coordinates, but coincide with the input at each