リキ萌
bff899c9c0
brush rendering is now completely client-side. the server only receives edits the client would like to do, in the form of PNG images of chunks, that are then composited onto the wall known issue: it is possible to brush up against the current 256 chunk edit limit pretty easily. I'm not sure it can be solved very easily though. the perfect solution would involve splitting up the interaction into multiple edits, and I tried to do that, but there's a noticable stutter for some reason that I haven't managed to track down yet. so it'll be kinda crap for the time being.
123 lines
4.2 KiB
TOML
123 lines
4.2 KiB
TOML
[build]
|
|
|
|
# The settings below control how the site is compiled down to static files.
|
|
|
|
# List of Handlebars templates to render.
|
|
render_templates = [
|
|
{ template = "fonts.hbs.css", to_file = "static/fonts.css" },
|
|
|
|
{ template = "index.hbs.html", to_file = "static/index.html" },
|
|
{ template = "docs.hbs.html", from_dir = "docs", to_dir = "docs" },
|
|
]
|
|
|
|
# List of JavaScript `import` root directories.
|
|
import_roots = [
|
|
{ name = "rkgk", path = "static" },
|
|
]
|
|
|
|
[build.page_titles]
|
|
|
|
# This is a mapping of filenames to page titles.
|
|
# The Djot template mode exposes this data as the variable {{ title }}.
|
|
# When a title is not provided, the path is used.
|
|
|
|
"docs/rkgk.dj" = "Introduction to rakugaki"
|
|
"docs/system.dj" = "System library"
|
|
|
|
[wall_broker.default_wall_settings]
|
|
|
|
# The settings below control the creation of new walls.
|
|
|
|
# The maximum number of chunks on a wall.
|
|
# It is recommended to cap this to something reasonable so that users can't trash the server's
|
|
# disk space very easily.
|
|
max_chunks = 65536
|
|
|
|
# Maximum concurrent sessions connected to a wall.
|
|
# Note that a single user can have multiple sessions at a time.
|
|
max_sessions = 128
|
|
|
|
# The size of chunks.
|
|
# Choosing an appropriate size for chunks is a tradeoff between performance and disk space - 168 is
|
|
# chosen as a reasonable default which is just small enough to perform operations on fairly quickly
|
|
# and responsively.
|
|
chunk_size = 168
|
|
|
|
# The size of the area that can be drawn over by a brush, in pixels.
|
|
# The larger this area, the more CPU-expensive brushes get overall, but the larger the image a brush
|
|
# can produce.
|
|
paint_area = 504
|
|
|
|
# Maximum size of a single edit, in chunks.
|
|
# You don't want to make this _too_ large, otherwise the client will try to allocate too many
|
|
# chunks at once. Way more than WebAssembly's 4GiB address space can handle.
|
|
max_edit_size = 256
|
|
|
|
[wall_broker.auto_save]
|
|
|
|
# How often should modified chunks be saved to the database.
|
|
interval_seconds = 10
|
|
|
|
[haku]
|
|
|
|
# The settings below control the Haku runtime on the server side.
|
|
# Technically clients may override these settings with some hackery, but then the server may not
|
|
# register changes they make to the canvas.
|
|
|
|
# Maximum length of source code.
|
|
max_source_code_len = 65536
|
|
|
|
# Maximum amount of source code chunks.
|
|
# This should be at least 2, to allow for loading in a standard library chunk.
|
|
max_chunks = 2
|
|
|
|
# Maximum amount of defs across all source code chunks.
|
|
max_defs = 256
|
|
|
|
# Maximum amount of unique tags across all source code chunks.
|
|
# Note that tag uniqueness is determined by the tag's source code string, so two instances of `A`
|
|
# only occupy one slot.
|
|
max_tags = 256
|
|
|
|
# Maximum amount of tokens a single chunk can have.
|
|
max_tokens = 65536
|
|
|
|
# Maximum amount of events that the parser may emit in a single chunk.
|
|
# These don't take up that much memory (a byte per event), so having many of these isn't a big deal.
|
|
max_parser_events = 65536
|
|
|
|
# Maximum amount of AST nodes in a single parse.
|
|
ast_capacity = 65536
|
|
|
|
# Maximum size of a bytecode chunk.
|
|
# This must be <= 65536 due to bytecode limitations - offsets are stored as 16-bit integers.
|
|
chunk_capacity = 65536
|
|
|
|
# Maximum size of the value stack.
|
|
# This defines how many local variables and temporary values can be in scope at a given moment.
|
|
# Effectively, this limits how deep and complex a single expression can get.
|
|
stack_capacity = 1024
|
|
|
|
# Maximum call stack capacity.
|
|
# This defines how much code is allowed to call itself recursively.
|
|
call_stack_capacity = 256
|
|
|
|
# Maximum amount of refs.
|
|
# Refs are big, reused, unique values that do not fit on the value stack - akin to objects in
|
|
# languages like Python, but immutable.
|
|
ref_capacity = 2048
|
|
|
|
# Amount of fuel given to the VM.
|
|
# Each instruction executed by the VM consumes fuel. The VM will continue running until it runs out
|
|
# of fuel completely.
|
|
# An unfortunate side effect of this is that since Haku is a functional language, a brush running
|
|
# out of fuel means it will not be rendered at all, because there is no complete value returned.
|
|
fuel = 65536
|
|
|
|
# Amount of heap memory available to the VM.
|
|
# Heap memory is used to limit how much data refs can allocate.
|
|
# In particular, large arrays use up this memory - such as list backing arrays.
|
|
memory = 1048576
|
|
|
|
# Maximum depth the renderer is allowed to recurse to.
|
|
render_max_depth = 256
|