SW Tracking Report Feature Objectives Overview: Difference between revisions
| Line 187: | Line 187: | ||
** [https://openjdk.org/projects/babylon/articles/linq Babylon] | ** [https://openjdk.org/projects/babylon/articles/linq Babylon] | ||
GraalVM experimentally hosts wasm only, | GraalVM experimentally hosts wasm only, | ||
but is not producing a wasm target for the wasm (browser) runtime. | but is not producing a wasm target for the wasm (browser) runtime. | ||
Revision as of 05:11, 3 April 2024
This list exposes building blocks for potential use and business case scenarios using Java & JogAmp on Desktop and Embedded Devices.
Notably Graph & Graph UI as well as Wayland & Vulkan support could be of interest here?
Also see Completed Features Objectives ...
Graph
Graph/GraphUI Progress Blog Entries
Desired Work Items
This is an ad-hoc list of desired features and fixes, which shall result in proper bug-reports soon.
After having reached UI usability with widgets and clipping, the following items are becoming more interesting
- Fix general issues with current implementation and API, if any
- Fix Graph rendering bugs (Tessellation)
- Use of super-sized triangles to render Graph lines & curves to allow
- Using a one-pass smooth AA Graph renderer to save resources otherwise used in our pass-2 FBO supersampling renderer
- Generate outlines, i.e. outlined fonts
- Generate special effects like glowing/pumping outlines indicating selection etc
- Allow passing or better attaching per-vertex color to Graph Outline (API)
Add subtitles in MediaPlayer GraphUI widget(done)- Add video encoding in our FFmpeg binding, i.e. an FFMPEGMediaRecorder (Encoding + Multiplexing)
Further more, if so desired, a C++ implementation of our Graph + GraphUI framework may also be of interest.
In case any company or organization is interested and likes to support this work and may also like to receive support in adopting this framework, please contact Göthel Software e.K.
OpenJDK Compatibility / Integration
Objectives should be to allow seamless integration into OpenJDK's deployment and JVM launch methods.
A dual JAR file to be used with and without modules is desired, however it seems that certain JAR options are not available with this configuration if our classes are not build as modules itself.
An optional JVM Launch Pad (JLP) might be helpful, even though it instructs further complexity and is not helping with a vanilla OpenJDK deployment.
OpenJDK >= 11
See Bug 1404
JVM Commandline Parameter
Current used 'add-opens' in my JogAmp test scripts for Java >= 11, covering all AWT utilization including background erase is:
--add-opens java.desktop/sun.awt=ALL-UNNAMED --add-opens java.desktop/sun.awt.windows=ALL-UNNAMED --add-opens java.desktop/sun.java2d=ALL-UNNAMED
OpenJDK >= 2x
See Bug 1505
JVM Commandline Parameter
Current used 'add-opens' in my JogAmp test scripts for Java >= 23, covering all AWT utilization including background erase is:
--add-opens java.desktop/sun.awt=ALL-UNNAMED --add-opens java.desktop/sun.awt.windows=ALL-UNNAMED --add-opens java.desktop/sun.java2d=ALL-UNNAMED --TO_BE_DETERMINED
Graph UI
Graph UI will enable an immersive UI within the 3D scene on the desktop, mobile and on bare-metal embedded systems without a windowing system.
Graph UI utilizes Resolution Independent NURBS Curves Rendering using Programmable Graphics Pipeline, i.e. rendering curves directly on the GPU, resolution independent [ paper, slides ].
This method allows us to have an ultimate fast font and UI rendering engine, suitable for all devices and applications. No CPU based curve nor font pre-rendering (matching a target resolution) is required.
Think of an integrated QT or OpenJFX in your 2D/3D application working on desktop and embedded devices even w/o any windowing system on top of a plain console DRM/GBM as support by JOGL(EGL) and NEWT as demonstrated by Xerxes on a Raspberry Pi4.
Reimagine Java on Desktop & Bare-Metal Devices demonstrates the updated Graph Curve Rendering and UI, while this update shows clipping and widgets. Further updates will be posted here....
Notably the Graph Curve Rendering is almost feature complete, as well as our own user input including gesture detection within NEWT.
- Parent Main Node
- Dependency Tree
- All GraphUI
- Open Items graphui
| ID | Version | Product | Component | Priority | Severity | Status | Summary |
|---|---|---|---|---|---|---|---|
| 544 | tbd | GraphUI | Core | P3 | enhancement | UNCONFIRMED | RFE for UI part of the graph package |
| 804 | tbd | GraphUI | Plugin | --- | enhancement | UNCONFIRMED | Add SVG Input Specification (Curved Geometry, Object Interaction) to Graph-UI |
| 805 | 2.6.0 | GraphUI | Core | --- | enhancement | IN_PROGRESS | Basic Graph-UI Widgets - I |
| 1483 | tbd | GraphUI | Plugin | P4 | normal | CONFIRMED | Enhanced Graph-UI Elements - II |
4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);
- Completed Items graphui
15 Total; 0 Open (0%); 15 Resolved (100%); 0 Verified (0%);
Jogl / Graph
Dependency Tree Graph Font Issues
- Open Items Jogl / graph
| ID | Version | Product | Component | Priority | Severity | Status | Summary |
|---|---|---|---|---|---|---|---|
| 1064 | tbd | Jogl | graph | P1 | major | IN_PROGRESS | Fix Graph Font Rendering (group for related bugs) |
| 1502 | 2.6.0 | Jogl | graph | P4 | normal | IN_PROGRESS | Graph: Improve Performance of Non-Convex/Intersection Classification and/or Intersection-Test itself (Bug 1501) |
| 1503 | 2.6.0 | Jogl | graph | P4 | normal | IN_PROGRESS | Graph: Resolve Tessellation Bugs (Delaunay Triangulation) - Part II |
3 Total; 3 Open (100%); 0 Resolved (0%); 0 Verified (0%);
- Completed Items Jogl / graph
33 Total; 0 Open (0%); 32 Resolved (96.97%); 1 Verified (3.03%);
WebAssembly (wasm) Target Platform
Overview
See Bug 1506 describing this feature.
Since Java Applets are not more supported within browser or by OpenJDK for years, it may seems feasible to evaluate the WebAssembly target running within e.g. web browser nowadays.
An initial evaluation on small C++ projects using the emscripten front-end for LLVM's clang++ to wasm compiler, which supports many ported system libraries like SDL, OpenGL, .. has been undertaken successfully with variable results.
The wasm target is comparable to Java bytecode but the wasm virtual machine is not as performant, efficient or flexible as actual native code. The lack of hassle free native threads and native high-performance may remind one of the first JVM steps. The wasm code runs within a virtual machine like the JVM and additionally lacks of native binding capabilities.
Some limitations may be overcome, others are likely by design as it usually runs on the same browser virtual machine as the JavaScript companion. Compromises must be made on shared memory and native threads, cached non-local file I/O and socket communication - while other native features will simply never work, e.g. operating system ioctl-calls, etc.
Opening the door for any language to be compiled to a platform independent intermediate representation (IR) like Java’s bytecode suitable for a versatile runtime environment including its virtual machine is surely still desirable.
Initial C++/wasm Evaluation
Our little gfxbox2 games compiled to wasm run about 40-60% slower within a browser than in native code, depending on coding strategy of our graphics (pixelmap vs SDL/OpenGL primitives).
The used emscripten frontend allowed us to use memory-growth, envelop files used in the wasm file, add cheap stack-overflow cockies and nullptr writes and so forth. Utilization of OpenGL ES via SDL2 was a breeze.
The underlying LLVM compiler did an excellent job and overall, the transition was easy and almost involved no code changes but dropping native thread (std::thread) usage.
The overall program structure had to be adapted to align to the single-thread main-loop workflow and specific emscripten-javascript hooks added to allow seamless interaction. All in all, nothing to be too afraid of and depending on the class of applications to be ported to the browser these days, a feasible procedure.
Java Support
Java support for the WebAssembly target are claimed to be supported by
Further interesting bits & pieces
GraalVM experimentally hosts wasm only, but is not producing a wasm target for the wasm (browser) runtime.
- GraalVM + wasm
- with the help of emscripten
- GraalVM + JNI
Java Browser Outlook
So far the only question arises why reinventing the wheel once again? Dropping utilization of a well working JVM for the web had no technical reasoning.
However, in case no suitable wasm target for the Java bytecode and the Java Runtime pieces can be established, one might either want to also look into bringing back the JRE into the browser or painfully drop Java for C++, as the latter is already close to have acceptable (slower and limited) wasm target runtime properties.
NEWT
11 Total; 11 Open (100%); 0 Resolved (0%); 0 Verified (0%);
NEWT + Wayland
Currently NEWT supports the X11/Xorg windowing server on Unix alike platforms.
It might be desired to add direct support to Wayland, as we already added support for bare metal devices w/o a windowing system via the Linux DRM/GBM console mode throughout JOGL + NEWT.
Vulkan
| ID | Version | Product | Component | Priority | Severity | Status | Summary |
|---|---|---|---|---|---|---|---|
| 1137 | tbd | Jogl | vulkan | --- | enhancement | CONFIRMED | Add Support for Vulkan (group) |
| 1138 | tbd | Jogl | vulkan | --- | enhancement | UNCONFIRMED | Common Subset of OpenCL >= 2.1 / Vulkan Command API (Queue, Buffer) and Context |
| 1139 | tbd | Jogl | vulkan | --- | enhancement | UNCONFIRMED | Generalize high-level API GLContext, GLDrawable, GLAutoDrawable for Vulkan and OpenGL |
| 1140 | tbd | Jogl | vulkan | --- | enhancement | UNCONFIRMED | Add Support for SPIR-V >= 2.0 (group) |
4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Video Encoding/Decoding & Player
Across our releases, we supported video encoding and decoding (with a player) based on either FFmpeg or Android's library as shown in this clip at 2:12 min mark.
Goal would be to
- Update general ffmpeg video decoding support
- Enhance ffmpeg video encoding support
- Potentially add better control about video-frame to framebuffer control for editing software
See related buglist
14 Total; 3 Open (21.43%); 11 Resolved (78.57%); 0 Verified (0%);
iOS Enhancements
Early iOS support has been demonstrated in 2019
Enhancing this port would allow to use JogAmp in a similar fashion as on Android, but using an OpenJDK iOS build.
Source Certification Contract (SCC)
| ID | Version | Product | Component | Priority | Severity | Status | Summary |
|---|---|---|---|---|---|---|---|
| 1368 | tbd | General | builds | P4 | normal | IN_PROGRESS | Source Certification Contract (SCC) |
| 1369 | 2.4.0 | Gluegen | core | P4 | normal | RESOLVED | SCC: Implement basic Secure Hash (SHA256) build time signatures & runtime validation |
2 Total; 1 Open (50%); 1 Resolved (50%); 0 Verified (0%);
OpenJFX
Bug report 607 describes different ways to either
- enhance external rendering via JOGL into an OpenJFX UI elements, or
- to replace OpenJFX's Glass w/ NEWT and Prism's OpenGL coding with JOGL
Misc
82 Total; 62 Open (75.61%); 19 Resolved (23.17%); 1 Verified (1.22%);