In this blog post, we'll explore the evolution of the Octopus design format and detail the changes that have occurred.

I asked my colleagues to contribute ideas for this blog post, and I received so much great content that I decided to split it into multiple blog posts. I'll be gradually publishing these over time. To start, let's provide a brief overview.

## What is Open Design 2.0?

Open Design 2.0 is a headless design editor, meaning it is a TypeScript framework that provides a foundation for developers to build upon when working with designs. The framework helps developers tackle complex issues such as design rendering, design format, and importing existing design formats.

[Back in September 2022](/blog/open-design-2-0), we discussed the ongoing work on refactoring almost all parts of the framework. This process brings both benefits and increased complexity and instability. In this article, we will explain the changes being made to each part of the framework and their current status.

## The current state of Open Design

It is important to note that Open Design is still under development and is not ready for production use at this time. Despite this, we have made significant progress and the initial benchmark tests have been promising. Let's take a look at the changes that have been made.

## The design format, also known as Octopus

Octopus is the universal design format used in our products, such as Avocode, Inspect, Design Converters and Ceros Studio. It has evolved over the years and has undergone a major change with the introduction of a new, more flexible, and generalized design data model.

This is the third version of Octopus and it currently supports integration with the following design tools: Figma, Adobe XD, Adobe Illustrator, and Adobe Photoshop. Where is Sketch, you may ask? The Sketch format is [quite complicated](/blog/reverse-engineering-sketch-s-smart-layouts-algorithm) and we need more time to get it right.

Our main focus for the third version was on improving the robustness, universality, and clarity of the data model. The key changes are as follows:

1. Layer content is now positioned entirely in a relative coordinate system, allowing for the reuse of design elements without the need to update layer content.
2. Layer transformations are relative to the parent layer and are clearly described using a transformation matrix. This removes any confusion regarding the application of transformations such as rotation and flipping (which are still present as metadata).
3. There is a restricted set of layer types, which includes shape, text, group, component reference, and mask group. Images are represented as patterns on shapes.
4. The representation of shapes has been redesigned in the following ways:
   - Shapes can be composed of an arbitrary combination of individual paths combined using boolean path operations (union, intersect, exclude, subtract).
   - The core path geometry is encoded in SVG path format.
   - Shapes may optionally include stroke geometry, where the border is expressed as a shape in itself, addressing Figma's shape representation.
   - Shape fills and strokes are stored directly within the shape object, rather than being stored among generic layer effects, making the data more closely linked and clearer.
5. The representation of layer effects has been updated as follows:
  - Layer-wide effects (such as blurs, shadows, and raster fills) are separated from entity-specific effects (such as vector strokes on shapes and fills on specific ranges of text).
   - Effect positioning parameters are consistent, eliminating any ambiguity in the description of, for example, pattern or gradient fills, which had multiple ways of being expressed in Octopus 2
6.  The handling of masks has been updated as follows:
  - All masks are represented in a "mask group" layer, with the masking layers explicitly stored in the "mask" object and the masked layers stored in the "layers" array as in group layers. This makes the format more user-friendly as there is no need to parse the layer tree to understand which layers are being masked.
   - There is no explicit handling of specific mask types like Photoshop bitmap or vector masks, as they are converted to the new representation.
7. The representation of text has undergone only minor updates, specifically, the meaning of text transformation is now explicitly stated. In addition, the naming of Octopus entities has been standardized, with a unified format for keys and enum value labels throughout the entire specification.
8. The concept of "meta" data has been introduced, which refers to all platform-specific and/or auxiliary data that is not necessary for a complete design representation. This data is stored in a dedicated "meta" object. For example, the original values of layer transformations (like rotation angle) are not essential as the transformation is already represented by a single matrix, but they may be useful and are therefore stored as metadata. This also allows for the storage of specific data from the original design tools.

