| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
and y is zero
|
|
|
|
| |
component.
|
| |
|
|
|
|
| |
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.
|