| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
jaulib, i.e. drop 0==epsilon case for performance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
between rendering & input-edt, use synchronized tripple-buffering
Tripple-buffering _almost_ produces zero data-race collisions,
however .. it still does rarely -> hence synchronize on the used ArrayList<>.
This adds a minimal chance for blocking the input-EDT,
but gives correct code & results.
Double-buffered 'renderedShapes' was introduced to resolve Bug 1489
in commit 5f9fb7159fa33bc979e5050d384b6939658049bd
This solution is tested by passing '-swapInterval 0' via CommandlineOptions for FontView01, UIMediaGrid01 ..,
i.e. rendering faster than picking and hence provoking the data-race condition.
|
| |
|
| |
|
|
|
|
| |
in demo text
|
| |
|
|
|
|
| |
This doesn't bring reliable results for Graph and also is pretty expensive.
|
|
|
|
|
|
|
|
| |
FloatUtil.EPSILON epsilon and no collinear test
commit 5488665474cc7b88577cedfca6416784f0fda3ba Generalize *seg2segIntersection* w/ epsilon and doCollinear
caused a big performance hit about 1/3 due to added doCollinear case and manual epsilon adding branches
and having the method being longer - probably not 'hotspot'ed.
|
| |
|
|
|
|
|
|
| |
toggle OutlineShape's isComplex() for visibility
We may use complex for other criteria than !convex, i.e. self-intersecting etc.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
a zero epsilon value to reduce complexity in upper math layers
|
|
|
|
| |
passing FloatUtil.EPSILON to explicit isZero(a, epsilon)
|
|
|
|
| |
non-convex treatment to simplify debugging etc
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and non-circulcircle triangulation candidates in our Delaunay tessellator
<https://jogamp.org/bugzilla//show_bug.cgi?id=1501#c6>
The used Delaunay tessellation works well with (almost) convex shapes.
In case e.g. a glyph gets to the extremes like 'M' in FreeMono
or any other complex Chinese symbol - it may just simply happen
that the new non-circumcircle triangle point crosses the inner (hope)
or outer boundaries of the given polygon.
Applying further constraint at Loop.cut() resolves most cases
by rejecting the proposed CCW and non-circumcircle triangle candidate
if its new two line-segments intersects with the original polygon.
This results in mostly proper rendered Chinese fonts and also
FreeMono is now readable - overal remaining bugs in Glyphs is low.
+++
Of course, this intersection test is costly around >= O(log(n)*n) costs,
practically adding a measured ~65% processing time.
E.g. for FontView01 using FreeSerif.ttf
- orig total took 1430.817638ms, per-glyph 0.2236ms, glyphs 6399
- fix total took 2377.337359ms, per-glyph 0.371517ms, glyphs 6399
Pure Glyph/Shape instantiation shows > 2x costs:
750 ms 100% convex (fake)
1875 ms 0% convex (fake)
1870 ms 13% convex 824/6399
+++
Hence it is desired to either
(1) Manually mark a polygon non-convex to add described intersection test for accuracy.
Also may be used to just drop the additional costs despite the lack of correctness.
PROVIDED
(2) Determine non-convex nature of a polygon with a and overall less expensive algorithm.
If considerably cheaper, this could reduce O(log(n) * n) -> O(n) or even O(log n).
Added convex/non-convex classification while ignoring off-curve points,
but only ~13% of FreeSerif is pure convex,
hence there is no benefit with this classification type.
It might be desired to attempt other classes, i.e.
being rendered in non-convex mode w/o intersection tests.
See
- GENERALIZED DELAUNAY TRIANGULATIONS OF NON-CONVEX DOMAINS
https://deepblue.lib.umich.edu/bitstream/handle/2027.42/28782/0000614.pdf;sequence=1
- https://en.wikipedia.org/wiki/List_of_self-intersecting_polygons
- https://en.wikipedia.org/wiki/Complex_polygon
|
|
|
|
|
|
|
|
|
|
|
| |
new impl; Add isConvex*() to determine whether a polyline is convex
I had problems using the previous line2line intersection methods in my (and my son's) C++ gfxbox2 project, e.g. freefall01.
Hence I found a different solution, also using less operations:
<https://jausoft.com/cgit/cs_class/gfxbox2.git/tree/include/pixel/pixel2f.hpp#n660>
While adding intersection tests for our Delaunay (Bug 1501) .. I came across this issue again
and hence swapped the implementation.
|
| |
|
|
|
|
|
|
| |
capability for code injection to render
Besides the one-shot on-init functionality, this allows us to re-render the shape differently.
|
|
|
|
| |
VBORegionSPES2 to just render lines instead of the filled area -> Used in UIShapeDemo02a
|
|
|
|
| |
setHintMask()->setHintBits(), clearHintMask()->clearHintBits()
|
| |
|
|
|
|
| |
*2d() variants
|
| |
|
|
|
|
| |
winding direction (outer-bondary TTF CW (Graph CCW) and inner-hole TTF CCW (Graph CW)
|
|
|
|
|
|
|
|
|
|
|
| |
inner-hole:=CW w/o using winding determination (might be incorrect)
This simplifies our code further and it has been validated that our polygon shoelace-algo for area >= 0 ? CCW
doesn't produce correct results with all curves.
Hence rely on given winding depending on outer-boundary and inner-hole if CDTriangulator2D.FixedWindingRule == true (default and fixed).
This also removes the more costly winding shoelace calculus,
hence Outline ctor only sets dirtyWinding:=true w/o calculating the winding.
|
|
|
|
| |
tessellation issue / or use Glyph03FreeMonoRegular_M
|
|
|
|
|
|
|
|
|
|
|
|
| |
version, overcome float precision; Loop: Pass edgeType not Winding, simplify findClosestValidNeighbor() -> isValidNeighbor(); CDTriangulator2D.addCurve() enforces Winding.CCW on BOUNDARY null == loop case
Add double version of triAreaVec2() and isInCircleVec2() in VectorUtil, overcoming float precision limits
- Analysis exposed float precision limits within isInCircleVec2()
Loop: Pass edgeType not Winding, simplify findClosestValidNeighbor() -> isValidNeighbor()
- Enhance code clarity
CDTriangulator2D.addCurve() enforces Winding.CCW on BOUNDARY null == loop case
|
| |
|
|
|
|
|
|
|
| |
demos utilize lots of smaller resources regions ...
.. and this also brings us to the next required task: Resolve AA w/o supersampling right in our shader,
which is very well possible when extending the tessellated outline triangle's area.
|
|
|
|
| |
time-string and still-images (optional) .. using HUDShape
|
|
|
|
| |
using inner object size/pos, similar like TooltipShape
|
| |
|
|
|
|
| |
position + NEWT MouseEvent to listener, renamed {Slider->Change}Listener and add PeekListener for mouse-over events
|
| |
|
|
|
|
| |
requires pause state (normal at play-state)
|
| |
|
|
|
|
| |
and subtitle language
|
|
|
|
|
|
|
|
|
|
|
| |
for experimental occlusion-culling
TreeTool's cullShapes(), actually a naive dumm occlusion test (*RENAME IT*),
would need to realize whether the shape/groups actually cover shapes below,
i.e. are not on same Z-Axis and transparent.
Hence, this is disabled in code and we rely on the Z buffer still,
just an idea ..
|
|
|
|
|
|
|
|
|
|
|
| |
simplify and reduce runtime costs
Refines commit 43a7899fedf2a570d20b03848bf15710f30b7f26
Scene handles top-level active state via releaseActiveShape() and setActive(),
now calling into setActiveTopLevel() -> dispatchActivationEvent().
Drop child's addActivationListener(forwardActivation) and isActive() override.
|
|
|
|
| |
ctrlBlend) to remove the occlusion by the blending box
|
|
|
|
| |
dropping UIMediaGrid00
|
|
|
|
| |
Pre/Next Buttons; Toggle HUD head info box (full or brief)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Order, testing Children and fallback to Group if positive
Picking algo in Z-Ascending order worked only by chance, as it picked up any bottom node.
+++
Proper algo is in Z-Descending order to block occluded (child) nodes:
for-all s : shapes
p1 = testPicking(s)
if ( s is Container ) {
p2 = testPicking(s.childs)
if( null != p2 ) {
p1 = p2; // override w/ child prio
}
}
return p1
}
Further, testPicking(shape) shall only return a positive shape,
if the event dispatching check (mouse-over, click, ..)
signals end-of-traversal - as originally intended.
Overall philosophy is to pick the 'deepest' child of a group
if responding, otherwise the next higher interactive group.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
where its zOffset gets adjusted when activated..
.. instead of having a non-working complicated callback orgy setup.
This also takes away the getAdjustedZ() overloading burden (or better uglyness) etc.
Hence Group's setWidgetMode(boolean) became:
- enableTopLevelWidget(Scene)
- disableTopLevelWidget()
The forwardActivation listener is still applied to all children
as well as isActive() is also still overloaded for same required behavior.
However, none of the children is set in 'widget mode'
as well as the Group is simply added to (or removed from)
the Scene's top-level Group list - the holder.
Scene's setActiveShape(Shape) and releaseActiveShape()
handle the top-level Group if affected,
i.e. adding or zero'ing its ZOffset.
|
|
|
|
| |
code.
|