You can look at an example of how Octopus 3 compares to Octopus 3 [here](https://avocode.notion.site/Public-example-of-Octopus-3-772a16e69ec14c39aed3a6c242796598).
 

### Data normalization

During the processing of design data, we also attempt to normalize it. For example, Figma's vector representation can be unnecessarily complex and contain unnecessary points. When converting it to Octopus 3, we optimize the output by removing these points:

![Screenshot 2023-01-06 at 12.14.12.png](https://cdn.marketing.avocode.com/pupushify-production/Screenshot_2023_01_06_at_12_14_12_40036ea9e4.png)

In the example above, the original shape takes up approximately 122 kB, while the normalized version only takes 16 kB (a savings of ~87%). This makes Octopus files more compact and easier to work with.

### Design-wide format

In Octopus 2, we primarily focused on representing artboards, and saving design-wide meta-information was not a priority. Octopus 3 is now a design-wide format that includes all essential details and meta-information about the entire design. It connects components, images, pages, and artboards.

### Flexibility of Octopus parsers

Another significant change is the design of the Octopus parsers, which are now more abstracted from specific inputs and can be extended by developers. This means, for example, that the parsers can consume data from both the Figma Plugin API and the Figma REST API. The exporting of artifacts, which are used to create the final Octopus file, is also abstracted and left to the developer to handle. The resulting data can be handled in any desired way, such as being saved as files or uploaded to the cloud.

### Web first

Many of the products that use Octopus are web services, so we also made sure to address this in the design. Non-compatible dependencies were rewritten to be compatible with browsers. For example, Octopus 2 used the `psd-tools` library to parse Adobe Photoshop files, but it was written in Python and not compatible with browsers. In Octopus 3, we use TypeScript and Rust, which are modern, robust, and browser-compatible technologies.

### Future goals

Although the current design processing using Octopus 3 is almost twice as fast as with Octopus 2, there are still missing features that we hope to add in the near future. Our focus will be on proper support for design components, fixing existing bugs, and making it ready for production use.


That's all for this blogpost. In the next article we will discuss the Open Design engine, which we have also completely refactored and changed the architecture.



Learn about the evolution of the Octopus design format in this detailed blog post. Discover the changes being made to Open Design 2.0, a headless design editor, and its current status as a TypeScript framework for developers. Find out how it helps tackle complex issues such as design rendering, format, and importing existing designs, but note that it is still under development and not ready for production use.

An Overview of Open Design in 2022: Part 1

large_overview-part-1.png

medium_overview-part-1.png

small_overview-part-1.png

thumbnail_overview-part-1.png

overview-part-1.png

## Intro

We know we have been silent for some time and we would like to correct that now. In this blog post, we want to let you know what we are working on and what it means for the future of Open Design.


Last year was a year of big changes for us. At the beginning of 2021, we launched a preview version of Open Design. Our goal at the time was to see if our vision around working programmatically with designs resonated with anyone else. We set a goal of talking with 30 interested companies to see what kinds of problems they were encountering and if a tool like Open Design could fill some of the gaps. We found that there was demand from all kinds of organizations - from small startups to giant corporations - for the ability to pull data from a design without having a copy of the design software open on a computer.

During our interviews, we heard that security of designs was top of mind for these companies. In particular, the fact that designs were sent to our remote servers to be deconstructed and then converted into the Octopus format meant that they needed to trust us with this sensitive data.

We also understood that for many of the problems that companies mentioned, it would be more practical to have all the necessary parts of our SDK available locally, without our cloud. This was both a technical and business problem for us at the time. Our main product, Avocode, was still our primary source of revenue and it seemed like a big risk to start bundling its core technologies for free to anyone who would use our SDK. We were a small startup that didn't even have a Series A investment, so a stable income was essential for us.

At the end of 2021, a huge change came. Avocode was acquired by its largest Open Design customer, Ceros.

Ceros is also a startup but at a completely different stage and size than Avocode. After seeing how Open Design was able to power Ceros Studio’s import feature, their leadership team started conversations about how our companies would continue to collaborate together. In particular, they saw enormous potential in Open Design’s vision of "Making design accessible to everyone.”, which eventually led to the acquisition.

In pursuit of our vision, we not only want to create software to make design accessible to people. We also want those people to be able to contribute back to that software. Eventually, free of the business concerns that we had before, we’d like to make all of our technology open source. So even if we happen to disappear in the future, or some company that created a design tool disappears, your designs should be able to open and work with in Open Design.

## Open Design 2.0

After we became a part of Ceros, we were given free rein to continue to build Open Design in any way that we desired. Our team got to work brainstorming and eventually came up with five areas of focus:

1. We want all parts of Open Design to be open source and available locally - both in the browser and on a private server.

2. We want to fundamentally improve the Octopus file format, which has acquired inconsistencies over many years of development. We also want to extend it to include additional data that had not previously been possible to include.

3. We want our design importers, the libraries that parse the designs, to be written in a language that is possible to run in the browser. This effort involves rewriting a number of our importers from Python into a language like Rust or Go.

4. We want to expand the capabilities of our rendering engine beyond just displaying designs. it should be able to create and edit them as well - and do it on the server and in the browser. In particular, this effort is so large that we’ve renamed the rendering engine to Open Design Engine (ODE) to better reflect its new responsibilities. And of course, ODE will run both in the browser and on the server.

5. From the very beginning, we’ve understood that nothing we build matters if developers can’t figure out how to use it. All of these new components should be bundled into one cohesive package that makes it super simple for a developer to import a package into their project and start manipulating designs. <br /><br /> We would like the API to be high level enough, yet flexible enough, that Open Design can be used as the basis for applications that work with canvas. We resonate quite a bit with the idea of TLDraw author Steve Ruiz, who [describes](https://twitter.com/steveruizok/status/1493907247314968576) that if software that solves a complex problem is not open source and other companies can't build on it, it limits further innovation in the field.

With these improvements, we’re positioning Open Design as a headless design editor - the best base for projects that want to work with designs.

And this is the current state of the new development:

**Completed:**

✅ Octopus 3 file format specification

✅ Adobe XD importer supports Octopus 3

✅ Figma importer supports Octopus 3

**WIP:**

🚧 Adobe Photoshop importer

🚧 Adobe Illustrator importer

🚧 Sketch importer

🚧 Open Design Engine

🚧 Open Design framework (The library that connects everything)

Our team is building Open Design 2.0 in tandem with another internal team using it to build a new motion design application (we’re eating our own dog food). This approach allows us to catch bugs and inaccuracies and improve the overall API quickly.

## What are the next steps?

We would like to communicate better with the community, so we want to start ~~writing monthly updates~~ (the monthly updates were an overly optimistic vision. We will write quarterly updates) on progress. From experience we do not want to promise a specific deadline for when everything will be available and in what state of stability. In the coming months, we will gradually start adding GitHub repositories and slowly start updating the Open Design 2.0 website and documentation.
If you want to follow updates, start following us on Twitter [@OpenDesignDev](https://twitter.com/OpenDesignDev).

In this blogpost we summarize what happened in Open Design last year and what we are currently working on.

Open Design 2.0

large_open-design-2.0.png

medium_open-design-2.0.png

small_open-design-2.0.png

thumbnail_open-design-2.0.png

open-design-2.0.png

Open Design allows you to crack open a design and see everything that's inside - from a rendering of an artboard all the way down to the properties of an individual layer. To get this level of detail without relying on the original design tool, [we have to reimplement all of the functionality from every design tool that we support](/blog/the-story-of-open-design) - that's Figma, Sketch, Adobe XD, Adobe Photoshop, and Adobe Illustrator.

Today, we render designs exactly as intended 99.6% of the time. We [don't claim to support 100% of every design tool](/docs/design-format-support) but we do care a lot about rendering precision and prioritize supporting features and fixing bugs that meaningfully affect this metric.

There's one design tool feature in particular that has been a thorn in our side and has cost us more engineering time than any other - **Sketch Smart Layouts**.

When re-implementing a feature from a design tool, the first step is to understand what it does. Typically, this is the easy part. Even with an advanced graphical effect, an experienced graphics engineer can generally get a rough idea right away. But Smart Layouts are different - their functionality is intertwined with the hierarchical structure of the entire design file. They were too complex to simply guess how they worked, so we had to come up with a new approach to reverse-engineer them.

## What are Smart Layouts?

So, what are Smart Layouts anyway? When you design a web page or a mobile app, certain elements appear more than once and should have a consistent appearance. To retain the ability to globally modify all occurrences of these elements, Sketch introduced the concept of symbols. A repeating element can be defined as a “symbol,” and in place of mere copies, symbol instances are made, which are inherently linked to the common “symbol source,” formerly known as symbol master.

Even though the designer wants symbol instances to look alike, sometimes that doesn’t mean identical. For example, a UI button can be turned into a symbol. And while all buttons should have the same design, each one has a different label. That’s where symbol overrides come in. While all instances start out as exact copies, optionally, parts of them can be individually modified with the so-called “overrides.”

And finally, we arrive at the problem that Smart Layouts attempt to solve. When you construct a symbol that is more complex than just a simple button with a label, it often has its components laid out in a non-trivial way. But when you start changing parts of it with overrides, they may no longer fit this carefully crafted layout. What’s worse though, is that since we are still dealing with a symbol instance, the layout can’t really be fixed up without modifying the symbol source and messing up all other instances.

So Sketch came up with Smart Layouts, a system that attempts to deduce how the layout should change automatically, merely from one single hint - the layout direction. In the following example, crisis is averted with the use of several Smart Layouts:

![https://cdn.marketing.avocode.com/pupushify-staging/dumb_vs_smart_layout_opt_a579edbbde.gif](https://cdn.marketing.avocode.com/pupushify-staging/dumb_vs_smart_layout_opt_a579edbbde.gif)

## The problem with Smart Layouts

Generally, components in a page are either positioned by hand (as in most graphics editors, including Sketch) or by a rigid layout system (e.g. HTML + CSS). With Smart Layouts, Sketch curiously tries to do both at the same time. This attempt to reconcile the two opposing paradigms gives designers a lot of freedom, but this in turn makes the layout logic very complicated and unpredictable.

This is the source of many issues that we faced during the reverse-engineering process. We found many inconsistencies in the implementation, some of which the Sketch team acknowledged and some they claimed were "features". In the latter case, we had to support those bugs in our implementation (since we wanted to be as close to 100% precision as possible).

In contrast, Figma introduced “Auto Layouts,” a feature that solves the exact same problem as Smart Layouts. Despite this, and in sharp contrast to Smart Layouts, I was able to understand how they work almost immediately. They constrain the designer to a more rigid layout system (they can't place contents arbitrarily), but this limitation is what ultimately makes the implementation predictable and robust.

## So how *do* they work?

A key point is that Smart Layouts only take effect when overrides are present. Otherwise, they do not make any difference whatsoever. What happens in the basic case is that an element whose size has changed due to an override essentially warps the entire spatial axis (horizontal or vertical, depending on the direction of the Smart Layout) from the point where it ends onwards in such a way that elements following it stay the same distance from it. However, elements that intersect the “spatial warp boundary” do not fare so well. For example, their left side may be unaffected, while their right side may be swept away by the warping effect. In these cases, the transformation is only applied on the four corners of the layer’s bounding box, simply stretching the layer to a different size. But nothing is stopping the right side of the layer’s bounding box from being “warped” all the way to the left of what used to be its left boundary. These elementary mechanics, including the case mentioned at the end, are captured in the following animation:

![https://cdn.marketing.avocode.com/pupushify-staging/smart_layout_anim_opt_25f4278b7c.gif](https://cdn.marketing.avocode.com/pupushify-staging/smart_layout_anim_opt_25f4278b7c.gif)

Now you might be thinking that, while perhaps not immediately obvious, surely these rules weren’t that hard to figure out. And indeed, up until this point, they weren't. I believed that figuring out how to apply these rules to the general case would be just a formality before wrapping up the same day, but that couldn’t be further from the truth. It turned out that understanding this simple case had no bearing on solving almost any other, even one only slightly more complex.

For example, do you know what would happen if multiple overridden elements overlapped? Or what if there were nested smart symbols affected by the “warping”? How would this affect a parent instance, where the smart symbol is embedded? Did you know that ordinary layer groups can also have Smart Layout enabled but behave slightly differently? And how do you suppose this all works if some of the layers also have resizing constraints - a completely separate layout mechanism? Almost none of these examples behaved the way I expected and a complete documentation of my findings would be much longer than this article.

## The Research

After initially making some good progress on reverse engineering, I hit a wall. Eventually, I was trying lots of different things without any clear direction and it became clear that I was not getting any closer to figuring out the complete algorithm governing Smart Layouts. A more systematic approach was necessary to crack this, so I turned to the scientific method.

For us, Sketch’s algorithm is a black box. We cannot look inside it to analyze how it works, but we can conduct experiments by sending inputs in and seeing what comes out. This way, we can form hypotheses in the form of our version of the algorithm or its parts and test if they hold up. I am not saying it’s on the same level as when physicists in CERN test which quantum model of the universe is correct by sending particles into the large hadron collider and seeing what comes out, but can you really claim the difference is more than semantic?

But before I could start my experiments, I had to develop a testing framework that prepared the inputs, supplied them to Sketch, and compared their output with my own. Sketchtool, the official command-line utility shipped with Sketch was instrumental in this endeavor, as without it I wouldn’t have been able to automate this process and test millions of design files.

## Step by step

That’s right. Several million design files with Smart Layouts have been tested during this endeavor, and although I haven’t managed to claim a 100% success rate, over 99% are a perfect match.

So where did we get that many design files? Don’t worry, we didn’t use those uploaded by Avocode users. I simply made a random design generator. Now, I still haven’t explained how this new approach is any more systematic. The key was that this custom design generator allowed me to fine-tune what kinds of designs were tested. I started with the simplest ones and once I achieved a (near) 100% match rate for a given complexity level, I would turn up the generator to come up with something harder. Rinse and repeat.

Before long, I was generating so many designs that even Sketchtool couldn’t keep up. I found that no matter how simple the design was, the Sketchtool utility would always take at least half a second to (presumably) initialize itself. I went so far as to implement a system to wrap several Sketch files into one, and then separate them again on the return journey. With this optimization, my testing throughput increased to 108 designs per second on a regular MacBook. And with a simple Python TCP server in under 20 lines, I didn’t even have to use the MacBook directly. (Note: Sketch and Sketchtool only run on macOS.)

Having a lot of examples for each scenario not only made it less likely that errors went under the radar, but I also had a larger pool of cases that failed the test, which I could closely analyze. In fact, I added in some extra features to streamline this process such as automatic lookup of the simplest case that failed, and even reducing some of the generated designs to just one dimension instead of two.

## The End?

I wish I could conclude this by saying that the mystery of Smart Layouts has been solved once and for all, but to tell you the truth, there actually hasn’t been a eureka moment where everything suddenly fell into place and I knew that what I have is the one and only true Smart Layouts algorithm. Instead, it was a thorny road of incremental improvements, and although the success rate is now at over 99%, there are still known cases that just don’t match the original. What is important though, is that now we have a tried and tested procedure to iron out these remaining flaws in the future.

When you upload a design to Avocode, our first job is to decode the file and replicate what it looks like as if you opened it in the original editor. This means that we basically have to reimplement all of the functionality of a given editor from scratch. With multiple supported editors, this is not an easy task by itself, but some editors make this job harder for us than others. There is one feature in particular that has probably cost us more man-hours than any other - the so called Smart Layouts in Sketch.

Reverse engineering Sketch’s Smart Layouts algorithm

large_smart-layout-2.png

medium_smart-layout-2.png

small_smart-layout-2.png

thumbnail_smart-layout-2.png

smart-layout-2.png

Open Design is a developer toolkit that allows you to read and display data from designs using code. Though Open Design was first released in early 2021, the technology behind it has been powering Avocode's design handoff tool for six years. This is the story of how it all came to be.

## Avocode's humble beginnings

Back in 2014, there was a lot of pain involved with designers handing off UI designs to developers. Many designers were still using Photoshop and developers didn't have a great way to get what they needed from those designs.

Avocode 1.0 was released to address those problems. At launch, it targeted teams using Photoshop and we started hearing that they saw their design → code process get faster and more accurate. It was a success!

But we were just getting started.

## Taking it up a notch

After our launch, we listened closely to feedback from our customers. We also did some UX testing with our designer and developer friends in Prague to learn more about the pain points in the design handoff workflow.

In the middle of 2016, we turned this feedback into an action plan. We focused our entire engineering team on building two interconnected features:

1. Open designs without the design tool installed (just drag and drop the file)
2. Be able to visually display the full design (including panning and zooming in)

This was quite a lot to take on at once, but we were confident that we could deliver and it would've killed us not to at least give it a try.

## Building Octopus

The first task was building parsers that could extract data from Photoshop and Sketch files without relying on the design tool itself. These parsers would need to deconstruct the file and convert the contents to JSON.

So the team got to work cracking open Photoshop's notoriously opaque binary format and Sketch's SQLite database with binary plist blobs (this was before [Sketch 43's new format was released](https://www.sketch.com/updates/#version-43)). After a lot of hard work and lots of trial and error, we had the designs converted into a readable JSON document that we called a "Source JSON".

But we weren't finished yet. If we had stopped here, the team working on the Avocode app would have to implement all of the app's functions (measuring distances, extracting text, etc.) twice - once for Photoshop and once for Sketch. On top of that, if a design tool update was pushed out that modified the format, the app team would have to support both the old and new version of the format (since we can't expect that every file will be saved in the newest version).

This sounded like a major headache, so we decided to go a step further. What we needed was a stable API between the parsing team and the app team.  So we took the best ideas from the Photoshop and Sketch formats and created a spec for a new JSON-based design format.  

This spec turned into Octopus 1.0.

<Image src="https://cdn.marketing.avocode.com/pupushify-production/octopus_printer_f67b128d84.png" caption="The Octopus printing machine we created for a marketing campaign." small external />

Then the team built converters that mapped values from the Source JSON into the new Octopus format. Some values could be mapped directly and some needed to be converted (for example, coordinate systems were normalized).

The obvious advantage of this approach was that the app team could focus on building a great product without worrying about whether a design tool update would break a feature. They were building on something stable and reliable. Meanwhile, the parsing team could focus on testing new design tool updates and making sure that they still translated into Octopus.

## Building Render

With Octopus, we checked off the first task. The next one to tackle was being able to actually display the design to the user. Previously, we used our Photoshop plugin to export a bitmap of every layer and placed them in a grid and at the specified position. Since we could no longer rely on the original design tool, we needed a new approach for generating these bitmaps.

So we decided to stop thinking like a handoff tool and to start thinking like a design tool. Photoshop and Sketch both had their own rendering engines, and it made sense for us to build one as well. So the team set out to build Render, a rendering engine that could faithfully reproduce the design using nothing but the data in the Octopus format.

We built the first version of Render in about 6 months. It wasn't perfect, but it handled the basics well and surprisingly rendered real-world designs decently well. It proved that we were on the right track, but the most glaring problem we saw was its performance. The team used JavaScript since they were already experienced with it but after some benchmarks, it was clear that we were hitting some language-specific limits.

Rewriting a project in a new language usually isn't the smartest thing to do, but we decided to risk it. We hired a few brilliant C++ developers and they got to work implementing the logic. C++ is faster than JavaScript for most operations, but the real speed boost was gained by using OpenGL for hardware acceleration. 

We knew beforehand that designers were (and still are!) very intentional with where they put pixels. If this project was going to be successful, we would have to make sure that Render's output was really *really* close to the original design tool. To measure precision, we built an internal tool that generated a bitmap of each artboard using both Render and the original design tool. It then compared the differences between the two and highlighted problem areas for our developers to look into. Especially later in the process, text rendering turned out to be a challenging thing to get pixel-perfect.

After about a year of really hard work, we attained an average of 99% rendering precision. In addition, the whole thing was lightning fast. 

## Avocode 3.0

In the summer of 2018, we launched Avocode 3.0 and billed it as the "world’s first truly cross-platform design handoff tool". For the first time, users could drag and drop a Photoshop or Sketch file directly into Avocode (no software or plugins necessary) and in just a minute or two, they could see and inspect the design. This is what we had been working towards for the last 2 years!

Oh, by the way, we delivered support for Adobe XD and Figma in this update as well. Once we had the foundation of Octopus + Render to work with, adding support for new formats was far simpler than it used to be.

<Embed src="https://www.youtube.com/embed/PUTxS9Gyn-Q" caption="Launch campaign for Avocode 3.0" />

## Building View

We rode on the coattails of the Avocode 3.0 launch for a few weeks, fixing bugs and watching how all of the new features were being used. One metric we paid special attention to was the amount of time it took between uploading a design and actually being able to see it. It was pretty fast for small Photoshop designs, but it could take a few minutes for a multi-artboard Sketch design.

In that processing workflow, we performed four steps:

1. Avocode app uploads design to Avocode servers
2. Parsers convert design to Source JSON and then convert it to Octopus
3. Render generates bitmaps of every layer and saves them to the CDN
4. Avocode app downloads every bitmap and places them on a grid

As we were thinking about optimizing steps 3 and 4, we had an idea. Instead of rendering every layer server-side and then having the app download all of the bitmaps, could we do the rendering directly in the browser?

We started exploring a cutting-edge technology called Emscripten that directly converted native C++ programs into code that could be run on the web. With this, we could just download the Octopus file in the app and progressively render tiles of the design, resulting in much faster load times. And, as the user zoomed in, the design could remain sharp instead of getting pixelated. These improvements would elevate the user experience, so we gave it a shot.

After learning the ropes of Emscripten, [learning tons about the limitations of web technologies](https://avocode.com/blog/how-we-made-avocode-faster-with-concurrent-design-rendering),  and [making some optimizations to Render](https://avocode.com/blog/sketch-xd-figma-graphics-engine-in-the-browser), the first version of View was looking really good. In the spring of 2019, we launched Avocode 3.7 with these changes included. Designs were opening up to 3x faster and customers were loving that their designs remained sharp even when they zoomed in to 1000%. It was a success!

<Image src="https://opendesign.dev/static/images/docs/view-pan.gif" caption="How parts of the design are rendered when the user pans around" small external />

## Introducing Open Design

We were really excited to have these core technologies - Octopus, Render, and View - finally integrated into Avocode. We even built free tools using these technologies to drive traffic to our site. The first of these, [Photoshop → Sketch Converter](https://avocode.com/convert-psd-to-sketch), garnered [a ton of praise](https://www.producthunt.com/posts/psd-to-sketch-design-converter) from the community and saw lots of engagement.

From this and [feedback from a pre-launch campaign](https://www.producthunt.com/posts/avocode-sdk), we realized that the core technologies we built could have use cases beyond just Avocode. If we externalized these and turned them into a product, would anyone use it? We were determined to find out.

In the middle of 2020, we started taking this initiative seriously. We started by creating a REST API to import designs and get Octopus back. Our engineers worked on cleaning up the Octopus format, creating TypeScript types, writing documentation, creating a new public-facing API, and more.

In January 2021, [we launched Open Design](https://www.producthunt.com/posts/open-design). Our main goal was to learn more about how potential customers wanted to use this tech in their applications. We hopped on calls with around 40 different companies and kept hearing the same two things:

- Design → Code - though it means something different to everybody, it's clear that people  want to automate the design handoff process
- Design Import - creators of design-based applications want to import Figma, Sketch, XD, Photoshop, and Illustrator designs into their app

<Image src="https://cdn.marketing.avocode.com/pupushify-production/od_diagram_f5287c55fe.png" caption="Open Design turns designs files into something usable." small external />

We also heard that the raw API endpoints were an obstacle to getting started. That's why, a few weeks ago, we [launched Open Design SDK](https://www.producthunt.com/posts/open-design-sdk), which is a Node.js library for interacting with Open Design. We also included Render so that anyone can export high-quality bitmaps and vectors from their designs.

We're still listening closely to learn more about different use cases as well as how to make it easier to adopt Open Design into your toolchain. We're excited to finally put the technology that we've spent years working on into the hands of people that can really use it. We believe that by making design more open and accessible, we can help make design tools smarter and teams work together better.

If you have any questions or want to learn more, we'd love to hear from you! [Contact us](https://opendesign.dev/contact) or [tweet at me](https://twitter.com/rhefner11).

Do these challenges sound interesting to you? If so, we'd love for you to [join the team](https://avocode.com/jobs).

Open Design is a developer toolkit that allows you to read and display data from designs using code. Though Open Design was first released in early 2021, the technology behind it has been powering Avocode's design handoff tool for six years. This is the story of how it all came to be.

The Story of Open Design

large_introducing-opendesign.png

medium_introducing-opendesign.png

small_introducing-opendesign.png

thumbnail_introducing-opendesign.png

introducing-opendesign.png

We've spent years building our flagship product Avocode to enable people to work with design files in the browser. To do that, we developed technology to transform each design format into a JSON-based design format (we call it Octopus 🐙), which enabled us to work only with a single design format (instead of five). We had to ask ourselves, could the Octopus and our design parsing power other apps besides Avocode? Short answer - it can.

In January 2020, we started working on a project with [Ceros](https://www.ceros.com/) to give them access to our Octopus format via an API to enable Ceros’ users to be able to import Sketch, Adobe Photoshop, and Adobe Illustrator design files and instantly turn them into production-ready websites.

After almost a year of close partnership, we’re excited to go public with this story. The Ceros dev team has successfully leveraged the Octopus format to work with design files in their web app and released the design file feature with their [Ceros Studio 7 update](https://www.businesswire.com/news/home/20201029005224/en/Ceros-Introduces-Release-7-a-New-Standard-for-Digital-Design). Ceros is now the third web app after [Avocode](https://avocode.com/) and our [Photoshop to Sketch Converter](https://avocode.com/convert-psd-to-sketch) that is able to work with third-party design file formats via an API.

As more companies and app teams requested access to this technology, we’re excited to announce that both our format Octopus and our API are now open to the public as the [Open Design API](https://opendesign.avocode.com/) - and yes, documentation is a part of it; check it out. 🎉

<Image src="75/1.png" caption="&nbsp;<a href='https://opendesign.avocode.com/' target='_blank'>Documentation of the Open Design API</a> for reading data in design files." />

To help you understand better the potential of the Open Design API and how it can help products out there, we sat down with the Ceros team to understand their new Ceros Studio 7 update and what role our API played in its development.

**Without further ado, let Molly O’Connell, Director of Partnerships at Ceros, introduce you to what is Ceros and why you should keep an eye out for it.**

Ceros is a cloud-based design platform that allows marketers and designers to create immersive content without writing a single line of code. It is a tool that can transform and liberate your digital presence across all touchpoints, and it’s backed up by a team of experts.

Our team has pivoted to be entirely remote-first in 2020. We are around 225 people, but the Avocode team worked with our Product, Engineering, Partnerships, and Design teams.

We're a group of people who are wildly passionate about changing the way content is created on the web. We believe content creation has been constrained by technology for too long, and creativity has taken a backseat. We exist to unlock creativity. Our platform empowers the world's leading brands to share their stories and engage their audiences.

## What value does the integration with Avocode bring to Ceros' users?

**Jack Dixon, Creative Director at Ceros:** Ceros’ partnership with Avocode empowers our customers to import Photoshop, Illustrator, and Sketch files into Ceros, instantaneously converting them to web-ready HTML5, without writing a single line of code. This cutting-edge file conversion technology integrated into Ceros’ cloud-based design studio offers unparalleled creative efficiency. Through this partnership, Ceros is now the world’s only design platform to offer this service.

Even prior to this integration, Ceros customers had a tremendous amount of flexibility in designing and building content within our design studio. But with this integration, we can now offer unparalleled design efficiency, giving our users more time to be creative.

<Image src="75/2.png" caption="The design file import feature inside the <a href='https://www.ceros.com/educate/help_center/ceros-import/' target='_blank'>Ceros Studio.</a>" />


## What business value does Open Design API bring to you?

**Jack Dixon, Creative Director at Ceros:** When I initially discovered Avocode in [an article I read](https://avocode.com/blog/sketch-xd-figma-graphics-engine-in-the-browser), I felt like I’d struck gold. This was something that had been on my mind for almost 6 years of my time at Ceros.

> Avocode’s Open Design API has essentially saved us years of development if we’d built this with our own product team.

Prior to finding Avocode, I wasn’t sure it was even physically possible to achieve this with the constraints of today’s web technologies. When I dug deeper and realized there was an API in development, I knew that this was a perfect fit for Ceros.

Avocode’s Open Design API has essentially saved us years of development if we’d built this with our own product team. We worked closely with Avocode’s technical team, ultimately developing and delivering a seamless experience for Ceros’ customers at break-neck speed.

**Alan Delong, Engineering Team Lead at Ceros,** puts it this way:

> Avocode has been one of our favorite partners to work with from our very first meeting. Their expertise is invaluable, and they have been consistently responsive to all of our requests. Collaborating with their team has often felt like they’re part of our own. They helped us build a killer feature, and it’s saved us both time and money - I wouldn’t hesitate for a second to work with them again in the future.

<Image src="75/3.png" caption="A Sketch design file being uploaded to the Ceros Studio." />

## What was your biggest struggle that you had before you started using Open Design API by Avocode?

**Jack Dixon, Creative Director at Ceros:** Ceros independently conducted several research and discovery projects with the goal of building our own file conversion engine, but ultimately struggled to make any meaningful progress due to the resources required to complete a feature of this scale.

>  With our latest offering, Ceros Release 7, our customers are now at the forefront of unmatched creative freedom, power, and efficiency. A part of that magic is powered by Avocode, and we are so excited to see what our users create with it.

While Ceros has made incredible progress in the way content is created for the web in the last 8 years, we knew that integrating with the existing tools designers and marketers already know and love would broaden our user base, and build more brand loyalty over time.

With our latest offering, Ceros Release 7, our customers are now at the forefront of unmatched creative freedom, power, and efficiency. A part of that magic is powered by Avocode, and we are so excited to see what our users create with it.

## How would you assess the cooperation between Avocode and Ceros engineering teams?

**Alan Delong, Engineering Team Lead at Ceros:** After the terms of the project were agreed upon; we involved our lead designer efficiency engineer, two developers, a product manager, and our Head of Product Design. They all collaborated closely with the Avocode team throughout the course of the implementation. We also set up a shared Slack channel between the Ceros and Avocode teams, and despite the time zone difference, the Avocode team always responded to us in a timely manner. 

## Would you recommend Open Design API to other companies? If yes, what would be the reason?

I don't know of any other offering in the market that can transform all these different design formats into a single universal design schema. If any company is looking to work with files from multiple design programs, the Open Design API is hands down the right choice.

> If any company is looking to work with files from multiple design programs, the Open Design API is hands down the right choice.

## How are you satisfied with Avocode backend infrastructure?

**Alan Delong, Engineering Team Lead at Ceros:** The Avocode team provided us with the results of a penetration test they commissioned and remediated the few vulnerabilities that were found in a timely manner. There were no major vulnerabilities discovered. Overall, we've had no problems with the infrastructure Avocode put in place for us. 

## Can you explain how is Ceros using Octopus - the Avocode open design format - to import Sketch, Adobe Photoshop, and Adobe Illustrator files?

**Alan Delong, Engineering Team Lead at Ceros:** Prior to our partnership with Avocode, designers that wanted to initially prototype their Ceros experiences in a visual design tool such as Photoshop or Sketch would need to manually upload, realign, and tweak all the assets from that design file into a blank Ceros experience.

Now, with Octopus, Ceros is able to automatically convert these designs into a Ceros experience, saving designers quite literally -hours- per experience. Without Avocode's expertise in proprietary design file formats, we would have spent an inordinate amount of time creating a conversion pipeline for every format. The Octopus design format allowed us to short-circuit that and write a straightforward translation from Octopus JSON into Ceros JSON.

## How helpful is the Octopus format to you, and why?

**Alan Delong, Engineering Team Lead at Ceros:** The Avocode team created examples of Octopus from our collection of testing design files at the beginning of our cooperations. These turned out to be invaluable to us when we were implementing our side of the design file conversion pipeline.

> Without Octopus, our Design File Import feature - one of the most game-changing things we've ever released - simply wouldn't exist. It's been immeasurably helpful.

We’re extremely happy to have helped with the design file import feature to Ceros. If you are tacking similar use cases, need to import design files to your product, convert file formats, sync design system tokens or automate some pipelines around design files, we’d be happy to help. 

The easiest way for you to verify if the [Open Design API](https://opendesign.avocode.com/) is good for you, is to simply [generate a token and trying it on your own](https://opendesign.avocode.com/docs/quickstart).

Do you need to enable users to import design files (like Sketch, Photoshop, or Illustrator) into your product? Ceros (a cloud-based design platform from the USA) faced the same challenge with their Ceros Studio no-code tool. We partnered with them to solve it thanks to our newly released Open Design API and our custom JSON-based design format Octopus.

 How Ceros launched Sketch, Photoshop, & Illustrator import thanks to the Open Design API by Avocode

large_1.png

medium_1.png

small_1.png

thumbnail_1.png

1.png

Ceros Design Import - Powered by the Open Design API - Case Study

At Avocode, we render designs from scratch. We have developed a specialized hardware-accelerated rendering engine in C++ that also runs in the browser with the help of Emscripten and WebAssembly.

Emscripten is the cutting edge technology that allows developers to directly convert native C++ programs into code that can be run on the web, with minimal modification. Traditionally, this has been JavaScript, but more recently, the high-performance WebAssembly has been gaining traction and is now supported by most major browsers. WebAssembly is designed specifically with this use case in mind, and even though it still has to be interpreted or retranslated by the browser, its performance is almost comparable with fully native programs. For users with older browsers, we still have a JavaScript version ready.

For us, though, the performance of the code itself is not a big issue since we take advantage of WebGL for all heavy-duty tasks, which allows us to fully utilize the specialized graphics hardware present in all modern computers, which is ideal for this purpose. Even though WebGL is more limited than its native counterparts, OpenGL, DirectX, and others, it is almost equal in performance.

So what challenges did we face as we developed this engine?

## Reverse engineering

We had to study the behavior of the supported graphics editors and try to reproduce their every quirk as faithfully as possible. A large portion of the editors’ functionality had to be basically reimplemented. Rasterization, composition, blending, masking, transformations, filters, effects. We have to be ready for even the most unlikely combinations, because with the volume of designs we process (over 100,000 a month), anything that is possible will probably appear at some point. Should a layer’s shadow be visible through its semi-transparent border? How does a layer’s blending mode interact with its fill’s blending mode and the parent group’s blending mode? The answer is usually, it depends.

What we have found is that each editor has a different “personality” in this manner. For example, Photoshop, while slightly intimidating at first with a large number of in-depth configuration options, actually turned out to be the most consistent and predictable out of all, in an almost scientific way. If something unexpected happens in Photoshop, chances are you simply don’t understand it well enough, but it actually makes perfect sense.

Sketch, on the other hand, proved to be the least robust. It was very easy to come up with situations that the program hadn’t been prepared for, at which point the results were completely unpredictable. For example, adding a certain effect to a layer may inexplicably change the drawing order of other elements in the scene.

At the same time, the graphics editors are constantly being updated, so we have to keep on our toes and implement new features as they come. Most recently, Sketch put us to work with its Smart layout feature, whose exact mode of function is somewhat unclear.

**Avocode Cloud API**

Since we have already done the work of writing parsers and rendering support for the most used proprietary formats, we’d like to open this technology via an **on-demand Cloud AP**I. If you need to request data from design files and would like to use our Cloud API, please contact us for a potential partnership at sam@avocode.com.

## Text rendering

One component of this project, in particular, which seemed innocuous at first, has blown up into one of our most significant endeavors - text rendering.

“What’s so hard about rendering text,” you may ask. Well, the problem is not so much the rendering itself, but laying out the characters. And, more specifically, doing this in the exact same way as the original editors. There are many reasons why this is a challenging task. For example, the fact that there are many languages in the world and many use completely different scripts, some of which work differently in certain ways, and for example, may be written from right to left.


Since we are not aiming only to display simple strings such as “Hello world,” but fully formatted multi-line, multi-paragraph text layers, many variables come into play, such as the typeface, font size, and style, horizontal and vertical alignment, justification, letter spacing, kerning, some of which may differ for each individual character. Again, it is not that hard to process all of that and produce the correct result. But our job is to lay out each individual character at precisely the same position as the source editor would. It is no big surprise that each editor behaves differently. And they do not make this any easier for us. For example, we have no indication of how a paragraph has been broken up into lines, but our users expect the same result. And if we are off by just one pixel, a long word might no longer fit on its line and will be moved to the next one, causing a chain reaction on the remaining lines. Of course, cases like this still occur, and we are still actively working on our text layout algorithm.

<Image width="400" src="52/1.gif" caption="This is how even a one pixel difference may impact text layout." small />

Another big issue is the management of font files. As you might know, if you use a non-standard font and transfer the design file to a different computer where this font isn’t installed, the text will either be drawn with the wrong font, or there might only be a cached image of the text that cannot be edited without selecting another font. **All in all, the problem is that the used typefaces are not embedded in the file.** We do manage a database of common typefaces, but the font file on our server may not always perfectly match the one on the designer’s computer. It could be a newer revision with different metrics, a version with a different character subset, or possibly a wholly different typeface that has the same name. For cases like these to work properly, our users have to upload their font files to Avocode.

## Monroe Machine - asynchronous graphics engine

Throughout the development process, our goals and priorities were constantly shifting. What was originally meant as a server-side service that produced rendered images, was now to be a core component of the Avocode front-end, running in real-time in the user’s browser. Because of this unexpected turn of events, and due to certain limitations imposed on apps running in the browser, our engine was not fully prepared for this paradigm shift.

The single most severe shortcoming was that once rendering had started, there was no way to stop it or pause it. At least not without multi-threading, a feature not available in browsers at the time. This would mean that for the entire duration, the Avocode app would be locked up, and the user unable to interact in any way. To avoid rebuilding the whole project with this consideration in mind, we came up with what is now known as the “Monroe Machine” architecture. The main idea is that while the program’s structure remains the same, all procedures that would cause actual rendering to occur are replaced by writing down a symbolic command for that operation. Without actually drawing anything, this process is almost instantaneous, and therefore doesn’t need to be interrupted. The result is a sequence of instructions in binary form, essentially an intermediate bytecode, which is then fed into an interpreter, one by one, that handles the actual rendering. But most importantly, the interpretation may be halted at any point between two instructions. This allows us to alternate between discrete rendering steps and responding to user input or restarting the process with updated parameters.

Ironically, even though this architecture was mainly created due to the lack of multi-threading, it actually made it easy to add multi-threading support to our rendering engine. The architecture is almost ideal for this, because all we had to do was add a second interpreter that runs along the instruction sequence ahead of the main one, and prepares partial results that can be computed in a secondary thread. These are typically certain CPU intensive calculations, as GPU rendering does not benefit from running in multiple threads - it has its own hardware-level multi-threading. The only consideration is that the preprocessing interpreter must not pass the main one and it shouldn’t get too far ahead, because then, the partial results may take up too much memory before they get consumed. At the same time, running the second interpreter is fully optional, so the application still works perfectly in a single-threaded environment.

[Learn more about concurrent rendering](https://avocode.com/blog/how-we-made-avocode-faster-with-concurrent-design-rendering).

# The Stage - design canvas in the browser

Let’s see what we can do with any Sketch, XD, PSD, AI, and Figma design in the browser.

<Embed src="https://stage-embed.avocode.com/embed/ca455d04f0f643429a6267e7a3fe1543?autoplay=0" />

This is an Adobe XD design linked from Avocode. You can zoom in and pan to see as the design is sharply rendered. The design canvas behind is called The Stage, and we can build pretty much anything on top of it. We can show you layers, show more artboards at once (even across formats), enable rapid prototyping, and more.

**So how does The Stage work?**

Since we have moved from the rendering service paradigm to a dynamic real-time viewer, we’ve been gradually improving our design view, which we call “the stage.” At this point, we are already able to draw a large number of artboards from scratch simultaneously and at any level of magnification. As the user is panning and zooming in the stage, we fill in the missing parts on the fly. For this, we use an approach similar to Google Maps. At each magnification level, we divide the plane into square tiles. We render all of the visible ones, as well as some that are just outside the user’s field of view - to be prepared for when they pan towards them. To save memory, some tiles that become too far out of view are dropped. When available, we make use of a fixed-scale pre-rendered image of the whole design to fill in the unfinished areas. Here is an animation of what that might look like:

<Image src="52/2.gif" caption="How we render parts of the design when the user pans around." small />

Similarly, when zooming in or out, the view is temporarily filled by the scaled previous state of the stage, as well as the pre-render.

<Image src="52/3.gif" caption="How we render designs when the user zooms in and out." small />

Unlike the maps though, we also have to update tiles that have already been rendered, since it is possible to change the design view in certain ways - currently mainly by changing the visibility of specific layers. 

However, in the future, we have big plans for possibilities to edit the designs, so stay tuned!

Explore how we developed a custom graphics engine that renders sharp design files in the browser (Chrome, Safari, Firefox). Need to access and render design data from proprietary design files? Contact us for access to our Cloud API.

How Avocode Graphics Engine renders Sketch, Adobe XD, PSD, AI, and Figma designs in the browser

large_hero_7800da0880.png

medium_hero_7800da0880.png

small_hero_7800da0880.png

thumbnail_hero_7800da0880.png

hero_7800da0880.png

Render Sketch, Adobe XD, PSD, AI, and Figma designs in the browser with Avocode

Designers and developers work with all kinds of tools on all types of platforms, so a proper design hand-off tool needs to work with all primary design tools (Sketch, Adobe XD, Photoshop, Illustrator and Figma) and on all platforms (macOS, Windows, Linux, and the web). Easier said than done.

So how does [Avocode](https://avocode.com/) do that? It’s magic. No really, it’s a design parsing technology combined with the Monroe rendering engine, written in C++ and compiled to WebAssembly via Emscripten, so the engine works on the server as well as on the client. Building this machine was quite a challenge. Was it a good idea? Yup, it works. Would we start such a project again if we could travel back in time? Not sure.😅

With that in mind, it’s our great pleasure to introduce you to Avocode 3.7 — an update that has cost us the most time, sweat, and merge requests to date. The new Avocode is finally powered by design processing and rendering that happens locally in the app and the reworked Monroe rendering engine that works like other vector-based design tools such as Sketch, Figma or Adobe XD.

## Precision, then speed
Up until now, the design canvas in Avocode behaved similarly to the bitmap image editors like Photoshop. When you zoomed in on a design file, it would become pixelated, since we have rendered the design only at 100% at 1x.

There were several reasons for this. In the beginning, Avocode was a developer-first tool that would help you inspect the design — get specs, code, and assets. As long as the exported assets were rendered correctly, the design preview didn’t have to be crystal sharp after going over 100% zoom. However, this changed rapidly as Avocode has become more of a design file hub for teams, where you can not only inspect, but also store files with version history and discuss design feedback. This brought in a wave of designers, stakeholders and agency clients who care very much about how crisp the design looks.

Our priority when building the rendering engine was precision. After we hit 99% design rendering precision across a sample of thousands of design files, we started to look more into a smooth zooming and rendering performance.

Until the [3.7 update](https://avocode.com/changelog), this is what would happen with every design you imported to Avocode:
1. Your design file was uploaded to the server.
2. We parsed its data structure and translated it to our universal design format Octopus so we could render it on any platform.
3. When you opened the design file on the client, Avocode would download the Octopus file (JSON object), bitmaps from the design, and also a rendered preview of the design.

All of it needed to happen before you could start inspecting layers. When you zoomed above 100%, the design would become pixelated. Generating more bitmap previews at higher scale already on the server would be a brute force fix. For example, at 4x scale we would need to render16x the amount of pixels and downloading such a bitmap would significantly decrease the app performance.

In short, we needed something more elegant.

## The challenge of web technologies
As pointed out, in the beginning, we need Avocode to run everywhere. This is possible thanks to web technologies (React.js, Node.js, Electron) which naturally come with certain limitations. The main weakness of web technologies such as JavaScript is the single threaded environment. This means that when a user requests an action, a single threaded task needs to be finished before it’s possible to continue working in the app.

Whenever you opened a design in Avocode or requested a rendering change by toggling layers, the rendering task was one — often very long — synchronous call. Since the task wasn’t split into more threads, the user couldn’t interact with the app until the call was finished.

A “quick fix” for this issue was a hybrid rendering architecture that pulled the design preview from the server while enabling local rendering for smaller design adjustments like toggling layers, so we wouldn’t have to download an utterly re-rendered design preview (a PNG or WebP around 5MB). The main problem with this solution was that if you toggled a layer that was covering a significant part of the design, the local rendering could take up to 10s and occasionally even freeze the app.

While web dev technologies don’t enable you to run multiple tasks in different threads simultaneously, the Facebook React.js team is currently working on [Concurrent React](https://reactjs.org/blog/2018/11/13/react-conf-recap.html) — a way to split long synchronous tasks from a single thread into smaller chunks. This way you would need to wait only for small bits of the job to be finished. This approach inspired us to fundamentally rework our rendering infrastructure and introduce an entirely local rendering that would split rendering tasks into smaller chunks that still run in one thread.

<Image src="44/1.png" small caption="Old (Avocode 3.6 and older) rendering running in long synchronous calls." />

Because the user interactions are unpredictable, we needed a way to find time for the rendering tasks to be completed to avoid lagging. To do that, we wrote an instruction mechanism, a bytecode if you will, that first looks at the design file complexity and generates a list of jobs that need to happen one by one. While we cannot stop the little tasks when the user interacts with the app, we can stop the bytecode interpretation between two tasks and can change the order of what will be rendered next at any time.

<Image src="44/2.png" small caption="New (Avocode 3.7) rendering thread split into short tasks." />

Since our cross-format rendering engine needs to draw and replicate everything that can appear in Sketch, Adobe XD, Figma, Photoshop and Illustrator formats correctly, we’re dealing with a very complex composition. We had to figure more than just the architecture of this solution. We had to make it fast.

It took us a while, but the 3.7 update is proof that we can compete with well-established vector editing tools in terms of the design rendering speed.

The new local rendering engine is running whenever you open a design file, zoom, move around or toggle layers. For this to work well, it’s essential to consider many time-related issues. How long should we wait to render something after an interaction? If we run the rendering tasks during the interaction, for example, while you’re zooming, it would quickly become glitchy. Instead, we had to turn on the render a few milliseconds after the interaction. While this might seem odd, it’s exactly how other vector editing tools like Adobe XD work (just try).

Another issue was finding the ultimate performance between how much memory and CPU is left on the computer and the smoothness of design rendering while zooming and moving around.

After a few months of optimization, we try to be at 60fps. When there is not enough memory or CPU, the rendering can slow down to something around 30fps, but luckily — thanks to the concurrent mode — it shouldn’t freeze.

App performance is our number one goal now, so you can expect more improvements coming, for example, we’re waiting for Web Assembly ([currently announced](https://developers.google.com/web/updates/2018/10/wasm-threads)) to launch a multiple thread environment in Chrome.


## A few performance perks
### Faster design loading
From now on, we’re not waiting for bitmaps and the whole design preview to be downloaded from the server to open the design file. This has significantly improved the design file loading performances for all design formats — in some cases even 3x. Once Avocode downloads the design data, the rendering starts and the user can already click around and inspect. Bitmaps are coming along the way. Thanks to this change, we’re finally ready to make zooming razor-sharp while not freezing the app.

### Faster design rendering while moving and zooming
We’re also rendering only the part of the design the user sees. Once that is razor sharp, we continue to pre-render other elements of the design so when you move to these parts you’d see them sharp as soon as possible. We’re also loading the bitmaps from the viewport first so you could have them ready for export quickly.

<Video src="C7OPWOrCaOc" />

### Sharp vectors scaling
Even at 400% your design files will be razor sharp — that includes vector shapes and bitmaps (depending on the resolution they were imported in to the design tool, e.g., if you added a picture 4000x4000px to Sketch and scaled it down to 1000x1000x, and import the design to Avocode, we’ll still have the bitmap ready for export up to 4000x4000px and you’ll be able to see it sharp at 400% scale).
Fonts are sharply scaled up to 400% for Adobe XD designs that were imported via the desktop app. Sharp font scaling for other formats is coming soon.

### Faster design import in the desktop app
With the 3.7 update, we’re also introducing local processing of Adobe XD files. That means your file will not have to be uploaded to the server to open it at first (it will be synced later in the background so you or your colleagues could access it from the Avocode web app as well).

<Video src="6LeYMqbeoqI" />

FYI, we’re currently working also on local Sketch design processing which will speed up your Sketch import up a notch.
Local design processing is also our first step to offering an Enterprise solution for businesses that need to keep their design files within their walls. With this technology, developers will be able to open a design file on any computer without having to upload it to the cloud and without any additional design tool.

Designers and developers work with all kinds of tools on all types of platforms, so a proper design hand-off tool needs to work with all primary design tools (Sketch, Adobe XD, Photoshop, Figma)

How we made Avocode faster with concurrent design rendering

large_3.png

medium_3.png

small_3.png

thumbnail_3.png

3.png

Wondering *how open* the Sketch file format actually is. Here’s a story behind the very first ever [PSD to Sketch Design Converter](https://avocode.com/convert-psd-to-sketch) that is now used by thousand of designers, based on technology we already had in the house...

##The journey from Photoshop to&nbsp;Sketch

Photoshop and Sketch are significantly different tools. One created for bitmap image editing, the other for vector based app design. However, Photoshop has been and still is being tweaked for user interface design.

> We found out that [Photoshop is no longer in the&nbsp;lead](https://avocode.com/design-report-2016/).

With the rise of mobile, most designers started to realise the obstacles of Photoshop driven design workflows. Suddenly you'd have to design tens if not hundreds of screens. Keeping all of this in one file requires not only a lot of data storage but also a lot of patience with moving and sharing large files. When Sketch showed up, it seemed both as a godsend and a natural development of the design workflow.

This year we have assessed data from over 1,000,000 Photoshop and Sketch designs that were uploaded to Avocode in 2016, and one of the most curious things we found out was that [Photoshop is no longer in the lead](https://avocode.com/design-report-2016/).

When we asked various designs teams about switching to Sketch, the biggest problem was, that their entire design system is in Adobe Photoshop. And the idea of recreating all this – well that&apos;s just too much time and effort they don’t have. (As a matter of fact, our product designer at Avocode went through the same experience he took the time to recreate all design assets layer by layer.)

Meanwhile, [Avocode](https://avocode.com/) is able to render uploaded Photoshop designs this means, disassembling the PSD format data structure (parsing) on our servers, translating it into our application independent data format and then rendering all layers and showing all assets (images) in the Avocode UI as close to 1:1 as possible. The reason why we have our own rendering is that unlike any other tool on the design inspecting market, we allow the developer export any layer from the design. All other tools require designers to prepare assets in the PS or Sketch design by renaming layers and setting Exportables ? which prolongs the design handoff and limits developers freedom.

> The reason why we have our own rendering is that unlike any other tool on the design inspecting market, we allow the developer export any layer from the&nbsp;design.

Then [Sketch 43](https://www.sketchapp.com/updates/#version-43) was introduced with their *Revised file format*. [Some](https://medium.com/sketch-app-sources/sketch-43-is-coming-to-town-with-a-new-game-an-open-file-format-ae62e7e7c223) even preached it?s open and it will change the game. At the time we were already able to read both Photoshop data format and the old Sketch file format (SQL database with Binary Plist documents), however, the real struggle was writing it creating a Sketch file. When Sketch released the new more open format, we thought creating a converter which would assemble a Sketch file would be a piece of cake?

<Image src="https://cdn-images-1.medium.com/max/1600/0*rxqQZMdyJiuxEIsr." small external />

##1) New Sketch app format is not human&nbsp;readable

To clarify, Bohemian Coding didn&apos;t announce the new format as open, but only as revised. Nevertheless, there was a lot of buzz in the design community about how open the new Sketch design format actually is, and what could it mean.

> This is what the fine folks at Bohemian Coding have done ? they opened up Sketch’s file format into a neat JSON making it possible for anyone to create and modify Sketch compatible files? ? [Jasim A&nbsp;Basheer](https://medium.com/sketch-app-sources/sketch-43-is-coming-to-town-with-a-new-game-an-open-file-format-ae62e7e7c223)

Well, a neat JSON would be swell. But this thing is nothing close to neat JSON. In reality, it’s a ZIP file with a lot of JSON files, each page equals one JSON file. However, text layers are described as BASE64 encoded Binary Plists, pasted inside the JSON files. Though the format is different, the data structure is 95% same as the old one.

<AdsBanner />

Since the format is not human readable, we thought there might be some documentation, but nope there’s nothing. Therefore you just have to keep looking at it until you think you understand it.

Quite a ride really. Thanks to our experience with the old format we figured it out in about 3 days. However, the more challenging part was still ahead of us: assembling a Sketch file.

##2) Building a Sketch file from a drastically different data structure (called&nbsp;PSD)

Yea, yea, we know Photoshop and Sketch are different tools. We also know that their data format semantics are significantly different. But still, we were surprised when we saw the scope of things you can do in Photoshop in comparison to Sketch. In other words, Photoshop allows designers to be super [messi](http://images.performgroup.com/di/library/goal_es/74/85/lionel-messi-barcelona-psg-uefa-champions-league-08032016_feltmf12bt0f18v9iprtnl463.jpg) while Sketch is puristically simple.

Plus there were more serious matters:

- A square in Photoshop is just a set of 4 lines. In Sketch there are additional metadata about the number of corners.
- There is currently no inner and outer glow support in Sketch. So we’d have to fake them somehow.
- There are several types of masking (at least 5) in Photoshop. Sketch has only alpha channel and vector clipping masks.
- Photoshop has its own text layer rendering, while Sketch is using macOS text rendering.


Additionally, thanks to this project we revealed and fixed a few mistakes in our internal app independent data format, for example with parsing the design grid and assigning it to a specific layer.

Nevertheless, after over a month of development, testing and fixing (with the help of our amazing [Community](https://community.avocode.com/)!) we were able to build a functional design converter, which can assemble the design layout with named layers, vector shapes and most layer effects.

<Image src="https://cdn-images-1.medium.com/max/1600/0*XXibP_hZ1bhKL6X4." small external />

##The result

> So far we have converted 11,769 Photoshop designs with an overall size of 61.6 GB, and we have a 99% conversion success&nbsp;rate.

<Image src="https://cdn-images-1.medium.com/max/1600/0*M8k_AauBesvZsMYf." small external />

Our PSD to Sketch Converter converts even large files (around 500MB) within a matter of minutes including upload, parsing and processing. So far we have converted 11,769 Photoshop designs with an overall size of 61.6 GB, and we have a 99% conversion success rate.

Our goal was not to create the impossible in Sketch but to be the first ones on the market who can not just read but also assemble the Sketch data format. Our converter is indeed the first one out there and it was warmly accepted by the design community and to date we got got [849 upvotes on Product Hunt](https://www.producthunt.com/posts/psd-to-sketch-design-converter-by-avocode).

<Image src="https://cdn-images-1.medium.com/max/1600/0*vpeuVuofEDec6a4i." small external />

<Image src="https://cdn-images-1.medium.com/max/1600/0*IbtHub-63naZLXZR." small external />

<Image src="https://cdn-images-1.medium.com/max/1600/0*REnb6qL_NsXfw1Cj." small external />

##Convert as many PSDs to Sketch as you&nbsp;like

See for yourself how close to your expectation our PSD to Sketch conversion works. It&apos;s free.

[1. Convert your PSD to Sketch here](https://avocode.com/convert-psd-to-sketch)

Here’s a step by step tutorial, [how to use our Converter](https://medium.com/avocode-stories/how-to-convert-photoshop-design-to-a-layered-sketch-file-192a8c2b98e5).

[2. Join our Slack Community of Beta testers](https://community.avocode.com/)

[3. Report bugs to our Github](https://github.com/avocode/psd-to-sketch-converter/issues)

[4. Tell us if you find it useful or what features should we add](https://avocode.typeform.com/to/tB0fkG)

##We&apos;re still in Beta. Here’s what?s&nbsp;next:

Since the text line height is still slightly broken, we need to fix calculating text layer bounding box. It requires a lot of mathematical calculations, and we want to release it once we’re absolutely sure we got it right.

> Once we get this right, we might be adding a 3 new design converters.

We also want to come up with a few faking techniques for some layer masks, layer styles like Inner and Outer glow and Circular and Angular gradient color fill options.

And last but not least we’re working on improving the performance to speed up the conversion so you can get your Sketch files faster.

Once we get this right, we might be adding 3 new converters:

- PSD to Xd
- Sketch to Xd
- Xd to Sketch


And in case you’re curious about **Sketch to PSD conversion** – we’d like to build it too. Please understand that assembling a PSD data format is a much bigger project than creating a Sketch file. Until then, stay tuned and make sure to check out our core product [Avocode](https://avocode.com/) – which has made our design parsing technology possible.

If you want to be the first to know about things we are working on, [follow us on Twitter](https://twitter.com/OpenDesignDev) or [join our community](https://opendesign.dev/community).


Wondering how open is the Sketch file format? Here’s a story behind the very first ever Photoshop to Sketch Design Converter that is now used by thousand of designers, based on technology we already had in the house.

Technology