|
3 | 3 | <img alt="Skia Canvas" src="test/assets/readme-header@2x.png">
|
4 | 4 | </picture>
|
5 | 5 |
|
6 |
| -Skia Canvas is a browser-less implementation of the HTML Canvas drawing API for Node.js. It is based on Google’s [Skia](https://skia.org) graphics engine and as a result produces very similar results to Chrome’s `<canvas>` element. The library is well suited for use on desktop machines where you can render hardware-accelerated graphics to a window and on the server where it can output a variety of image formats. |
| 6 | +Skia Canvas is a browser-less implementation of the HTML Canvas drawing API for Node.js. It is based on Google’s [Skia](https://skia.org) graphics engine and, accordingly, produces very similar results to Chrome’s `<canvas>` element. The library is well suited for use on desktop machines where you can render hardware-accelerated graphics to a window and on the server where it can output a variety of image formats. |
7 | 7 |
|
8 | 8 | While the primary goal of this project is to provide a reliable emulation of the [standard API](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) according to the [spec](https://html.spec.whatwg.org/multipage/canvas.html), it also extends it in a number of areas to take greater advantage of Skia's advanced graphical features and provide a more expressive coding environment.
|
9 | 9 |
|
10 | 10 | In particular, Skia Canvas:
|
11 | 11 |
|
12 | 12 | - is fast and compact since rendering takes place on the GPU and all the heavy lifting is done by native code written in Rust and C++
|
13 |
| - - renders directly to [windows](#window) using the OS's native drawing routines and provides a browser-like [UI event][win_bind] framework |
| 13 | + - can render to [windows](#window) using an OS-native graphics pipeline and provides a browser-like [UI event][win_bind] framework |
14 | 14 | - generates output in both raster (JPEG & PNG) and vector (PDF & SVG) image formats
|
15 | 15 | - can save images to [files][saveAs], return them as [Buffers][toBuffer], or encode [dataURL][toDataURL_ext] strings
|
16 | 16 | - uses native threads and the Node [worker pool](https://github.com/neon-bindings/rfcs/pull/35) for asynchronous rendering and file I/O
|
@@ -271,15 +271,15 @@ function synchronous(){
|
271 | 271 |
|
272 | 272 | #### `.gpu`
|
273 | 273 |
|
274 |
| -The `.gpu` attribute allows you to control whether rendering occurs on the graphics card or uses the CPU. Rendering is hardware accelerated by default, using [Metal](https://developer.apple.com/metal/) on macOS and [Vulkan](https://www.vulkan.org) on Linux and Windows. To use software-based rendering, set the `.gpu` property to the `false`. If the current platform doesn't support GPU-based rendering, the property will be `false` by default (see [this article](https://linuxconfig.org/install-and-test-vulkan-on-linux) for some tips on getting Vulkan working on Linux). |
| 274 | +The `.gpu` attribute allows you to control whether rendering occurs on the graphics card or uses the CPU. Rendering is hardware accelerated by default, using [Metal](https://developer.apple.com/metal/) on macOS and [Vulkan](https://www.vulkan.org) on Linux and Windows. To use software-based rendering, set the `.gpu` property to `false`. If the current platform doesn't support GPU-based rendering, the property will be `false` by default (see [this article](https://linuxconfig.org/install-and-test-vulkan-on-linux) for some tips on getting Vulkan working on Linux). |
275 | 275 |
|
276 | 276 | #### `.pages`
|
277 | 277 |
|
278 | 278 | The canvas’s `.pages` attribute is an array of [`CanvasRenderingContext2D`][CanvasRenderingContext2D] objects corresponding to each ‘page’ that has been created. The first page is added when the canvas is initialized and additional ones can be added by calling the `newPage()` method. Note that all the pages remain drawable persistently, so you don’t have to constrain yourself to modifying the ‘current’ page as you render your document or image sequence.
|
279 | 279 |
|
280 | 280 | #### `.pdf`, `.svg`, `.jpg`, and `.png`
|
281 | 281 |
|
282 |
| -These properties are syntactic sugar for calling the `toBuffer()` method. Each returns a Node [`Buffer`][Buffer] object with the contents of the canvas in the given format. If more than one page has been added to the canvas, only the most recent one will be included unless you’ve accessed the `.pdf` property in which case the buffer will contain a multi-page PDF. |
| 282 | +These properties are syntactic sugar for calling the `toBuffer()` method. Each returns a [Promise][Promise] that resolves to a Node [`Buffer`][Buffer] object with the contents of the canvas in the given format. If more than one page has been added to the canvas, only the most recent one will be included unless you’ve accessed the `.pdf` property in which case the buffer will contain a multi-page PDF. |
283 | 283 |
|
284 | 284 | ##### METHODS
|
285 | 285 |
|
@@ -971,7 +971,7 @@ win.on('keydown', ({key}) => {
|
971 | 971 | })
|
972 | 972 | ```
|
973 | 973 |
|
974 |
| -In the previous example, we created references to the window’s `ctx` and `canvas` objects from outside the event handler, but sometimes you'll want to use the same handler function in more than one window. You can get a reference to the specific window associated with an event through its `target` attribute, allowing us to write an event handler that doesn't contain a reference to the `win` variable it's attached to: |
| 974 | +In the previous example, we used references to the window’s `ctx` and `canvas` that were created outside the event handler, but this makes the function less general since it's tied to a single window. We can get a reference to the specific window associated with an event through its `.target` attribute, allowing us to write an event handler that doesn't contain a reference to the `win` variable it's attached to: |
975 | 975 | ```js
|
976 | 976 | const closeWindow = (e) => {
|
977 | 977 | console.log("now closing window:", e.target)
|
@@ -1128,7 +1128,7 @@ An array of references to all of the `Window` objects that have been created and
|
1128 | 1128 | ##### METHODS
|
1129 | 1129 |
|
1130 | 1130 | #### `launch()`
|
1131 |
| -Any `Window` you create will schedule the `App` to begin running as soon as the current function returns. You can make this happen sooner by calling `App.launch` within your code. The `launch()` method will not return until the last window is called so you may find it handy to place ‘clean up’ code after the `launch()` invocation. |
| 1131 | +Any `Window` you create will schedule the `App` to begin running as soon as the current function returns. You can make this happen sooner by calling `App.launch` within your code. The `launch()` method will not return until the last window is closed so you may find it handy to place ‘clean up’ code after the `launch()` invocation. |
1132 | 1132 | >Note, however, that the `App` **cannot be launched a second time** once it terminates due to limitiations in the underlying platform libraries.
|
1133 | 1133 |
|
1134 | 1134 | #### `quit()`
|
|
0 commit comments