What's everyone working on this week (44/2017)?

New week, new Rust! What are you folks up to?

I am using Rust for Scientific Computing :slight_smile: More precisely replacing python scripts for running simulations (C++ code) in batch (with rayon) after some data processing. Could not be happier!

Next step would be to replace C++/Eigen completely.

2 Likes

Indigo UI Framework

This past week I got some more work done on Indigo, my UI framework prototype for Rust. (See last week here
This week saw some changes to the style system and how the markup plugin works.

Here's what's new:

Style changes

I spent some time simplifying the style system and doing related work in RSX to make things less confusing.

Previously you'd declare an RSX node like so:

ui!(<StackPanel Alignment={Alignment::Stretch}>
	<Button Height=400. />
	<Button Height=400. />
    </StackPanel />);

and the attributes would get collected and built into a Style (collection of properties) struct of "explicit" properties which was then merged into the "resolved" style (as a result of finding which Style the element's StyleId resolved to).

In an effort to simplify things, I did away with the notion of StyleId and with StyleContext (a collection of Styles per component) and made it so that each element has a default style (defined in the Component using the #[component] derived plugin) and an explicit Style (passed into the element using the Style attribute on the RSX node).

Every other attribute that isn't named Style gets built into a separate struct and passed as a "props" object to the component.
In addition to simplifying Styling, this fixes a long standing issue with RSX where the direct content nodes would be "erased" after the plugin expanded the RSX syntax the initial time. This made invalidation (which is done with subsequent calls to render) have corner cases where the children of components (Say a StackPanel) would disappear.

I plan on integrating the props definition into my #[component] derive plugin so that you can define it more naturally via a props! macro inside of the trait impl.

Here's some code showing off the implementation of the StackPanel component:

#[derive(Debug, Default)]
pub struct StackPanelProps {
    pub children: Vec<ComponentRef>,
    pub Orientation: Orientation
}


#[component]
impl Component for StackPanel {
    fn default_style(&self) -> Option<Style> {
        Some(style! {
            Layout: Layout::Stack(StackLayout(self.props.Orientation));
        })
    }

    fn render(&mut self) -> Vec<NodeRef<Box<Component>>> { 
        let children = self.props.children.clone().into_iter().flat_map(|ele| {
            ele
        }).collect();
        children
    }
}

You'll notice the render() function operates on the children passed as props, collected into a flattened vector of components. Also default_style() uses the Orientation prop and passes that to layout.

This lets the component author selectively expose props on their Component to allow more expressiveness in defining their component input.

All of this paves the way for more straight forward invalidation of the visual tree with weird issues.

Drop Shadow support

I added support for the DropShadowProperty which hooks into WebRender's box shadow support. It supports multiple shadows per primitive:

#[derive(Clone)]
pub struct DropShadow {
    pub blur_radius: f32,
    pub spread_radius: f32,
    pub x_offset: f32,
    pub y_offset: f32,
    pub shadow_color: webrender_api::ColorF,
    pub shadow_type: ShadowType
}

#[derive(Copy, Clone)]
pub enum ShadowType {
    Outset,
    Inset
}

and used in a Style:

let scroll_viewer_style = style! {
	...
	DropShadow: vec![
	    DropShadow::new(
	        ShadowType::Outset,
	            0., 2.,
	            4., 0.,
                ColorF::new(0., 0., 0., 0.2)
	        ),                              
	    DropShadow::new(
		    ShadowType::Outset,
	            0., 25.,
	            50., 0.,
                ColorF::new(0., 0., 0., 0.1)
	        ),
	];
};

which is then passed to a Component:

<ScrollViewer Style={scroll_viewer_style}>
	...
</ScrollViewer>

I posted this late last week, but here's a screenshot of a work in progress TodoMvc port for Indigo.

Next week

I hope to finish my internal refactoring to make invalidation really rock solid and also perhaps start on an TextBox component. Perhaps even add styled text runs for the TextBlock component.

4 Likes

Finally got some time to focus on uom (type-safe zero-cost dimensional analysis) over the weekend and made big process on my efforts to support non-floating point underlying storage types. I'm down to two failing tests from before the change!

1 Like

More env_logger this week. We're getting pretty close to covering off all the features we want to support in the next version, which is exciting :smiley:

I'm also starting to accrue a stack of [WIP] PRs that I should really get around to finishing before opening a bunch more...

I've released very first version of my new max-quality GIF maker — gif.ski.

Combining multiple crates for this (imagequant, gif, rayon) made it quick to develop, and was able to play with various massively-parallel ways of processing (but for quality of the algorithm needs to generate frames serially and hits Amdahl's law hard :/).

I'm still wrangling with framerates and aspect ratios in videos, which seem utterly impossible to get right.

5 Likes