diff --git a/README.md b/README.md index 17469574..53ed670c 100644 --- a/README.md +++ b/README.md @@ -18,9 +18,13 @@ Launch the latest alpha release of the [Graphite editor](https://editor.graphite ⭐ Please remember to star this project here on GitHub! ⭐ -[![Vector artwork: "Valley of Spires"](https://static.graphite.rs/content/index/gui-demo-valley-of-spires__3.png)](https://editor.graphite.rs/#demo/valley-of-spires) +[![Vector artwork: "Red Dress"](https://static.graphite.rs/content/index/gui-demo-red-dress.png)](https://editor.graphite.rs/#demo/red-dress) -*[Click here](https://editor.graphite.rs/#demo/valley-of-spires) to open this artwork and explore it yourself.* +*[Red Dress](https://editor.graphite.rs/#demo/red-dress) (click to open this artwork and explore it yourself)* + +[![Vector artwork: "Valley of Spires"](https://static.graphite.rs/content/index/gui-demo-valley-of-spires__4.png)](https://editor.graphite.rs/#demo/valley-of-spires) + +*[Valley of Spires](https://editor.graphite.rs/#demo/valley-of-spires) (click to open this artwork and explore it yourself)* ## Discord community diff --git a/libraries/bezier-rs/src/symmetrical_basis.rs b/libraries/bezier-rs/src/symmetrical_basis.rs index 8b11f514..f0493b18 100644 --- a/libraries/bezier-rs/src/symmetrical_basis.rs +++ b/libraries/bezier-rs/src/symmetrical_basis.rs @@ -33,8 +33,8 @@ * https://www.mozilla.org/MPL/1.1/ * * This software is distributed on an "AS IS" basis, WITHOUT WARRANTY - * OF ANY KIND, either express or implied. See the LGPL or the MPL for - * the specific language governing rights and limitations. + * OF ANY KIND, either express or implied. See the MPL for the specific + * language governing rights and limitations. */ use crate::{Bezier, BezierHandles}; diff --git a/website/content/about.md b/website/content/about.md index 0eb41d9e..77eda2c6 100644 --- a/website/content/about.md +++ b/website/content/about.md @@ -116,7 +116,7 @@ It's easy to learn and teach, yet Graphite's accessible design does not sacrific
-
+
Photo of Keavon Chambers @@ -131,7 +131,7 @@ It's easy to learn and teach, yet Graphite's accessible design does not sacrific Keavon is a creative generalist with a love for the fusion of arts and technology. Photographer, UX and graphic designer, technical artist, game developer, and everything in-between— he is equal parts designer and engineer. His multidisciplinary background in the digital arts is aptly suited for concocting the unique vision needed to bring Graphite to fruition.
-
+
Photo of Dennis Kobert @@ -146,7 +146,7 @@ Keavon is a creative generalist with a love for the fusion of arts and technolog Dennis is a mix between a mathematician and a mad scientist. While still enjoying the art of photography and image editing (which drew him to the project early on), he thrives when challenged with designing complex systems and pushing boundaries. His method of building generalized solutions wrapped in elegant layers of abstraction led to his creation of the Graphene engine.
-
+
Photo of Hypercube diff --git a/website/content/features.md b/website/content/features.md index a8dcd5b2..8e81bf13 100644 --- a/website/content/features.md +++ b/website/content/features.md @@ -213,7 +213,7 @@ Always on the bleeding edge and built to last— Graphite is written on a robust
- Internationalization and accessability + Internationalization and accessibility
diff --git a/website/content/volunteer/guide/projects/student-projects.md b/website/content/volunteer/guide/projects/student-projects.md index 224caa3f..de0364c3 100644 --- a/website/content/volunteer/guide/projects/student-projects.md +++ b/website/content/volunteer/guide/projects/student-projects.md @@ -5,9 +5,9 @@ title = "Student projects" order = 1 # Page number after chapter intro +++ -Graphite offers a number of opportunities for students to contribute by building a self-contained project as part of a structured format. These projects are designed to be completed over several months and are ideal for Google Summer of Code or similar internship programs, solo or group university capstone projects, or other arrangements. Each project has a distinct focus and is a great way to make a meaningful contribution to open source over the length of the program while receiving mentorship and guidance from the Graphite team. Student projects require adherence to a set schedule with regular check-ins, milestones, and evaluations. +Graphite offers a number of opportunities for students to contribute by building a self-contained project as part of a structured format. These projects are designed to be completed over several months and are ideal for Google Summer of Code or similar internship programs, solo or group university capstone projects, and other arrangements. Each project has a distinct focus and is a great way to make a meaningful contribution to open source over the length of the program while receiving mentorship and guidance from the Graphite team. -The structured setting is designed to provide a supportive environment for students to learn and grow as developers while gaining real-world industry experience from collaborating on a sizable software product and remaining accountable to stakeholders. +Student projects require adherence to a set schedule with regular check-ins, milestones, and evaluations. The structured setting is designed to provide a supportive environment for students to learn and grow as developers while gaining real-world industry experience from collaborating on a sizable software product and remaining accountable to stakeholders. It's our goal to make sure you succeed! To date, three student project experiences have been completed successfully. [See below](#successful-past-projects) for summaries to get a feel for what has worked before. @@ -21,57 +21,195 @@ GSoC is a program offering students a stipend for successful completion of an in Writing a good proposal is an important first step that demonstrates your understanding of the project and your ability to plan and execute it. A well-defined proposal will set you up for success throughout the rest of the program. -You are encouraged to reference the project idea list below to find several potential projects suited to your experience, interest, and choice of scope. Then, we highly recommend reaching out to a core team member through Discord to discuss your plan in detail before writing a proposal. This will help you understand the project's scope and requirements, and it will help us understand your background and capabilities to offer you feedback and suggestions for the best outcome. +You are encouraged to reference the project idea list below to find several potential projects suited to your experience, interest, and choice of scope. Then, we highly recommend reaching out to a [core team member](/about#core-team) through Discord to discuss your plan in detail before writing a proposal. This will help you understand the project's scope and requirements. It will also help us understand your background and capabilities to offer you feedback and suggestions for the best outcome. + +When it comes to writing the proposal, which you will submit to the GSoC application website, we offer some guidelines below: + +- **Proposal structure:** Please consult the [Blender GSoC application template](https://developer.blender.org/docs/programs/gsoc/application_template/) as reference for our desired format. +- **Your background:** We're especially interested in your background and experience, so attaching a résumé or CV is optional but suggested and will help us understand your capabilities. If able, please also include links to evidence of past open source contributions or personal projects in the bio section of your proposal. Our goal is to help you learn and grow as an open source software engineer, not in helping you learn to program from scratch, so any such evidence will help us understand your potential as a self-motivated contributor to the open source community. +- **Prior PRs:** If you have made any contributions to Graphite or other open source projects, please include links to your pull requests in your proposal. We put extra weight towards applicants who have already made contributions to Graphite because this demonstrates your ability to work in a professional capacity with our team and demonstrates your interest in Graphite in particular (as opposed to a shotgun approach to GSoC applications). You can also state that you'll submit your first PRs (we encourage at least two) after the application deadline on [April 2](https://developers.google.com/open-source/gsoc/timeline#april_2_-_1800_utc), but before we make our final selections a couple days prior to [April 24](https://developers.google.com/open-source/gsoc/timeline#april_24_-_1800_utc). + + ## Project idea list -The following will be expanded upon in detail later today, 2024-01-06. +### Port LibRaw to Rust -- Port LibRaw to Rust +*For Graphite to support editing photos from professional digital cameras, it needs a raw decoding/processing library.* -- PDF export +- **Needed Skills:** Rust, C++, binary format parsing +- **Project Size:** Large *(GSoC: 350 hours)* +- **Difficulty:** Hard +- **Possible Mentors:** [Keavon](/about#keavon), [Dennis](/about#dennis), [Hypercube](/about#hypercube) +- **Expected Outcomes:** Develop a Rust library that ports LibRaw functionality to native Rust. A clean, well-structured code base and API. At a minimum, demonstrate the successful end-to-end decoding, debayering, and color space handling of Sony ARW format photos in Graphite. Publish the library to crates.io. -- ONNX model embedding to run in WebGPU and native (Tauri) and server +For Graphite to work as a photo editing app, it needs to import raw photos. These contain compressed sensor imagery and metadata in a variety of formats. Sony ARW is the first target, and additional camera brands are stretch goals, while porting all useful functionality would be the best outcome. -- Node auto layout +Graphite needs a library written in pure Rust with a suitable (non-GPL) license, which does not currently exist in the ecosystem, so we need to create one ourselves. LibRaw is a common C++ library that supports most camera brands and formats and has a compatible license. Since raw formats are rarely documented by camera manufacturers, porting LibRaw to Rust is the most practical approach. -- Select mode +This project involves diving into the LibRaw source code (~44,000 lines), understanding its architecture, and translating its pieces to idiomatic Rust. Because of Rust's differences from C++, this is not likely to be as simple as a 1:1 source code translation. The student should have strong familiarity with the two languages, experience exploring moderately large code bases, working with binary format parsing, and ideally some knowledge of color science. -- GPU-based node graph UI +### Node graph auto layout -- Complex widget layout system +*Graphite's graph UI needs a system to automatically arrange layers and nodes given incremental changes to the graph contents.* -- Spreadsheet viewer/editor +- **Needed Skills:** Rust, algorithm design ([constraint solving](https://en.wikipedia.org/wiki/Constraint_satisfaction_problem), [packing](https://en.wikipedia.org/wiki/Packing_problems), [graph drawing](https://en.wikipedia.org/wiki/Graph_drawing)) +- **Project Size:** Medium *(GSoC: 175 hours)* or Large *(GSoC: 350 hours)* +- **Difficulty:** Medium +- **Possible Mentors:** [Keavon](/about#keavon) +- **Expected Outcomes:** A system that manages the placement of nodes based on a set of layout constraint rules and incremental updates to the graph topology. It should run efficiently, even with large graphs. It should be robust enough to handle a variety of graph topologies and user interactions, producing organized, useful, and stable layouts. -- Testing and performance instrumentation infrastructure +The Graphite concept is built around a node graph representation of layer stacks, while tools automatically generate and manipulate nodes. When a layer or node is inserted, deleted, moved, or referenced, the graph needs to be reorganized to maintain a clear and useful layout. Users can also interactively expand and collapse groups of nodes which occupies or frees up graph real estate. -- Animation system +Unlike other node editors that are centered around manual graph editing, where users are fully in charge of node placements within one large node network, Graphite's node UI is more oriented towards automatic layout management and viewing just parts of the graph at one time. This means the shown graph toplogy is constantly changing and the layout system needs to cooperatively organize the graph in concert with user actions. -- Infrastructure for generating subsystem visualizations for docs, debugging, and identifying redundant message traffic +While general graph layout algorithms are complex and struggle to produce good results in other node editors, Graphite's graph topology is more constrained and predictable, which makes it possible to design a layout system that can produce good results. Nodes tend to be organized into rows, and layers into columns (see the image in the project below). This turns the problem into more of a constraint-based, axis-aligned packing problem. +### Shader-driven graph UI rewrite + +*Graphite's node graph UI needs to be rewritten using a shader-based rendering system.* + +- **Needed Skills:** Rust, WGPU, computer graphics, shader programming +- **Project Size:** Large *(GSoC: 350 hours)* +- **Difficulty:** Hard +- **Possible Mentors:** [Keavon](/about#keavon), [Dennis](/about#dennis) +- **Expected Outcomes:** A reimplemented graph UI that draws nodes, layers, connections, thumbnails, text, etc. with a custom shader UI rendering system written with WGPU. + +The current graph UI is implemented using HTML/CSS and SVG, which is too slow for large graphs and lacks the flexibility to create the desired visual effects like frosted glass. The new system should be able to handle thousands of nodes with ease, and it should be able to render all the visual effects that are envisioned in the design mockup: + +Node graph UI mockup + +The proposed system is a custom immediate mode renderer built with shader programming. At a minimum, it should replicate present graph interaction functionality, but stretch goals would go beyond that to include various graph quality-of-life features. + +### Marquee selection masking + +*Graphite's raster editing features requires the implementation of Select mode, where users can draw a mask which becomes a marquee (marching ants) selection.* + +- **Needed Skills:** Rust, computer graphics +- **Project Size:** Medium *(GSoC: 175 hours)* +- **Difficulty:** Medium +- **Possible Mentors:** [Keavon](/about#keavon), [Hypercube](/about#hypercube) +- **Expected Outcomes:** Complete implementation of Mask mode and its marquee selection. Marching ants visualization shader effect. Integration of selection mask with the node graph and raster editing tools. Useful raster editing workflow. + +A central part of the workflow in raster image editors is the selection of portions of the image to constrain manipulations just to the masked areas. Tools such as the circular and rectangular marquee, lasso, and magic wand are used to create masks. Instead of using dedicated tools, Graphite's design reuses the existing vector and raster drawing tools (like Rectangle, Ellipse, Pen, and Fill) to create masks in a dedicated Mask mode. Returning from Mask mode reveals the marching ants selection that constrains further editing operations. + +This is a key feature in Graphite's evolution to a fully-featured raster editor. + +### Complex widget layout system + +*Graphite's UI needs an upgraded layout system to support more complex and dynamic widget arrangements defined from the backend.* + +- **Needed Skills:** Rust, web (Svelte, CSS, TypeScript) +- **Project Size:** Small *(GSoC: 90 hours)* or Medium *(GSoC: 175 hours)* +- **Difficulty:** Medium +- **Possible Mentors:** [Keavon](/about#keavon) +- **Expected Outcomes:** An improved system for defining widget layouts with better control and flexibility over arrangement and dynamic data binding. Reduction in boilerplate and plumbing required to define each new layout. Better control of styling between rows. + +The current system for defining the arrangement of widget layouts from the backend, created during a [previous student project](#2022-backend-layout-system), has served us well thus far but has limitations. This project aims to extend the system to better model our evolved requirements. + +The present system is very row-centric, which makes it challenging to create multi-row layouts that distribute their widgets across the space in concert with other rows. It also requires manual updates to the backend data model for each widget, which makes dynamic layouts require extra plumbing and room for mistakes. Defining popover and dialog menus is also cumbersome because each requires several new files in the backend architecture. + +Students should have a good level of familiarity with Rust design patterns to envision, prototype, propose, and robustly implement a new system that can handle the complexity of Graphite's use cases. The size of this project can vary depending on the proposal's scope and extent of refactoring to these and adjacent systems. + +### Node data table editor + +*The node graph data model for procedural content generation can be thought of as a spreadsheet, which needs a dedicated viewer/editor panel.* + +- **Needed Skills:** Rust, web (Svelte, TypeScript) +- **Project Size:** Small *(GSoC: 90 hours)* +- **Difficulty:** Easy-to-medium +- **Possible Mentors:** [Keavon](/about#keavon) +- **Expected Outcomes:** A functional panel in the editor that displays the selected node output data as a spreadsheet across multiple domains. Connection to the graph engine to read and edit the data. Virtual scrolling and efficient transfer of data to the frontend. + +The node graph is a powerful tool for procedural content generation, but it can be difficult to understand the data that flows through it. Node data can be represented as a spreadsheet, where each row presents a domain-specific instance (e.g., a point, segment, or face) and each column displays an attribute (like position, color, or radius). + +This project involves implementing the frontend as a cleanly-written Svelte component that can display the data in a tabular format, where virtual scrolling lets it efficiently process only the visible portion of the full data table. Help will be provided in building the frontend component and especially its CSS styling, but the student should be familiar with efficient TypeScript and Rust programming to handle both frontend and backend challenges while maintaining a focus on performance. The backend portion will need to integrate with the node engine and surrounding tooling to query the data coming from the selected node. + +A larger-scoped version of the project can expand this to focus also on displaying thumbnail previews of data coming from each node's output. + +### Animation system + +*Adding a timeline-based animation system to Graphite would begin realizing the vision as a versatile content creation suite supporting motion graphics.* + +- **Needed Skills:** Rust, frontend (Svelte, CSS, SVG, TypeScript) +- **Project Size:** Medium *(GSoC: 175 hours)* or Large *(GSoC: 350 hours)* +- **Difficulty:** Easy-to-medium +- **Possible Mentors:** [Keavon](/about#keavon) +- **Expected Outcomes:** A timeline panel in the editor that can create and edit keyframes and timing curves for animating data channels used by nodes. Ergonomic experience for keyframing properties. Efficient curve interpolation. Rendering optimizations for relatively smooth animation playback. + +A powerful outcome of Graphite's node-driven architecture is the relatively simple ability to vary data parameters over time. + +In the frontend, the student will be responsible for hooking up useful animation features into the existing editor UI (like exposing node parameters to the timeline) and building the new timeline panel with both simplified keyframe indicators and editable curves. A scrubbable playhead, playback controls, and other common timeline features should be included. + +In the backend, the animation curves need to be evaluated at the playhead position for each animation channel, then fed into the compiled graph. The node graph system (Graphene) needs to be updated so it can accept these time-varying parameters and route them to the appropriate nodes without requiring a full recompilation of the graph each frame. Any other rendering bottlenecks should also be found and optimized, where feasible and reasonably within scope. + +### Testing and performance instrumentation infrastructure + +*Graphite has many areas that could benefit from better automated testing for bugs and performance regressions.* + +- **Needed Skills:** Rust, unit testing +- **Project Size:** Small *(GSoC: 90 hours)* or larger if proposed +- **Difficulty:** Easy +- **Possible Mentors:** [Dennis](/about#dennis), [Hypercube](/about#hypercube) +- **Expected Outcomes:** Specific focus and scope may vary by the student's interests and proposal. In general, a significant increase in the coverage of tests in useful code areas (such as document loading, manipulation, and rendering) and attention towards systems which measure performance metrics and identify bottlenecks and regressions. + +Graphite could benefit from better testing coverage in a number of areas, especially end-to-end testing in the tool, document, and node graph systems. This project is about identifying and addressing areas that are lacking and most vulnerable to suffering from regressions. The student will be responsible for identifying areas that could benefit from better testing. + +### Architecture visualization + +*Infrastructure to generate visualizations of Graphite's system architecture would be a valuable addition to the project's documentation and debugging tools.* + +- **Needed Skills:** Rust (especially proc macros) +- **Project Size:** Medium *(GSoC: 175 hours)* or Large *(GSoC: 350 hours)* +- **Difficulty:** Medium +- **Possible Mentors:** [Keavon](/about#keavon), [Dennis](/about#dennis) +- **Expected Outcomes:** A system built from proc macros which can generate useful visualizations of Graphite's system architecture. Depending on proposal scope, this can include static visualizations added to the documentation, dynamic message flow visualizations for debugging, and tools to help identify redundant message traffic. + +Graphite's editor architecture, based around a message-passing processing queue, is structured as a hierarchical system of message handlers. Each handler stores its own state, and references to the state data may be passed along to its child handlers they need it. + +It is challenging to document the hierarchy of this system as a tree in the documentation because the code is often changing. Generating a visualization would ensure it remains up to date. Additional visualizations could also be generated with greater detail, such as message flow diagrams for each message. + +If proposed as part of the project's scope, a runtime component could be added as an extension of the aforementioned documentation visualizations. These would help developers understand and trace the flow of message traffic, essentially becoming a visual debugger for the message system. Instrumentation included with this could help identify message traffic that causes particularly high load, or locate redundant message traffic, to keep Graphite's performance under control. Timing could also be measured for each message and visualized in a custom flame graph. Current debugger tools can't provide this information because the message-passing approach "flattens out" the traditional function call stack. + +### Your own idea + +*If you have an idea for a project that you think would be a good fit, we'd love to hear it!* + +- **Needed Skills:** Varies +- **Project Size:** Varies +- **Difficulty:** Varies +- **Possible Mentors:** Varies +- **Expected Outcomes:** Stated in your proposal. + +If none of the projects above suit your interests or experience, we are very open to discussing your own project ideas that could benefit Graphite. You may consult our [task board](https://github.com/orgs/GraphiteEditor/projects/1/views/1) and [roadmap](/features#roadmap) to get a feel for what our current priorities are. + +As is the case with all projects, please discuss this with us on Discord to flesh out your idea. Unsolicited proposals that have not been discussed with us will almost certainly be rejected. + + + ## Successful past projects +### 2023: Bezier-rs library + +Affiliation: University of Waterloo, Ontario, Canada +Duration: 9 months +Students: Hannah Li, Rob Nadal, Thomas Cheng, Linda Zheng, Jackie Chen + +The student group designed an API for representing and manipulating Bezier curves and paths as a standalone Rust library which was [published to crates.io](https://crates.io/crates/bezier-rs). It now serves as the underlying vector data format used in Graphite, and acts as a testbed for new computational geometry algorithms. The team also built an [interactive web demo catalog](/libraries/bezier-rs/) to showcase many of the algorithms, which are also handily embedded in the library's [documentation](https://docs.rs/bezier-rs/latest/bezier_rs/). + ### 2022: Backend layout system -Institution: California Polytechnic State University, San Luis Obispo, USA - -Duration: 3 months - +Affiliation: California Polytechnic State University, San Luis Obispo, USA +Duration: 3 months Student: Max Fisher +The student designed and implemented a new system across the editor's frontend and backend which made it possible to define and manage layouts for widgets from the backend and receive input data from those widgets. Previously, all layouts were statically defined in the frontend and extensive plumbing was required to pass data back and forth. + ### 2022: Path boolean operations -Institution: California Polytechnic State University, San Luis Obispo, USA - -Duration: 3 months - +Affiliation: California Polytechnic State University, San Luis Obispo, USA +Duration: 3 months Student: Caleb Dennis -### 2023: Bezier-rs library - -Institution: University of Waterloo, Ontario, Canada - -Duration: 9 months - -Students: Hannah Li, Rob Nadal, Thomas Cheng, Linda Zheng, Jackie Chen +The student devised and prototyped algorithms for performing boolean operations on paths, such as union, intersection, and difference. These were used as a stopgap during 2022 and 2023 to provide users with a rudimentary boolean operation feature set.