TODO

[hyrious]

Graphics isn't an easy thing at all. Even on the web. This repo is intended to paint one important thing on canvas -- Strokes, which are often provided by ✏️ pen input devices (like wacom tablets or apple pencil). i.e. I don't care about other shapes or functions (embedding a note pad in the canvas?, no). But everything related to simulating a real canvas should be implemented. I came up with these (maybe not completed):

• It should capture user inputs, pointer event is a good start.
• It should paint strokes correctly, lines are not hard, the hard things are --
  • What if it has dynamic width, e.g. from pressure.
  • What if it has dynamic color, e.g. a rainbow pen.
  • What if it is not solid, e.g. PS (PhotoShop) users may be familiar with many weird brushes, ones for drawing hair, ones for drawing clouds.
• It should has reasonable performance. There may be thousands of hundreds of strokes on the canvas, but it should not slow down until the RAM is full. Try make use of some tricks -- split loops into frames, workers; cache drawing results, webgl, etc.
• A bit of opposite of previous one, it should eat as less memory as possible. The most expensive resources on the web are: <canvas> > <svg> > {}/()=>{}. Don't create them, reuse them.

Resources:

• Chrome's Handwriting Recognition API. I may copy the data structure in this proposal. e.g. Set the top-left corner as (0, 0).
• Paper.js, world's oldest vector graphing library, never got its 1.0.0. I guess this is because it just invents a new scripting language (historical reasons) and handles all drawing implicitly (you assign a variable, the view changes), which leads to unnecessary complexity and memory leaks.

[hyrious]

Some further ideas/info about this repo:

• Some devices cannot handle draw-call at a high rate (about 100~200fps on mobiles like iOS). However, you will only feel smooth when your input is handled and drawn as soon as the JavaScript receive the pointer events. This is a deal:
  • If drawing too fast, the queued requests will definitely slow down the whole runtime because browsers put them in a single thread.
  • If drawing slow like align them in 60fps animation frame or 30fps, you will feel not that smooth. But the pressure of the runtime is down, so maybe the whole performance is better than above.
  • In 60fps, you will obviously find your input is drawn at least one frame after the event, which is at least 18ms. People often do not feel a button's animation lag, but the drawing process is continuous.
  • So we must construct a rendering strategy that slows down the drawing when it finds high pressure of the runtime. This can be done by measuring each frame's total timing usage. If it is averagely lower than 20ms, we'd say it is ok. If it cannot handle frames in 60fps, then it can perform a batch optimization.
• Another optimization is about reusing the resources: <canvas> and draw-calls. Some elements can be drawn at once (like same-color strokes and shapes). On the other hand, a canvas is a linear memory, which has its size limit. So we'd better only create canvases at a maximum size, then concat them visually on the screen. This also avoids memory-leak on iOS.
• One thing I want to learn is about (earth) maps. They have a very smooth feeling when you resize the view quickly. Despite of any webgl tech, it is obvious (by only seeing) that maps often has an optimization of "minimaps" (I just call it in the way). The idea is to simplify the elements at different zooming levels. When the scale is high, there's no need to draw hundreds of points in 1px. This needs us to create some AOT tools to calculate the minimaps. There are some simplifying algorithms already.