| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invPMv null; PMVMatrix: Make Mvi, Mvit optional at ctor, add user PMv and PMvi - used at gluUnProject() ..
Matrix4f.mapWin*() variants w/ invPMv don't need temp matrices,
they also shall handle null invPMv -> return false to streamline usage w/ PMVMatrix if inversion failed.
PMVMatrix adds user space common premultiplies Pmv and Pmvi on demand like Frustum.
These are commonly required for e.g. gluUnProject(..)/mapWinToObj(..)
and might benefit from caching if stack is maintained and no modification occured.
PMVMatrix now has the shader related Mvi and Mvit optional at construction(!), so its backing buffers.
This reduces footprint for other use cases.
The 2nd temp matrix is also on-demand, to reduce footprint for certain use cases.
Removed public access to temporary storage.
+++
While these additional matrices are on demand and/or at request @ ctor,
general memory footprint is reduced per default and hence deemed acceptable
while still having PMVMatrix acting as a core flexible matrix provider.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Utilize Vec3f, Recti, .. throughout API (Matrix4f, AABBox, .. Graph*)
Big Easter Cleanup
- Net -214 lines of code, despite new classes.
- GLUniformData buffer can be synced w/ underlying data via SyncAction/SyncBuffer, e.g. SyncMatrix4f + SyncMatrices4f
- PMVMatrix rewrite using Matrix4f and providing SyncMatrix4f/Matrices4f to sync w/ GLUniformData
- Additional SyncMatrix4f16 + SyncMatrices4f16 covering Matrix4f sync w/ GLUniformData w/o PMVMatrix
- Utilize Vec3f, Recti, .. throughout API (Matrix4f, AABBox, .. Graph*)
- Moved FloatUtil -> Matrix4f, kept a few basic matrix ops for ProjectFloat
- Most, if not all, float[] and int[] should have been moved to proper classes
- int[] -> Recti for viewport rectangle
- Matrix4f and PMVMatrix is covered by math unit tests (as was FloatUtil before) -> save
Passed all unit tests on AMD64 GNU/Linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for fair and realistic numbers - Both mul() ops faster than FloatUtil
Enhanced invert() of Matrix4f* and FloatUtil: Use 1f/det factor for burst scale.
Enhanced Matrix4f.invert(..): Use factored-out mulScale() to deliver the scale,
giving a good 10% advantage on aarch64 and amd64.
Brings Matrix4f.invert(..) on par w/ FloatUtil, on aarch64 even a 14% advantage.
+++
TestMatrix4f02MulNOUI added an additional Matrix4f.load() to the mul(Matrix4f) loop test,
which surely is an extra burden and not realistic as the mul(Matrix4f, Matrix4f) and FloatUtil
pendants also don't count loading a value.
Matrix4f.mul(Matrix4f) shall be used to utilize an already stored value anyways.
Matrix4f.mul(Matrix4f) didn't really exist in FloatUtil.
Same is true for Matrix4f.invert(), re-grouped order, i.e. pushing the non-arg variant last.
+++
Revised performance numbers from commit 15e60161787224e85172685f74dc0ac195969b51
AMD64 + OpenJDK17
- FloatUtil.multMatrix(a, a_off, b, b_off, dest) is considerable slower than all
- Matrix4f.mul(a, b) roughly ~10% faster than FloatUtil.multMatrix(a, b, dest)
- Matrix4f.mul(b) roughly ~18% faster than FloatUtil.multMatrix(a, b, dest) (*)
- Matrix4f.invert(a) roughly ~ 2% faster than FloatUtil.invertMatrix(..)
- Matrix4f.invert() roughly ~ 4% slower than FloatUtil.invertMatrix(..) (*)
- Launched: nice -19 scripts/tests-x64.sh
RaspberryPi 4b aarch64 + OpenJDK17
- FloatUtil.multMatrix(a, a_off, b, b_off, dest) is considerable slower than all
- Matrix4f.mul(a, b) roughly ~ 9% faster than FloatUtil.multMatrix(a, b, dest)
- Matrix4f.mul(b) roughly ~14% faster than FloatUtil.multMatrix(a, b, dest) (*)
- Matrix4f.invert(a) roughly ~14% faster than FloatUtil.invertMatrix(..)
- Matrix4f.invert() roughly ~12% faster than FloatUtil.invertMatrix(..) (*)
- Launched: nice -19 scripts/tests-linux-aarch64.sh
(*) not a true comparison in feature, as operating on 'this' matrix values
for one argument, unavailable to FloatUtil.
Conclusion
- Matrix4f.mul(..) is considerable faster!
- Matrix4f.invert(..) faster, esp on aarch64
And additional Matrix4fb tests using float[16] similar to FloatUtil
also demonstrates less performance compared to Matrix4f using
dedicated float fields.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ray, AABBox, Frustum, Stereo*, ... adding hook to PMVMatrix
Motivation was to simplify matrix + vector math usage, ease review and avoid usage bugs.
Matrix4f implementation uses dedicated float fields instead of an array.
Performance didn't increase much,
as JVM >= 11(?) has some optimizations to drop the array bounds check.
AMD64 + OpenJDK17
- Matrix4f.mul(a, b) got a roughly ~10% enhancement over FloatUtil.multMatrix(a, b, dest)
- Matrix4f.mul(b) roughly ~3% slower than FloatUtil.multMatrix(a, b, dest)
- FloatUtil.multMatrix(a, a_off, b, b_off, dest) is considerable slower than all
- Matrix4f.invert(..) roughly ~3% slower than FloatUtil.invertMatrix(..)
RaspberryPi 4b aarch64 + OpenJDK17
- Matrix4f.mul(a, b) got a roughly ~10% enhancement over FloatUtil.multMatrix(a, b, dest)
- Matrix4f.mul(b) roughly ~20% slower than FloatUtil.multMatrix(a, b)
- FloatUtil.multMatrix(a, a_off, b, b_off, dest) is considerable slower than all
- Matrix4f.invert(..) roughly ~4% slower than FloatUtil.invertMatrix(..)
Conclusion
- Matrix4f.mul(b) needs to be revised (esp for aarch64)
- Matrix4f.invert(..) should also not be slower ..
|
| |
|
| |
|
|
|
|
|
|
|
| |
its default. GraphUI: Always use default.
Graph RegionRenderer, its RenderState as well as GraphUI's Scene don't need to have knowledge of Vertex.Factory,
which is only used within OutlineShape and its 'inner geom workings'.
|
|
|
|
| |
API doc
|
|
|
|
| |
and destroys it. Dropping this also from user (complexity).
|
|
|
|
| |
GraphUI.Scene using RegionRenderer's viewport (no duplicate)
|
|
|
|
| |
explicitly to set the name upfront, clarifying workflow. Impl: ImageSequence + GLMediaPlayerImpl
|
|
|
|
|
|
| |
TextRegionUtil: Use pre-calc'ing buffer sizes for GLRegion;
TextRendererGLELBase: Fix temp AffineTransform usage
|
|
|
|
| |
allowing access w/o jars. TODO: Test Android.
|
|
|
|
| |
for easy deployment and test w/ junit/ant
|
|
|
|
|
|
|
|
|
|
| |
Root package is 'com.jogamp.graph.ui.gl', i.e. a sub-package of Graph denoting UI and OpenGL usage.
Implementation will stay small, hence relative files size costs are minimal.
Source and build is in parallel to nativewindow, jogl and newt
and has a dependency to all of them.
The NEWT dependencies are merely the input listener ..
|
|
|
|
| |
general functionality in UIShape (drag, ..)
|
| |
|
| |
|
|
|
|
| |
proper filenames for screenshots)
|
|
|
|
| |
Consider applying it in default chooser?
|
|
|
|
| |
modify values if text and/or font differs, skipping markShapeDirty() saves performance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
undesired (Graph VBAA + MSAA); Add NonFSAAGLCapabilitiesChooser
Notable: On RaspiPi4b w/ Mesa3D's Broadcom/VC driver,
the chosen capabilities is a multisamnple one even though not requested.
This causes
- extra performance overhead
- doubled AA: 1st our VBAA, then the FSAA (multisample) -> loss of sharpness
Simply dropping the undersired FSAA helps and ups performance
on the Raspi board (22 -> 35 fps).
|
|
|
|
|
|
|
|
|
|
| |
comparing the VisualID first; Added VisualIDHolder.isVisualIDSupported(VIDType)
We cannot accept 2 capabilities with different VisualID but same attributes otherwise accepted as equal,
since the underlying windowing system uniquely identifies them via their VisualID.
Such comparison is used in certail GLAutoDrawable implementations like AWT GLCanvas
to determine a configuration change etc.
|
|
|
|
| |
region, i.e. have a proper resolution independent layout.
|
|
|
|
| |
fit on small displays
|
|
|
|
| |
PC 'regioned' perf enhanced a little bit, for some reason the RPI performance went down a tiny bit (fluctuations?).
|
|
|
|
| |
TextRegionUtil.countStringRegion() allowing to use Region.setBufferCapacity()
|
|
|
|
| |
than enough
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used for getElemCount() instead of 0==position, ... (API change)
API Change
- sealed() moved up from GLArrayDataEditable -> GLArrayData
- GLArrayDataWrapper is sealed by default
- getSizeInBytes() -> getByteCount()
- Semantics of getElemCount() and getByteCount()
- Correctly use sealed() to switch from position to limit - instead of 0==position
Aligned method names:
- getElemCount()
- elemPosition()
- remainingElems()
- getElemCapacity()
to corresponding byte counts:
- getByteCount()
- bytePosition()
- remainingBytes()
- getByteCapacity()
|
|
|
|
| |
but recommended)
|
|
|
|
|
|
|
|
| |
Also tested w/ alternative JVM (Azul) .. works well, no big difference (but slower startup time, but might be OpenJDK 17->19 related as well).
Printing usual system infos to make the test record useful.
Cmdline is: com.jogamp.opengl.test.junit.graph.PerfTextRendererNEWT00 -es2 -Nperf -long_text -loop 40
|
|
|
|
|
|
| |
FPSCounterImpl accuracy by maintaining timestamps in [ns]
Idea: Perhaps we want to use [ns] for FPSCounter's method types by now?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performance-hit measuring performance.
This was mostly notable on a Raspberry-Pi 4 arm64, where perfromance degragated around 3x using high-freq counter.
Using our well determined Clock.currentNanos() removes this overhead,
back to 'easy measuring' and having a well defined 'currentNanos()' since module start.
TestTextRendererNEWT00 can enable Region and Font perf-counter w/ '-perf',
w/o it only uses its own counter and hence reduce the high-freq burden (64% perf win on raspi4).
+++
Below numbers show that Region.addOutlineShape() perhaps needs a little performance work
to allow long text to be processed in 'real time' on embedded platform.
Hower, usually we cache the Region for long text and can have at least one liner
to be renderer within 60fps fast, i.e. Region produced in ~26ms for a 81 char line
instead of ~130ms for 664 chars.
+++
Raspberry Pi 4b, OpenJDK17, Debian 11:
Using current medium sized text_1 w/ 664 chars, w/o '-perf'
and after having passed 40 frames, we have following durations:
- process the OutlineShape -> Region: 129ms (text)
- Render the Region: 53ms
Startup Times:
- loading GlueGen - loading test 0 [ms]
- loading GlueGen - start test 1,910 [ms]
- loading test - start test 1,910 [ms]
- loading test - gl 2,631 [ms]
- loading test - graph 2,636 [ms]
- loading test - txt 2,844 [ms]
- loading test - draw 3,062 [ms]
Perf ..
1 / 1: Perf Launch: Total: graph 5, txt 207, draw 218, txt+draw 425 [ms]
1 / 1: Perf Launch: PerLoop: graph 5,505,740, txt 207,530,736, draw 218,393,680, txt+draw 425,924,416 [ns]
20 / 20: Perf Frame20: Total: graph 16, txt 376, draw 281, txt+draw 657 [ms]
20 / 20: Perf Frame20: PerLoop: graph 807,055, txt 18,820,824, draw 14,075,146, txt+draw 32,895,970 [ns]
20 / 40: Perf Frame40: Total: graph 3, txt 129, draw 53, txt+draw 182 [ms]
20 / 40: Perf Frame40: PerLoop: graph 176,670, txt 6,451,330, draw 2,658,217, txt+draw 9,109,547 [ns]
+++
On a modern desktop (~2y old), GNU/Linux Debian 11, AMD GPU on Mesa3D:
Using current medium sized text_1 w/ 664 chars, w/o '-perf'
and after having passed 40 frames, we have following durations:
- process the OutlineShape -> Region: 42ms (text)
- Render the Region: 5ms
Startup Times:
- loading GlueGen - loading test 0 [ms]
- loading GlueGen - start test 310 [ms]
- loading test - start test 309 [ms]
- loading test - gl 459 [ms]
- loading test - graph 460 [ms]
- loading test - txt 490 [ms]
- loading test - draw 506 [ms]
Perf ..
1 / 1: Perf Launch: Total: graph 1, txt 29, draw 15, txt+draw 45 [ms]
1 / 1: Perf Launch: PerLoop: graph 1,191,096, txt 29,868,436, draw 15,519,445, txt+draw 45,387,881 [ns]
20 / 20: Perf Frame20: Total: graph 240, txt 68, draw 21, txt+draw 89 [ms]
20 / 20: Perf Frame20: PerLoop: graph 12,045,651, txt 3,415,402, draw 1,069,348, txt+draw 4,484,750 [ns]
20 / 40: Perf Frame40: Total: graph 283, txt 42, draw 5, txt+draw 47 [ms]
20 / 40: Perf Frame40: PerLoop: graph 14,152,395, txt 2,116,114, draw 265,292, txt+draw 2,381,406 [ns]
|
|
|
|
| |
Platform.currentTimeMillis()
|
|
|
|
| |
Clock.getMonotonicTime() ...
|
|
|
|
| |
PC and raspi-aarch64 ..
|
|
|
|
|
|
|
|
| |
newt.ws.mmwidth and newt.ws.mmheight property
This is essential on bare-metal devices where the screen DRM/GBM driver does not provide the screen-size (in mm).
Otherwise we would have resolution/(size_mm=0) infinity density and none of our graph font demos would work,
as we compute pixel-em-size based using dpi and pixel-pt-size.
|
|
|
|
| |
creation in other demos.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ease GLArrayData* buffer growth.
Using integer indices, i.e. GL_UNSIGNED_INT, requires us to pass a GLProfile 'hint' to the GLRegion ctor.
Region.max_indices is computed in this regard and used in Region.addOutlineShape().
TODO: If exceeding max_indices, the code path needs some work.
Buffer growth is eased via GLArrayData using its golden growth ratio
and manually triggering growth before processing all triangles in Region.addOutlineShape().
+++
TextRegionUtil static drawText() won't clear passed Region anymore, caller has to do this if so intended.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
finalize immutables, add growthFactor (default golden ratio 1.618), add getCapacity*() and printStats(..)
The growthFactor becomes essential for better growth behavior and can be set via setGrowthFactor().
The other changes were merely to clean up the GLArrayData interface and its 4 implementations.
Not great to change its API, but one name was misleading ['getComponentCount' -> 'getCompsPerEleme'],
so overall .. readability is enhanced.
Motivation for this change was the performance analysis and improvement of our Graph Curve Renderer.
|
|
|
|
| |
test-shapes
|
| |
|
|
|
|
| |
lineGap, document them properly and fix Font.getLineHeightFU()
|
|
|
|
| |
complex example code, ascending
|
|
|
|
| |
and winToObjCoord (expect all set, no doubling); GLEventListenerButton: Resize FBO to screen-size for proper 1:1 quality
|
| |
|
|
|
|
| |
sizes a little
|
|
|
|
| |
GPUUISceneGLListener0A: Formatting and move reshape() after init()
|
| |
|