| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
behavior to BoxLayout and GridLayout.
For all:
- Padding is applied to each {@Shape} via {@link Shape#setPaddding(Padding)} if passed in constructor
BoxLayout:
- Optionally centered {@link Alignment.Bit#CenterHoriz horizontally}, {@link Alignment.Bit#CenterVert vertically} or {@link Alignment#Center both}.
- Optionally scaled to cell-size if given and {@link Alignment#Fill}
- Margin is ignored on dimension with center {@link Alignment}
- Not implemented {@link Alignment}: Top, Right, Bottom, Left
GridLayout:
- Optionally centered {@link Alignment.Bit#CenterHoriz horizontally}, {@link Alignment.Bit#CenterVert vertically} or {@link Alignment#Center both}.
- Optionally scaled to cell-size if given and {@link Alignment#Fill}
- Without cell-size behaves like a grid bag using individual shape sizes including padding
- Can be filled in {@link Order#COLUMN} or {@link Order#ROW} major-order.
- Not implemented {@link Alignment}: Top, Right, Bottom, Left
Changes to Group.Layout interface:
- Added preValidate(Shape) allowing to prepare the shape before validation, used to inject Padding
Changes to Margin:
- Removed the complex CENTER property and using Alignment in BoxLayout as well
Changes to BoxLayout:
- Using Alignment
+++
Tested via UILayoutBox01 and UILayoutGrid01,
try the tooltip by clicking on the group's description label.
|
|
|
|
| |
Scene but manual GLEventListener etc, add a few Glyph tests
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
glyphSymbol number, mouse-wheel scrolling, Fitting the font info, ..
- Add mouse-wheel scrolling, for one-line and with control for one page.
- Add left-column glyphSymbol number, for orientation while scrolling
- Fitting the font info, i.e. consider width + height
Refactoring further isolated the addGlyphs(..) functionality in same method, etc.
Used to test Graph's capabilitry to properly read, detect and visualize certain fonts.
Previous Graph fixes were triggered by this procedure,
i.e. commits
- 733cc5272cfed10fa07b707e29fd756f44581508
- 920e529516bb264f04138ed1caca80d4925e3773
- 7fd51917b0cc85c3dc3d07592093a62b213d1ea5
Further the proper detection of non-contour/whitespace
allows FontView to skip them and only show usably Glyphs without noise.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
providing sets of animated Shapes (GlyphShape or any other)
Hardcoding the whole animation process into user code is not feasible to allow a quick add-on.
GraphUI's new AnimGroup is a Group and allows to add multiple AnimGroup.Set of AnimGroup.ShapeData.
+++
AnimGroup.ShapeData holds the actual Shape and its start- and target position
as well as its active animation state and an optional user object attachment.
AnimGroup.Set holds a list of AnimGroup.ShapeData as well as the animation properties
and states like acceleration and velocity for translation and angular operations.
It also contains the AnimGroup.LerpFunc for linear interpolation of the next position
as called via AnimGroup.tick() over all sets.
AnimGroup.LerpFunc is intended to perform the linear interpolation for the next position,
either user provided or one of the provided may be used, i.e. TargetLerp, ScrollLerp and SineLerp.
To setup the start- and target position for each AnimGroup.ShapeData,
a AnimGroup.ShapeSetup is used - user implementated or one of the build-in
of AnimGroup.addGlyphSetHorizScroll01(..), AnimGroup.assGlyphSetRandom01(..).
+++
UISceneDemo03 consolidated UISceneDemo03 + UISceneDemo03b (deleted)
and shows the following AnimGroup capabilities:
- Two repetitive scrolling text lines. One text shorter than the line-width and one longer.
- One line of animated rectangles, rotating around their z-axis
- A text animation assembling one line of text,
each glyph coming from from a random 3D point moving to its destination all at once including rotation.
- One line of text with sine wave animation
|
|
|
|
| |
tests for now
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLEventListener.reshape(..) when re-adding GLJPanel
When re-adding GLJPanel on Windows glViewport()
is not called through
- GLJPanel.Updater.display()
- GLDrawableHelper.reshape()
- GLDrawableHelper.setViewportAndClear()
Instead the following sequence is called due to sendReshape == false:
- GLJPanel.Updater.display()
- GLDrawableHelper.display() ** missing glViewport(..) **
This bug is not visible on X11 or MacOS since the glViewport
is only set to a different user value on Windows ...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Install Homebrew https://brew.sh/
> /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Follow further directions...
Install FFmpeg (Currently v6) https://formulae.brew.sh/formula/ffmpeg
> brew install ffmpeg
or
> brew install fmpeg@6
Leaves the ffmpeg libraries in:
- x86_64: /usr/local/Cellar/ffmpeg/6.0/lib
- aarch64: /opt/homebrew/Cellar/ffmpeg/6.0/lib
|
| |
|
| |
|
|
|
|
| |
shall handle null streamWorker, i.e. when using NullGLMediaPlayer
|
| |
|
|
|
|
| |
glMultiDrawElementsIndirect shall only have VBO indirect access
|
| |
|
|
|
|
| |
projection settings
|
| |
|
|
|
|
|
|
|
| |
Validated GLMediaPlayer ...
Validated GLMediaPlayer w/ new AudioSink
and channels > 2 for ALAudioSink with openal-soft > 1.18 (w/o AL_SOFT_buffer_samples).
|
|
|
|
| |
270172bcbd91f96d4a38a3d73e23d744f57a25b8) and joal (commit 03f4bb63ce8a358b1c2ef303480e1887d72ecb2e)
|
|
|
|
|
|
|
|
|
|
|
| |
have AWT toolkit define pixelScale only (simplification)
This aligns with Glenn's initial AWT patch commit e5e7514d649cd7dd28bbb8e04b72338dc09c2c83, i.e. removing redundancies...
Tested on Linux, Windows and MacOS w/ GLCanvas, GLJPanel and GLWindow using pixelScale values:
- Linux: 1, 2
- Windows: 1, 1.25, 2
- MacOS: 1, 2
|
|
|
|
| |
propagated properly to our AWT GLCanvas and NEWT
|
|
|
|
| |
blocking native change by monitor-pixelScale (Windows, X11)
|
| |
|
|
|
|
| |
threads', allowing C++ std::mutex etc to be used (openal-soft)
|
| |
|
|
|
|
| |
Padding and alignment (Margin?) (CSS alike)
|
|
|
|
| |
FontView01 demos) rendering a grid of each glyph for better validation for many fonts and renderModes/sampleCount
|
|
|
|
| |
FontForge' ;-)
|
|
|
|
|
|
|
|
|
|
| |
UISceneDemo20 with button Groups
All layout magic is simply performed in Group.Layout.layout(..) @ validate, incl. updating the
bounding box to have the padding included.
This demonstrates GraphUI's capability to be used with correct layout,
i.e. its pure matrix based position, scale and rotation.
|
|
|
|
| |
and w/ scroll-wheel (or zoom if alt is pressed)
|
|
|
|
|
|
| |
as well as getSurfaceSize(..) (use absolute size)
Tested w/ UISceneDemo01b and UISceneDemo03, where you now can pick any moving glyph at any rotation and drag it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
traversing the PMVMatrix throughout childs (-> see TreeTool).
Utilizing the Vec*f (and Matrix4f) API w/ AABBox et al renders our code more clean & safe,
see commit 15e60161787224e85172685f74dc0ac195969b51.
A Group allows to contain multiple Shapes,
hence the PMVMatrix must be traversed accordingly using TreeTool
for all operations (draw, picking, win->obj coordinates, ..).
Hence Scene + Group are now implementing Container
and reuse code via TreeTool and a Shape.Visitor*.
This will allow further simplification of user code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use w/ UISceneDemo03 Type Animation...
A list of GlyphShape can be created via GlyphShape.processString(..),
which preserves all details incl. intended original unscaled position and its kerning.
Whitespace or contourless Glyphs are dropped.
A GlyphShape is represented in font em-size [0..1] unscaled.
+++
UISceneDemo03 Type Animation
- Using GlyphShape and apply scaling via its Shape.setScale()
- Recalc fontScale per used text
- Refined 'arrival' criteria and smoothing out near target w/ speed-up rotation
- Using GraphUIDemoArgs to parse common commandline demo options
|
|
|
|
| |
Graph/GLRegion
|
| |
|
|
|
|
| |
launcher to our new UISceneDemo naming series
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Contrary to UISceneDemo0[01], here we
- Call the Scene GLEventListener methods manually
- Issue glClear* ourselves
- Using own PMVMatrixSetup
- gluPerspective like Scene's default
- no normal scale to 1, keep distance to near plane for rotation effects. We scale Shapes
- translate origin to bottom-left
- Scale Button not by screen-size but Scene.getBounds() dimension,
hence issue setupUI() from reshape() and not from init()
- GLButton: Using additional view-rotation like UISceneDemo01
- Multi-line text labels resize issues are
- Supposed sticky-edge is moving
(Sticky-edge are the opposites of the picked drag point)
|
|
|
|
| |
UISceneDemo01 simply provides shape drag-move and -resize
|
|
|
|
| |
clean)
|
|
|
|
| |
API doc
|
| |
|
| |
|
|
|
|
| |
not testing using jars but classpath)
|
|
|
|
| |
bottom-left or bottom-right corner. Rename translate -> position.
|
|
|
|
| |
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 ..
|