Update diagrams

README.md

@@ -27,31 +27,6 @@ The current plan:
 
 *Note:* Since HyperText (so is HTML) is not used, you can even ditch the HTTP protocol. However TLS, for encryption, can still be used.
 
-## Text on Screen Flowcharts
-
-**Prepare steps**
-
-```plantuml
-(*) --> "Load fonts glyphs (ttf)/default font"
---> "Create Font Atlas"
---> "Create Viewport"
--->[Ready for render] (*)
-```
-
-**Text rendering**
-
-```plantuml
-(*) --> "Get file online /\nRead from disk"
--->[Content in memory] "Parse document"
--->[AST output] "Convert AST to Bitmap struct"
--->[Ready for painter] "Paint text on Viewport"
--->[Text visable on Screen] (*)
-```
-
-*ttf* = TrueType Font
-
-*AST* = Abstract Syntax Tree
-
 ## Devs
 
 Decentralized Browser written in C++20 with C libraries. And using the [cmark-gfm](https://github.com/github/cmark-gfm) library, used for CommonMark (markdown) parsing.
@@ -64,7 +39,7 @@ For now we will use markdown as the source of the site. No HTML and JavaScript a
 
 I'm using VSCodium editor, with the following extensions installed: `C/C++`, `Cmake` and `Cmake Tools` .
 
-## Depedencies
+### Depedencies
 
 For the build you need at least:
 
@@ -77,6 +52,12 @@ For release packages you also need:
 
 * CPack
 
+### Diagrams
+
+There existing several design and/or research diagrams of Browser by using PlantUML. Sometimes words aren't enough to explain yourself.
+
+[Check-out the diagrams page](docs/diagrams.md).
+
 ### 2D/Vector engines - Under Research
 
 We are currently in an exploration phase, which 2D vector graphics rendering library we should us.

docs/diagrams.md

@@ -0,0 +1,47 @@
+# Diagrams
+
+List of sequence/UML diagrams for design and/or research reasons. Could may be used in a whitepaper if still relevant.
+
+## High-level Design
+
+```plantuml
+(*) --> "Fetch source document from a P2P network"
+--> "Parse markdown document"
+-->[AST model output] "Convert AST to X & Y coords with text/drawing items"
+--> "Add items to a drawing scene"
+--> "Render the scene on screen"
+-->[User sees the output on screen] (*)
+```
+
+*P2P* = Peer-to-Peer (decentralized networks)
+
+*AST* = Abstract Syntax Tree
+
+## Text on Screen Flowcharts
+
+Folowing diagrams are only applicable when you need to draw text on the screen without supporting library.
+
+However, most GUI libraries does support you in drawing text on a screen.
+
+**Prepare steps**
+
+```plantuml
+(*) --> "Load fonts glyphs (ttf)/default font"
+--> "Create Font Atlas"
+--> "Create Viewport"
+-->[Ready for render] (*)
+```
+
+**Text rendering**
+
+```plantuml
+(*) --> "Get file online /\nRead from disk"
+-->[Content in memory] "Parse document"
+-->[AST model output] "Convert AST to Bitmap struct"
+-->[Ready for painter] "Paint text on Viewport"
+-->[Text visable on Screen] (*)
+```
+
+*ttf* = TrueType Font
+
+*AST* = Abstract Syntax Tree

docs/research.md

@@ -1,6 +1,22 @@
 # Research topics
 
-1. *First Goal:* We want to draw text on the screen as fast as possible. Skipping the HTML parser step, meaning: `Markdown` -> `screen` instead of: `Markdown` -> `HTML` / `CSS` -> `screen`.
+1. *Goal #1:* We need to be able to draw text on the screen as fast and efficient as possible by using some existing **GUI Library**. Skipping the HTML parser step, meaning: `Markdown` -> `screen` instead of: `Markdown` -> `HTML` / `CSS` -> `screen`. Which should give us *full control* about the rendering and drawing sequences.
+   - *Conclusion:** GTK + Cairso & Pango
+2. *Goal #2:* We need a decentralized solution to transferring markdown files across the network, **without** client <> server typology. And no single-point-of-failure. And no easy censorship.
+
+## P2P/Decentralized Protocol/Network
+
+See the list of P2P or Decentralized protocols/network solutions below.
+
+### Hypercore
+
+Hypercore is a distributed append-only log. See [Hypercore protocol website](https://hypercore-protocol.org/).
+
+Part of the [Dat Foundation](https://dat.foundation/).
+
+Why NodeJS and not C++?
+
+
 
 ## GUI libraries
 
@@ -43,7 +59,7 @@ We can try using a [QGraphicsScene](https://doc.qt.io/qt-5/qgraphicsscene.html)
 * [Drawing Text/line using QPainter](https://www.youtube.com/watch?v=tc3nlNEAdig) (video).
 * [Calligra](https://github.com/KDE/calligra) Word processor using Qt, maybe also creating their own text painting as well?
 
-**Conclusion:** No, QGraphics will NOT be used, way too slow.
+**Conclusion:** No, QGraphics will NOT be used, way too slow. Not performant enough.
 
 ### GTK
 
@@ -53,6 +69,8 @@ GTK is using the Cairo 2D graphics renderer using rasterization (CPU) bvy defaul
 
 Problem is its only raster graphics using the CPU. Which isn't that bad, but I really miss hardware acceleration via OpenGL/Vulkan (cairo-gl will never be stable and is a dead-end). There is no vector generation. Cairo can however be used [together with SDL](https://www.cairographics.org/SDL/) they claim.
 
+**Conclusion:** Seems like a perfect fit! Ideal for content first apps/viewer.
+
 #### GTK +  OpenGL/Vulkan
 
 Since GTK version 4, they are no longer using Cairo, but directly OpenGL/Vulkan calls. Using `GtkSnapshot`.
@@ -81,7 +99,7 @@ Meaning the app and Skia has quite a tight build relationship. Even the Skia "He
 
 After 2 full days, I gave up to build of an independent hello world example linking skia as static library. It's really really hard to getting started, this is a red flag.
 
-**Conclusion:** Looks like a no.
+**Conclusion:** No, too complex, even hard to get started.
 
 ## Multimedia libraries / Vector graphics engine
 
@@ -125,7 +143,7 @@ OpenVG is part of the Khronos group, which is a plus. But it looks a bit too muc
 
 [NanoVG](https://github.com/memononen/nanovg) is a 2D vector drawing library on top of OpenGL for UI and visualization. Its very small, with a lean API.
 
-**Conclusion:** *No Conclusion yet* - Under investigation
+**Conclusion:** *No Conclusion yet*
 
 ### ImGui
 
@@ -140,4 +158,4 @@ Also the application suffered quite some screen tearing (even with VSYNC on).
 
 My expectation is that there are some huge synchronization issues with Imgui and OpenGL/Vulkan backends. Therefor is my advice is not to use Imgui for text rendering applications until futher notice. This is a shame.
 
-**Conclusion:** No, Will NOT be used, some very strange performance issues under Linux (X11).
+**Conclusion:** No, Will NOT be used, some very strange performance issues under Linux (X11). Not production ready as main GUI.