Next Steps for GraphUI in JogAmp & Gamp (I) – Göthel Software Blog (original) (raw)

After the release of JogAmp 2.6.0 and the launch of Gamp earlier with its initial Graph code, I need to recapitulate the existing Graph and GraphUI code base within Jogl to evaluate our next steps including its Gamp implementation.

JogAmp‘s Jogl contains the Java code-base of GraphUI and Gamp shall evolve into its native C++ companion. Both are considered cross-platform, while only Gamp is able to be fully compiled down to the metal and executed w/o virtual machine while still capable of serving web browser via WebAssembly (yes, this involves a virtual machine again).

Jogl’s current Graph Implementation

• Resolution independent NURBS curves rendering via GPU shader (the base), including
  • OutlineShape w/ quadratic curves and lines
  • Delaunay tessellation
  • GPU vertex- and texture-coordinate pipeline of OutlineShapes into Region objects
  • GPU shader management for various use-cases
    * Monochrome, colorchannel, (streaming) textures, per-pixel clipping, ..
    * Antialiasing 2nd pass using a multisample framebuffer object per region of a OutlineShapes
• Font support
  • Typecast TTF font parser, developed by David Schweinsberg and patched (enhanced tables, bug fixes)
  • Streaming in TTF font files
  • Single Glyph to OutlineShape conversion
• Text shaping, i.e. layout unicode text string to a list of OutlineShapes (Glyph Data)
  • This includes kerning, orientation, etc and rudimentary output validation
  • Implementation is focused on performance, i.e. reuses pre-processed tessellated OutlineShapes, which will be scaled and translated via the usual model-matrix into world- or any other sub-space.

Jogl’s current GraphUI Implementation

GraphUI’s code base has been designed and implemented in a test- or design-driven manner, step by step – and is subject to be changed.

A Shape represents the basic node, independent from Graph, while GraphShape is its Graph derivation.

A Shape holds its pointer and keyboard listener and owns its dedicated translation, scale, rotation and zoom parameters as well its cached 4×4 counterpart matrix.

• Simple DAG scenegraph w/ Shape and Group within a Scene
  • The usual setup, however, it uses a simple projection + model-view matrix combo instead of a dedicated camera view-matrix (TODO?).
  • Ray picking
  • Pointer/Mouse event propagation inside out w/ coordinate transformation
  • Shapes are reusable (DAG) and the OutlineShape data is cached for re-usage for performance
  • Lacks cached world-matrix or model-view matrix for e.g. picking (TODO)
• Layout (w/ CSS semantics)
  • BoxLayout
  • GridLayout
  • Alignment, Gap, Margin and Padding
• Shape and (layout) Group implementations
  • Label, a text string label
  • Button, a multi-state w/ text for each
  • ImageButton, a single texture button
  • TexSeqButton, a texture streaming button
  • MediaButton, a streaming video texture button
  • GLButton, a full GLEventListener button to embed OpenGL visuals
  • HUDShape, a head-up-display shape usable for custom tool-tip implementations
• Widgets, i.e. Shape/Group w/ complex controls (interaction)
  • MediaPlayer a MediaButton with UI, subtitles and controls
  • RangedGroup clipped (grid) Group w/ slider
  • RangeSlider a scroll-slider

Graph Enhancements

The following items are earmarked (but not funded) to be implemented for Graph.

• Tessellation
  • Used Delaunay tessellation works for most shapes, however, certain corner cases still exist w/ wrong results
  • Alternative traditional GLU tessellation could be utilized as an optional fallback
    * Performance impact might be limited due to the caching within OutlineShape
• Antialiasing (AA)
  • Current state
    * Use full scene multisampling (MSAA), e.g. 2x – 4x gives good results, or
    * use our internal framebuffer based OutlineShape region multisampling on low DPI, e.g. 4x gives good results, or
    * use a high resolution monitor >= 200 DPI (?)
  • Enhancement: Single pass AA by Graph shader
    * Widen shader area of lines and curve segments, model-based (performance, reused)
    * otherwise, AA gradient would reduce the actual model representation mass
    * Pass original line coordinates (approximated texture coords) to render similar to curves
    * Find appropriate gradient stepping for AA

Potential Gamp Implementation of Graph/GraphUI

So far, I have simply translated the existing Java code into C++20 while also flattened certain internal data representations.

The currently existing shape demos demonstrate non-curve glutess tessellation using floats (sub-module) as well as line and curve capable Graph tessellation using Delaunay. This was a first approach to potentially use glutess as an alternative in the next steps forward.

As you can see above, the biggest code-base on the TODO list is the font/type parsing, text and GraphUI segment.

Font/Type Parsing

• Translate our enhance Typecast Java codebase (see above) to C++
• Use stb‘s TTF implementation
• Use HarfBuzz‘s OpenType implementation (?, not fully compatible w/ TrueType?)

Test Shaping (Layout)

• Translate our text layout Java codebase (see above) to C++ (small, good enough?)
• Use HarfBuzz‘s implementation (?, bigger)

Java to C++ Source Compiler

I will also double check for a good Java to C++ source code translator (not bytecode), i.e. soothing the typing a little.
However, so far the few existing ones were not sufficient as they either used a bytecode approach, obfuscated the C++ target making the result unreadable really.

It is C++’s high expressiveness which probably simply must be done by hand.
Of course, I used a few sed scripts to shortcut the usual naming replacements.

Conclusion so far…

Lots to do, get something done – day by day.

Funding & Contracting

To continue JogAmp to support its wide range of user applications and to potentially further Gamp, I seek contracting work (best in a related project) or direct project funding by companies and institutions. Please contact me sgothel at jausoft dot com.

(A Gamp Browser-Screenshot)

Post navigation