|
|
| Line 1: |
Line 1: |
| This list exposes building blocks
| | Extracted from [[SW Tracking Report Feature Objectives Overview|Feature & Objectives]]. |
| for potential use and business case scenarios
| |
| using Java & JogAmp on Desktop and Embedded Devices.
| |
|
| |
|
| Notably [[#Graph|Graph & Graph UI]] as well as [[#NEWT_+_Wayland|Wayland]] & [[#Vulkan|Vulkan]] support could be of interest here?
| | = Overview = |
| | |
| Also see [[Completed Features Objectives]] ...
| |
| | |
| = Graph =
| |
| [https://jausoft.com/blog/tag/graph_type_rendering/ 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 [https://jausoft.com/blog/2024/01/21/graphui-frustum-culling-clipping-modelview-space/ 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)
| |
| ** [https://jausoft.com/blog/2024/02/13/fixing-jogamps-graph-delaunay-tessellation-of-complex-non-convex-shapes/ First round done]
| |
| * 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)
| |
| * <s>Add subtitles in MediaPlayer GraphUI widget</s> ''([https://jausoft.com/blog/2024/02/07/graphui-mediaplayer-feature-complete/ 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 [[Maintainer_and_Contacts#Commercial_Support|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 [https://jogamp.org/bugzilla/show_bug.cgi?id=1505#c0 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 [https://jogamp.org/bugzilla/show_bug.cgi?id=1404 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:
| |
| | |
| <pre>
| |
| --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
| |
| </pre>
| |
| | |
| === OpenJDK >= 2x ===
| |
| | |
| See [https://jogamp.org/bugzilla/show_bug.cgi?id=1505 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:
| |
| | |
| <pre>
| |
| --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
| |
| </pre>
| |
| | |
| == Graph UI ==
| |
| | |
| [https://jausoft.com/blog/2023/02/22/reimagine-java-on-desktop-bare-metal-devices/ ''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 [https://jausoft.com/blog/2011/10/05/jogljogamp-red-square-moscow-nurbs-graphicon2011/ Resolution Independent NURBS Curves Rendering using Programmable Graphics Pipeline], i.e. rendering curves directly on the GPU, resolution independent [ [https://jogamp.org/doc/gpunurbs2011/p70-santina.pdf paper], [https://jogamp.org/doc/gpunurbs2011/graphicon2011-slides.pdf 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 [{{SERVER}}/bugzilla/show_bug.cgi?id=1156 DRM/GBM as support by JOGL(EGL) and NEWT]
| |
| as demonstrated [https://ict.zafena.se/improved-graphical-information-technology/ by Xerxes on a Raspberry Pi4].
| |
| | |
| [https://jausoft.com/blog/2023/02/22/reimagine-java-on-desktop-bare-metal-devices/ Reimagine Java on Desktop & Bare-Metal Devices]
| |
| demonstrates the updated Graph Curve Rendering and UI, while [https://jausoft.com/blog/2024/01/21/graphui-frustum-culling-clipping-modelview-space/ this update shows clipping and widgets]. [https://jausoft.com/blog/tag/graph_type_rendering/ 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
| |
| : [{{SERVER}}/bugzilla/showdependencytree.cgi?id=803&hide_resolved=0 Dependency Tree]
| |
| : [{{SERVER}}/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cversion%2Cshort_desc%2Cchangeddate&component=core&component=Plugin&list_id=2265&product=GraphUI&query_format=advanced&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED All GraphUI]
| |
| | |
| ;Open Items ''graphui''
| |
| <bugzilla>
| |
| {
| |
| "status":["IN_PROGRESS","CONFIRMED", "UNCONFIRMED"],
| |
| "product":"graphui",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
| | |
| ;Completed Items ''graphui''
| |
| <bugzilla>
| |
| {
| |
| "status":["RESOLVED","VERIFIED"],
| |
| "product":"graphui",
| |
| "include_fields":"id,version,product,component,status,resolution,summary"
| |
| }
| |
| </bugzilla>
| |
| | |
| == Jogl / Graph ==
| |
| | |
| [{{SERVER}}/bugzilla/showdependencytree.cgi?id=1064&hide_resolved=0 Dependency Tree Graph Font Issues]
| |
| | |
| [{{SERVER}}/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cversion%2Cshort_desc%2Cchangeddate&component=graph&list_id=2264&product=Jogl&query_format=advanced&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED All Jogl Graph]
| |
| | |
| ;Open Items ''Jogl / graph''
| |
| <bugzilla>
| |
| {
| |
| "status":["IN_PROGRESS","CONFIRMED", "UNCONFIRMED"],
| |
| "product":"jogl",
| |
| "component":"graph",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
| | |
| ;Completed Items ''Jogl / graph''
| |
| <bugzilla>
| |
| {
| |
| "status":["RESOLVED","VERIFIED"],
| |
| "product":"jogl",
| |
| "component":"graph",
| |
| "include_fields":"id,version,product,component,status,resolution,summary"
| |
| }
| |
| </bugzilla>
| |
| | |
| = WebAssembly (wasm) Target Platform =
| |
| | |
| == Overview ==
| |
| See [https://jogamp.org/bugzilla//show_bug.cgi?id=1506 Bug 1506] describing this feature. | | See [https://jogamp.org/bugzilla//show_bug.cgi?id=1506 Bug 1506] describing this feature. |
|
| |
|
| Line 165: |
Line 18: |
| 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. | | 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 ==
| | = Initial C++/wasm Evaluation = |
| [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ Our little gfxbox2 games] compiled to [https://webassembly.org/ 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). | | [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ Our little gfxbox2 games] compiled to [https://webassembly.org/ 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). |
|
| |
|
| Line 177: |
Line 30: |
| to the browser these days, a feasible procedure. | | to the browser these days, a feasible procedure. |
|
| |
|
| == Java Support ==
| | = Java Support = |
| Java support for the WebAssembly target are claimed to be supported by | | Java bytecode compiler to wasm including some ''runtime envelop'' |
| * [https://github.com/i-net-software/JWebAssembly JWebAssembly] | | * [https://github.com/konsoletyper/teavm TeaVM] [https://teavm.org/docs/intro/overview.html overview] |
| * [https://github.com/konsoletyper/teavm TeaVM]
| | * [https://github.com/i-net-software/JWebAssembly JWebAssembly] [https://github.com/i-net-software/JWebAssembly/wiki doc] |
| * [https://mirkosertic.github.io/Bytecoder/ Bytecoder] | | * [https://mirkosertic.github.io/Bytecoder/ Bytecoder] |
|
| |
|
| Further interesting bits & pieces | | Further interesting bits & pieces |
| ** [https://openjdk.org/jeps/457 JEP 457: Class-File API ]
| | * [https://openjdk.org/jeps/457 JEP 457: Class-File API ] |
| ** [https://openjdk.org/projects/babylon/articles/linq Babylon]
| | * [https://openjdk.org/projects/babylon/articles/linq Babylon] |
| | * [https://github.com/google/j2cl/blob/master/docs/getting-started-j2wasm.md J2wasm] within [[https://github.com/google/j2cl J2CL] emits very naïve Wasm using the text format and it relies on Binaryen toolchain to assemble, link, and optimize |
| | ** [https://www.wingolog.org/pub/epfl-wasm-gc-feb-2024-slides.pdf 2024 Slides] |
|
| |
|
| | == GraalVM == |
| 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. |
|
| |
| * [https://www.graalvm.org/latest/reference-manual/wasm/ GraalVM + wasm] | | * [https://www.graalvm.org/latest/reference-manual/wasm/ GraalVM + wasm] |
| ** with the help of emscripten | | ** with the help of emscripten |
| ** [https://www.graalvm.org/22.0/reference-manual/native-image/JNI/ GraalVM + JNI] | | ** [https://www.graalvm.org/22.0/reference-manual/native-image/JNI/ GraalVM + JNI] |
|
| |
|
| == Java Browser Outlook ==
| | [https://github.com/oracle/graal/issues/3391 Request for enhancement about wasm target in GraalVM]. |
| | |
| | = 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. | | 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. | | 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 =
| |
|
| |
| * [{{SERVER}}/bugzilla/showdependencytree.cgi?id=807&hide_resolved=0 Dependency Tree NEWT Input Devices]
| |
| * [{{SERVER}}/bugzilla/showdependencytree.cgi?id=814&hide_resolved=0 Dependency Tree NEWT Pointer Event]
| |
|
| |
| <bugzilla>
| |
| {
| |
| "product":["newt","jinput"],
| |
| "version":["2.5.0","3.0.0","tbd"],
| |
| "cf_type":"FEATURE",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
|
| |
| = 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
| |
| [https://jogamp.org/bugzilla/show_bug.cgi?id=1156 bare metal devices w/o a windowing system via the Linux DRM/GBM console mode]
| |
| throughout JOGL + NEWT.
| |
|
| |
| = Vulkan =
| |
|
| |
| <bugzilla>
| |
| {
| |
| "component":"vulkan",
| |
| "cf_type":"FEATURE",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
|
| |
| = 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 [https://youtu.be/4gWStKCioi8?t=132 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 [https://jogamp.org/bugzilla//buglist.cgi?bug_status=__open__&component=video&list_id=3053&product=Jogl related buglist]
| |
|
| |
| <bugzilla>
| |
| {
| |
| "component":"video",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
|
| |
| = iOS Enhancements =
| |
|
| |
| Early iOS support has been demonstrated in 2019
| |
| * [https://jausoft.com/blog/2019/06/17/jogamp-ios-arm64-bring-up/ iOS Arm64 bring-up]
| |
| * [https://jausoft.com/blog/2019/06/23/jogamp-ios-arm64-port-first-visuals/ iOS Arm64 Port: First Visuals]
| |
| * [https://jausoft.com/blog/2019/07/08/jogamp-ios-arm64-port-newt/ iOS Arm64 Port: NEWT]
| |
|
| |
| Enhancing this port would allow to use JogAmp in a similar fashion as on Android,
| |
| but using an OpenJDK iOS build.
| |
|
| |
| = [[SCC Overview|Source Certification Contract (SCC)]] =
| |
|
| |
| [{{SERVER}}/bugzilla/showdependencytree.cgi?id=1368&hide_resolved=0 Dependency Tree]
| |
|
| |
| [{{SERVER}}/bugzilla/show_bug.cgi?id=1368 Root Parent Entry]
| |
|
| |
| <bugzilla>
| |
| {
| |
| "id":["1368", "1369"],
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
|
| |
| = OpenJFX =
| |
|
| |
| [https://jogamp.org/bugzilla//show_bug.cgi?id=607#c20 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 =
| |
|
| |
| <!-- bugzilla>
| |
| {
| |
| "product"!=["graphui","newt"],
| |
| "component"!=["graph","vulkan"],
| |
| "version":["2.5.0","3.0.0","tbd"],
| |
| "cf_type":"FEATURE",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla-->
| |
|
| |
| <bugzilla>
| |
| {
| |
| "version":["2.5.0","3.0.0","tbd"],
| |
| "cf_type":"FEATURE",
| |
| "include_fields":"id,version,product,component,priority,severity,status,summary"
| |
| }
| |
| </bugzilla>
| |
Extracted from Feature & Objectives.
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 bytecode compiler to wasm including some runtime envelop
Further interesting bits & pieces
GraalVM
GraalVM experimentally hosts wasm only,
but is not producing a wasm target for the wasm (browser) runtime.
Request for enhancement about wasm target in GraalVM.
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.