Blog post updates
This commit is contained in:
Keavon Chambers
parent
19b2d3f859
commit
44f3ad27ec
|
|
@ -7,7 +7,7 @@ banner = "https://static.graphite.rs/content/blog/2022-03-12-graphite-a-vision-f
|
|||
author = "Keavon Chambers"
|
||||
+++
|
||||
|
||||
Graphite is an open source, cross-platform digital content creation desktop and web application for 2D graphics editing, photo processing, vector art, digital painting, illustration, data visualization, compositing, and more. Inspired by the open source success of Blender in the 3D domain, it aims to bring 2D content creation to new heights with efficient workflows influenced by Photoshop/Gimp and Illustrator/Inkscape and backed by a powerful node-based, nondestructive approach proven by Houdini and Substance.
|
||||
Graphite is an open source, cross-platform digital content creation desktop and web application for 2D graphics editing, photo processing, vector art, digital painting, illustration, data visualization, compositing, and more. Inspired by the open source success of Blender in the 3D domain, it aims to bring 2D content creation to new heights with efficient workflows influenced by Photoshop/Gimp and Illustrator/Inkscape and backed by a powerful node-based, nondestructive approach proven by Houdini, Nuke, Blender, and others.
|
||||
|
||||
The user experience of Graphite is of central importance, offering a meticulously-designed UI catering towards an intuitive and efficient artistic process. Users may draw and edit in the traditional interactive (WYSIWYG) viewport with the Layer Tree panel or jump in or out of the node graph at any time to tweak previous work and construct powerful procedural image generators that seamlessly sync with the interactive viewport. A core principle of the application is its 100% nondestructive workflow that is resolution-agnostic, meaning that raster-style image editing can be infinitely zoomed and scaled to arbitrary resolutions at a later time because editing is done by recording brush strokes, vector shapes, and other manipulations parametrically.
|
||||
|
||||
|
|
@ -15,4 +15,4 @@ The user experience of Graphite is of central importance, offering a meticulousl
|
|||
|
||||
One might use the painting tools on a small laptop display, zoom into specific areas to add detail to finish the artwork, then perhaps try changing the simulated brush style from a blunt pencil to a soft acrylic paintbrush after-the-fact, and finally export the complete drawing at ultra high resolution for printing on a large poster.
|
||||
|
||||
On the surface, Graphite is an artistic medium for drawing anything imaginable— under the hood, the node graph in Graphite powers procedural graphics and parametric rendering to produce unique artwork and automated data-driven visualizations. Graphite brings together artistic workflows and empowers your creativity in a free, open source package that feels familiar but lets you delve further.
|
||||
On the surface, Graphite is an artistic medium for drawing anything imaginable. Under the hood, Graphite's node graph engine powers procedural graphics processing to produce unique artwork and automated data-driven visualizations. Graphite unlocks your creative potential in a familiar, free, accessible, and lightweight package.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,78 @@
|
|||
+++
|
||||
title = "Distributed computing in the Graphene runtime"
|
||||
date = 2022-05-12
|
||||
|
||||
[extra]
|
||||
banner = "https://static.graphite.rs/content/blog/2022-05-12-distributed-computing-in-the-graphene-runtime.png"
|
||||
author = "Keavon Chambers"
|
||||
+++
|
||||
|
||||
Graphite is a professional 2D graphics editor for photo editing, image manipulation, graphic design, illustration, data visualization, batch processing, and technical art. It is designed to run on a variety of machines, from mobile hardware like iPads or web browsers on midrange laptops up to beefy workstations with dozens of CPU cores and multiple GPUs.
|
||||
|
||||
To provide a responsive user experience, its architecture is made to support the use of distributed computation to make up for deficiencies in local compute power. Resulting productivity benefits will scale for users on hardware ranging from low-end mobile devices up to high-end workstations because documents and use cases can grow to great complexity.
|
||||
|
||||
This article explores the current thinking about the problems and potential engineering solutions involved in Graphite and Graphene for building a high-performance distributed computing runtime environment. We are only just embarking on the graph engine implementation, meaning this post describes theoretical approaches to theoretical challenges. The aim is to shed light on what will need to be built and what we currently believe is the trajectory for this work. We hope this post prompts discussions that evolve the concepts and approaches described herein. If this topic sounds interesting and you have feedback, please [get in touch](/contact).
|
||||
|
||||
<!-- more -->
|
||||
|
||||
# Node-based editing
|
||||
|
||||
A core feature is Graphite's reliance on procedural content generation using a node graph engine called Graphene. In traditional editors like Photoshop and Gimp, certain operations like "blur the image" modify the image pixels permanently, destroying the original (unblurred) image information.
|
||||
|
||||
Graphite is a *nondestructive* editor. Its approach is to represent the "blur" operation as a step in the creation process. All editing steps made by the user are encoded as operations, such as: import or resize an image, draw with a paintbrush, select an area with a certain color, combine two geometric shapes, etc.
|
||||
|
||||
Operations are functions that process information and are called *nodes*. For example, the "Blur" node takes an image and a strength value and outputs a blurred version of the image. On the advanced end, machine learning-powered nodes may do things like image synthesis or style transfer. Many nodes perform a wide variety of image editing operations and these are connected together into a directed acyclic graph where the final output is the pixels drawn to the screen or saved to an image file.
|
||||
|
||||
Many nodes process raster image data, but others work on data types like vector shapes, numbers, strings, colors, and large data tables (like imports from a spreadsheet, database, or CSV file). Some nodes perform visual operations like blur while others modify data, like performing regex matching on strings or sorting tables of information. For example, a CSV file might be imported, cleaned up, processed, then fed into the visual nodes which render it in the form of a chart.
|
||||
|
||||
Different nodes may take microseconds, milliseconds, seconds, or occasionally even minutes to run. Most should not take more than a few seconds, and those which take appreciable time should run infrequently. During normal operations, hundreds of milliseconds should be the worst case for ordinary nodes that run frequently. Caching is used heavily to minimize the need for recomputation.
|
||||
|
||||
## Node authorship
|
||||
|
||||
The nodes that process the node graph data can be computationally expensive. The goal is for the editor to ordinarily run and render (mostly) in real-time in order to be interactive. Because operations are arranged in a directed acyclic graph rather than a sequential list, there is opportunity to run many stages of the computation and rendering in parallel.
|
||||
|
||||
Nodes are implemented by us as part of a built-in library, and by some users who may choose to write code using a built-in development environment. Nodes can be written in Rust to target the CPU with the Rust compilation toolchain (made conveniently accessible for users). The same CPU Rust code can be reused (with modifications where necessary) for authoring GPU compute shaders via the [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) compiler. This makes it easier to maintain both versions without using separate code files and even languages between targets.
|
||||
|
||||
## Sandboxing
|
||||
|
||||
For security and portability, user-authored nodes are compiled into WebAssembly (WASM) modules and run in a sandbox. Built-in nodes provided with Graphite run natively to avoid the nominal performance penalty of the sandbox. When the entire editor is running in a web browser, all nodes use the browser's WASM executor. When running in a distributed compute cluster on cloud machines, the infrastructure provider may be able to offer sandboxing to sufficiently address the security concerns of running untrusted code natively.
|
||||
|
||||
# The Graphene distributed runtime
|
||||
|
||||
In the product architecture, Graphene is a distributed runtime environment for quickly processing data in the node graph by utilizing a pool of CPU and GPU compute resources available on local and networked machines. Jobs are run where latency, speed, and bandwidth availability will be most likely to provide a responsive user experience.
|
||||
|
||||
## Scheduler
|
||||
|
||||
If users are running offline, their CPU threads and GPU (or multiple GPUs) are assigned jobs by the local Graphene scheduler. If running online, some jobs are performed locally while others are run in the cloud, an on-prem compute cluster, or just a spare computer on the same network. The schedulers generally prioritize keeping quicker, latency-sensitive jobs local to the client machine or LAN while allowing slower, compute-intensive jobs to usually run on the cloud.
|
||||
|
||||
Each cluster in a locality—such as the local machine, an on-prem render farm, and the cloud data center—runs a scheduler that commands the available compute resources. The multiple schedulers in different localities must cooperatively plan the high-level allocation of resources in their respective domains while avoiding excessive chatter over the network about the minutiae of each job invocation.
|
||||
|
||||
## Cache manager
|
||||
|
||||
Working together with the scheduler, the Graphene cache manager stores intermediate node evaluation results and intelligently evicts them when space is limited. If the user changes the node graph, it can reuse the upstream cached data but will need to recompute downstream nodes where the data changed. Memoization can be used to avoid recomputation when an input to a node is the same as received in the past, and that result is available in the cache.
|
||||
|
||||
## Progressive enhancement
|
||||
|
||||
The scheduler and cache manager work in lockstep to utilize available compute and cache storage resources on the local machine or cluster in order to minimize latency for the user. Immediate feedback is needed when, for example, drawing with a paintbrush tool.
|
||||
|
||||
Sometimes, nodes can be run with quality flags. Many nodes (like the paintbrush rasterizer) are implemented using several different algorithms that produce different results trading off speed for quality. This means it runs once with a quick and ugly result, then runs again later to render a higher quality version, and potentially several times subsequently to improve the visual fidelity when the scheduler has spare compute resources and time. Anti-aliasing, for example, will usually pop in to replace aliased renders after a few seconds of waiting.
|
||||
|
||||
## Batched execution
|
||||
|
||||
It is important to reduce the overhead between executions. Sometimes, Graphene will predict, or observe during runtime, the frequent execution of code paths (or rather, *node paths*) with significant sequential (not parallel) execution steps. These are good candidates for optimization by reducing the overhead between each execution.
|
||||
|
||||
In these cases, Graphene will batch multiple sequentially-run nodes by recompiling them such that they are inlined as one execution unit. This can happen for both CPU-based programs and GPU-based compute shaders. This is conceptually similar to how just-in-time (JIT) compilers can predict, or observe at runtime, frequently-run code paths in order to apply compiler optimizations where they are most impactful.
|
||||
|
||||
## Data locality
|
||||
|
||||
When dealing with sequential chains of nodes, if they haven't already been recompiled as a batched execution unit, the Graphene scheduler may also frequently prioritize grouping together a set of related nodes to be run together on the same machine for memory and cache locality.
|
||||
|
||||
Sequential nodes allocated to the same physical hardware can avoid the overhead of copying data over the internet, or between machines in the cluster, or between RAM and VRAM, or from RAM to the CPU cache.
|
||||
|
||||
Graphene should recognize when a certain intermediate result already lives in RAM or VRAM and prioritize using that CPU or GPU to compute the tasks which rely on that data. But when that's not possible, we need a fast architecture to transfer data between machines. For GPUs, it might be possible to use a DMA (Direct Memory Access) strategy like Microsoft's new DirectStorage API for DirectX and transfer data into or out of VRAM straight to SSDs or networked file systems. Efficiently transferring the final result, and maybe occasionally intermediate cache results, between networks (like the cloud and client) with latency and bandwidth considerations is also important.
|
||||
|
||||
# Conclusion
|
||||
|
||||
Presently, we are [experimenting](https://github.com/GraphiteEditor/NodeGraphExperiments) with CPU and GPU node composition for the beginnings of the Graphene visual programming language. Most of what was described in this post will likely evolve as we get further into the implementation stage and when we learn more from experts in the fields of computer science that Graphene overlaps with.
|
||||
|
||||
If you have a background or interest in programming language design, functional programming, ECS and data-oriented design, scheduling, distributed computing, general-purpose GPU compute (GPGPU), or high-performance computing (HPC), we'd love to have your ideas steer our work. Or better yet, join the team to make this dream a reality. We discuss most of our architecture and designs on our [Discord server](https://discord.graphite.rs) through text and sometimes voice. Please come say hi!
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
+++
|
||||
title = "Distributed computing with the Graphene runtime"
|
||||
date = 2022-04-18
|
||||
|
||||
[extra]
|
||||
banner = "2022-03-12-graphite-a-vision-for-the-future-of-2d-content-creation.png"
|
||||
author = "Keavon Chambers"
|
||||
+++
|
||||
|
||||
Graphite is a professional 2D graphics editor for photo editing, image manipulation, graphic design, illustration, data visualization, automation, and technical art. It is designed to run on a variety of machines, from mobile hardware like iPads or web browsers on midrange laptops up to beefy workstations with dozens of CPU cores and multiple GPUs. To provide a responsive user experience, its architecture is made to support the use of cloud computation to make up for deficiencies in local compute power, even providing some productivity improvements for high-end workstation users thanks to the wide scalability of distributed rendering.
|
||||
|
||||
# Node-based editing
|
||||
|
||||
A core feature is Graphite's reliance on procedural content generation using a node graph system called Graphene. In traditional editors like Photoshop and Gimp, certain operations like "blur the image" modify the image pixels permanently, destroying the original (unblurred) image information.
|
||||
|
||||
Graphite is a *nondestructive* editor. Its approach is to store the "blur" operation as a step in the creation process. All editing steps made by the user are encoded as operations, such as: import or resize an image, draw with a paintbrush, select an area with a certain color, combine two geometric shapes, etc. Operations are functions that process information and are called *nodes*. For example, the "Blur" node takes an image and a strength value and outputs a blurred version of the image. More advanced, machine learning-powered nodes may do things like image synthesis or style transfer. Many nodes perform a wide variety of image editing operations and these are connected together into a directed acyclic graph where the final output is the pixels drawn to the screen or saved to an image file.
|
||||
|
||||
Many nodes process raster image data, but others work on data types like vector shapes, numbers, strings, colors, and large data tables (like imports from a spreadsheet, database, or CSV file). Some nodes perform visual operations like blur while others modify data, like performing regex matching on strings or sorting tables of information. For example, a CSV file might be imported, cleaned up, processed, then fed into the visual nodes which render it in the form of a chart. Different nodes may take microseconds, milliseconds, seconds, or occasionally even minutes to run. Most should not take more than a few seconds, and those which take so long should run infrequently. During normal operations, hundreds of milliseconds should be the worst case for ordinary nodes that run frequently. Caching is used heavily to minimize the need for recomputation.
|
||||
|
||||
## Node authorship
|
||||
|
||||
The nodes that process the data can be computationally expensive. The goal is for the editor to ordinarily run and render (mostly) in real-time in order to be interactive. Because operations are arranged in a directed acyclic graph rather than a sequential list, there is opportunity to run many stages of the computation and rendering in parallel.
|
||||
|
||||
Nodes are implemented by us as part of a built-in library, and by some users who may choose to write code using a built-in development environment. Nodes can be written in Rust to target the CPU with the Rust compilation toolchain (made conveniently accessible for users). The same CPU Rust code can often be reused for authoring GPU compute shaders via the [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) compiler.
|
||||
|
||||
## Sandboxing
|
||||
|
||||
For security and portability, user-authored nodes are compiled into WebAssembly (WASM) modules and run in a sandbox. Built-in nodes run natively, and are not sandboxed, for better performance (except when the entire editor is running in a web browser). When running in a distributed compute cluster on cloud machines, the infrastructure provider may be able to offer sandboxing to sufficiently address the security concerns of running untrusted code in order to safely use the native (non-WASM) versions of nodes.
|
||||
|
||||
# The Graphene distributed runtime
|
||||
|
||||
In the product architecture, Graphene is a distributed runtime environment for quickly processing data in the node graph by utilizing a pool of CPU and GPU compute resources available on local and networked machines. Jobs are run where latency, speed, and bandwidth availability will be most likely to provide a responsive user experience.
|
||||
|
||||
## Scheduler
|
||||
|
||||
If users are running offline, their CPU threads and GPU (or multiple GPUs) are assigned jobs by the local Graphene master scheduler. If running online, some jobs are performed locally while others are run in the cloud, an on-premise compute cluster, or just a spare computer on the same network. The scheduler generally prioritizes keeping quicker, latency-sensitive jobs local to the client machine or LAN while allowing slower, compute-intensive jobs to usually run on the cloud. Each networked cluster (such as the local machine, an on-prem render farm, and the cloud data center) runs a master scheduler that commands the available compute resources. The multiple master schedulers (of which one may be authoritative) must cooperatively plan the high-level allocation of resources in their respective domains while avoiding excessive chatter over the internet about the minutiae of each job invocation.
|
||||
|
||||
## Cache manager
|
||||
|
||||
Working together with the scheduler, the Graphene cache manager stores intermediate node evaluation results and intelligently evicts them when space is limited. If the user changes the node graph partially downstream, it can reuse the upstream cached data but will need to recompute changed downstream operations. When rendering raster imagery, areas of the image are broken down into tiles at a certain resolution (document zoom depth) and cached on a per-tile basis. Tiles are used because the whole document is too large to render all at once every time changes occur, since some parts may be outside the confines of the current viewport, and because changes may only invalidate portions of the document so only those tiles need to re-render.
|
||||
|
||||
## Progressive enhancement
|
||||
|
||||
The scheduler and cache manager work in lockstep to utilize available compute and cache storage resources on the local machine or cluster in order to minimize latency for the user. Immediate feedback is needed when, for example, drawing with a paintbrush tool. Sometimes, nodes can be run with quality flags. Many nodes are be implemented using several different algorithms that produce faster results of worse quality. This means it runs once with a quick and ugly result, then runs again later to render a higher quality version, and potentially several times subsequently to improve the visual fidelity when the scheduler has spare compute resources and time. Anti-aliasing, for example, will usually pop in to replace aliased renders after a few seconds of waiting.
|
||||
|
||||
## Batched execution
|
||||
|
||||
It is important to reduce the overhead between executions. Sometimes, Graphene will predict, or observe during runtime, the frequent execution of code paths (or rather, node paths) with significant sequential (not parallel) execution steps. These are good candidates for optimization by reducing the overhead between each execution. In these cases, Graphene will batch multiple sequentially-run nodes by recompiling them such that they are inlined as one execution unit. This can happen for both CPU-based programs and GPU-based compute shaders. This is conceptually similar to how just-in-time (JIT) compilers can predict, or observe at runtime, frequently-run code paths in order to apply compiler optimizations where they are most impactful.
|
||||
|
||||
## Data locality
|
||||
|
||||
When dealing with sequential chains of nodes, if they haven't been recompiled as a batched execution unit, the Graphene scheduler may also frequently prioritize grouping together a set of related nodes to be run together on the same machine for memory and cache locality. Sequential nodes allocated to the same physical hardware can avoid the overhead of copying data over the internet, or between machines in the cluster, or between RAM and VRAM, or from RAM to the CPU cache. Graphene should recognize when a certain intermediate result already lives in RAM or VRAM and prioritize using that CPU or GPU to compute the tasks which rely on that data. But when that's not possible, we need a fast architecture to transfer data between machines. For GPUs, it might be possible to use a DMA (Direct Memory Access) strategy like Microsoft's new DirectStorage API for DirectX and transfer data into or out of VRAM straight to SSDs or networked file systems. Efficiently transferring the final result, and maybe occasionally intermediate cache results, between networks (like the cloud and client) with latency and bandwidth considerations is also important.
|
||||
|
|
@ -87,9 +87,16 @@ Because this is cumbersome, we have a proc macro `#[child]` that automatically i
|
|||
|
||||
The Graphite project highly values code quality and accessibility to new contributors. Therefore, please make an effort to make your code readable and well-documented.
|
||||
|
||||
**Naming:** Descriptive variable names, and not abbreviated naming conventions, is encouraged. Prefer to spell out full words most of the time, so `gen_doc_fmt` should be written out as `generate_document_format` instead. This avoids the mental burden of expanding abbreviations into semantic meaning. Monitors are wide enough to display long variable/function names, so descriptive is better than cryptic.
|
||||
**Naming:** Please use descriptive variable/function/symbol names and keep abbreviations to a minimum. Prefer to spell out full words most of the time, so `gen_doc_fmt` should be written out as `generate_document_format` instead. This avoids the mental burden of expanding abbreviations into semantic meaning. Monitors are wide enough to display long variable/function names, so descriptive is better than cryptic.
|
||||
|
||||
**Tests:** It's great if you can write tests for your code, especially if it's a tricky stand-alone function. However at the moment, we are prioritizing rapid iteration and will usually accept code without associated unit tests. That stance will change in the near future as we begin focusing more on stability than iteration.
|
||||
**Imports:** At the top of Rust files, please follow the convention of separating imports into three blocks, in this order:
|
||||
1. Local (`use super::` and `use crate::`)
|
||||
2. First-party crates (e.g. `use graphene::`)
|
||||
3. Third-party libraries (e.g. `use std::` or `use serde::`)
|
||||
|
||||
Combine related imports with common paths at the same depth. For example, the lines `use crate::A::B::C;`, `use crate::A::B::C::Foo;`, and `use crate::A::B::C::Bar;` should be combined into `use crate::A::B::C::{self, Foo, Bar};`. But do not combine imports at mixed path depths. For example, `use crate::A::{B::C::Foo, X::Hello};` should be split into two separate import lines. In simpler terms, avoid putting a `::` inside `{}`.
|
||||
|
||||
**Tests:** It's great if you can write tests for your code, especially if it's a tricky stand-alone function. However at the moment, we are prioritizing rapid iteration and will usually accept code without associated unit tests. That stance will change in the near future as we begin focusing more on stability than iteration speed.
|
||||
|
||||
Additional best practices will be added here soon. Please ask @Keavon in the mean time.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,10 +17,11 @@
|
|||
height: auto;
|
||||
}
|
||||
|
||||
hr {
|
||||
margin-top: calc(40px - 20px);
|
||||
margin-bottom: 40px;
|
||||
}
|
||||
}
|
||||
|
||||
hr {
|
||||
margin-top: 40px;
|
||||
margin-bottom: 40px;
|
||||
}
|
||||
|
||||
article {
|
||||
|
|
@ -44,4 +45,9 @@
|
|||
font-size: var(--font-size-article-h3);
|
||||
}
|
||||
}
|
||||
|
||||
.social {
|
||||
display: flex;
|
||||
gap: 20px;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ body {
|
|||
width: 100%;
|
||||
height: 100%;
|
||||
margin: 0;
|
||||
background: var(--color-manilla);
|
||||
background: white;
|
||||
font-family: "Inter", sans-serif;
|
||||
line-height: 1.5;
|
||||
font-weight: 500;
|
||||
|
|
@ -179,7 +179,7 @@ pre {
|
|||
kbd {
|
||||
background: var(--color-fog);
|
||||
border-radius: calc(var(--variable-px) * 4);
|
||||
outline: var(--border-thickness) solid var(--color-navy);
|
||||
outline: calc(var(--border-thickness) / 2) solid var(--color-navy);
|
||||
padding: 0 4px;
|
||||
margin: 0 4px;
|
||||
color: var(--color-navy);
|
||||
|
|
@ -214,6 +214,16 @@ summary {
|
|||
text-decoration: none;
|
||||
font-weight: 800;
|
||||
white-space: nowrap;
|
||||
|
||||
img {
|
||||
height: calc(var(--font-size-link) * 1.5);
|
||||
margin-right: calc(var(--font-size-link) / 2);
|
||||
}
|
||||
|
||||
img,
|
||||
span {
|
||||
vertical-align: middle;
|
||||
}
|
||||
}
|
||||
|
||||
.arrow::after {
|
||||
|
|
@ -435,7 +445,7 @@ hr,
|
|||
content: " »";
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
img {
|
||||
display: block;
|
||||
width: var(--height);
|
||||
|
|
@ -452,7 +462,7 @@ hr,
|
|||
--nav-font-size: 26px;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@media screen and (max-width: 760px) {
|
||||
gap: 20px;
|
||||
|
||||
|
|
@ -462,7 +472,7 @@ hr,
|
|||
--nav-font-size: 22px;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@media screen and (max-width: 600px) {
|
||||
gap: 16px;
|
||||
|
||||
|
|
@ -566,17 +576,17 @@ hr,
|
|||
gap: 40px;
|
||||
padding: 40px;
|
||||
padding-top: 0;
|
||||
|
||||
|
||||
nav {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
justify-content: center;
|
||||
gap: 8px 40px;
|
||||
|
||||
|
||||
@media screen and (max-width: 900px) {
|
||||
max-width: 500px;
|
||||
}
|
||||
|
||||
|
||||
@media screen and (max-width: 760px) {
|
||||
max-width: 440px;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -9,10 +9,15 @@
|
|||
margin-top: 20px;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
&.color {
|
||||
background-color: var(--color-fog);
|
||||
background-blend-mode: color-burn;
|
||||
}
|
||||
|
||||
&.light {
|
||||
background-color: var(--color-manilla);
|
||||
background-blend-mode: hard-light;
|
||||
background-blend-mode: color-burn;
|
||||
}
|
||||
|
||||
&.dark {
|
||||
|
|
@ -25,11 +30,6 @@
|
|||
}
|
||||
}
|
||||
|
||||
&.light {
|
||||
background-color: var(--color-fog);
|
||||
background-blend-mode: color-burn;
|
||||
}
|
||||
|
||||
.box {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
|
|
@ -42,13 +42,13 @@
|
|||
img {
|
||||
max-width: calc(100vw - 2 * 80 * var(--variable-px));
|
||||
}
|
||||
|
||||
|
||||
span {
|
||||
font-weight: 800;
|
||||
margin-top: 20px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
|
||||
a {
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -3,6 +3,10 @@
|
|||
|
||||
{% block head %}
|
||||
<link rel="stylesheet" href="/article.css">
|
||||
<meta property="og:title" content="{{ page.title }}.">
|
||||
<meta property="og:type" content="article" />
|
||||
<meta property="og:image" content="{{ page.extra.banner }}">
|
||||
<meta property="og:url" content="{{ current_url }}">
|
||||
{% endblock head %}
|
||||
|
||||
{% block content %}
|
||||
|
|
@ -12,11 +16,26 @@
|
|||
<h2 class="headline">{{ page.title }}.</h2>
|
||||
<span class="publication">By {{ page.extra.author }}. {{ page.date | date(format="%B %d, %Y", timezone="America/Los_Angeles") }}.</span>
|
||||
<img class="banner" src="{{ page.extra.banner }}" />
|
||||
<hr />
|
||||
</div>
|
||||
<hr />
|
||||
<article>
|
||||
{{ page.content | safe }}
|
||||
</article>
|
||||
{% if page.extra.reddit or page.extra.twitter %}
|
||||
<hr />
|
||||
<div class="social">
|
||||
{% if page.extra.reddit %}
|
||||
<a href="{{ page.extra.reddit | safe }}" target="_blank" class="button arrow">
|
||||
<img src="https://static.graphite.rs/icons/reddit.svg" /><span>Comment on Reddit</span>
|
||||
</a>
|
||||
{% endif %}
|
||||
{% if page.extra.twitter %}
|
||||
<a href="{{ page.extra.twitter | safe }}" target="_blank" class="button arrow">
|
||||
<img src="https://static.graphite.rs/icons/twitter.svg" /><span>Comment on Twitter</span>
|
||||
</a>
|
||||
{% endif %}
|
||||
</div>
|
||||
{% endif %}
|
||||
</div>
|
||||
</section>
|
||||
{% endblock content %}
|
||||
|
|
|
|||
Loading…
Reference in New Issue