[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6886358: layout code update
Changeset: 1d4340015b85 Author:srl Date: 2010-12-06 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1d4340015b85 6886358: layout code update Reviewed-by: igor, prr ! make/sun/font/FILES_c.gmk ! src/share/classes/sun/font/FontUtilities.java ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h + src/share/native/sun/font/layout/HangulLayoutEngine.cpp + src/share/native/sun/font/layout/HangulLayoutEngine.h - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h + src/share/native/sun/font/layout/ICUFeatures.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h + src/share/native/sun/font/layout/TibetanLayoutEngine.cpp + src/share/native/sun/font/layout/TibetanLayoutEngine.h + src/share/native/sun/font/layout/TibetanReordering.cpp + src/share/native/sun/font/layout/TibetanReordering.h + test/java/awt/font/TextLayout/TestOldHangul.java +
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hi Denis,
On 12/6/2010 4:21 PM, Denis Lila wrote:
Hi Jim.
line 134 - what if numx or numy == 0 because only roots outside [0,1]
were found?
In this case lines 151-162 will execute, and nothing is wrong. The only
problem is when both numx and numy are 0. This is certainly possible in
the general case (but only with quadratic curves), but the way we're using
this function, the intermediate value theorem guarantees at least one root
will be found. Of course, finite precision math doesn't necessarily care
what calculus has to say, but in this case I can't see how the root computation
could fail. On the other hand, one could argue that this is exactly why we need
to defend against this case, so I've added some checks.
I'm sure you will likely find a root, but the method you are using is
roots*inAB* which may throw the root out because it is out of range, no?
In looking at that method it looks like the cubic handling code tries 0
and 1 in addition to the critical points it finds using a root, but the
quadratic code that it chooses if a==0 will throw out all roots outside
the 0,1 range and may end up with 0 answers. The cubic code further can
reject all of the points (if they are all non-zero and same sign) and
also return no answers, but may have fewer cases where it would do that.
Still, my point was not that you might fail to find a root, but that the
roots may get rejected and end up with no answers in range.
line 145 - what if d0 and d1 are both 0? NaN results. What if you
just used a simple d0 d1 ? tx : ty - how far off would that be?
I tried that out on a curve with very high acceleration, and it makes a
noticeable
difference. So, instead I'm using
if (w0 == Float.NaN) {
return tx;
}
Read the IEEE spec on NaN. It's a special value that has this bizarre
property that it is the only number that is not equal to itself. ;-) In
fact, the test for NaN is usually if (x == x) notNaN else NaN. If
you want to be explicit and formal then you can use the static
Float.isNaN() method (which is essentially that test - x!=x).
Same thing on Dasher line 363 where you also test for NaN.
line 357 - another optimization would be to check the acceleration in
the range and if it is below a threshold then simply use the t from
line 348 as the t for the split
I like this. I tried implementing it. I haven't tested it yet though, and
I still have to pick a good cutoff acceleration. For now I'm using 1/leaflen.
We definitely don't want it to just be a constant, since the longer the leaf,
the worse it will be to allow acceleration, so for longer leaves we want to
skip the getTCloseTo call only if the acceleration is smaller.
A lot of the lines before you test MaxAcc are not needed unless you go
into the if. In particular, x,y,[xy][01] are only used if you call
getTCloseTo().
Renderer.java: Is this just a straight copy of what I was working on?
I'm pretty sure it is, yes.
Actually I think you've updated the AFD code so I should really take a
look... :-(
;-)
TransformingPathConsumer2D:
Any thoughts on whether we need translation in the scale filter and
whether a 4-element non-translation filter would be useful? I think
the current code that drives this passes in the full transform and its
inverse, but it could just as easily do delta transforms instead and
save the adding of the translation components...
I thought about this long ago, but I wasn't sure it wouldn't break anything.
Today, I got a bit more formal with the math, and I think it's ok
to eliminate the translation. I've implemented this (though, I haven't had
time to test it yet. That's for tomorrow).
Right now you have (note that the common terminology for transform
without translation is delta transform):
PathIterator
= DeltaAT = Normalize
= DeltaInverseAT = strokers
= FullAT = renderer
The problem is that normalization needs proper sub-pixel positioning so
you need to hand it the true device space coordinates with proper
translation. You need this:
PathIterator
= FullAT = Normalize
= DeltaInverseAT = strokers
= DeltaAT = renderer
I would skip the creation of atNotTranslationPart and just inverse the
original transform (since I don't think the inversion is affected by
translation - you can see this in the calculations in
AT.createInverse()), and then have the transforming consumers apply a
delta transform - i.e. create a TPC2D.deltaTransformConsumer() method
which would apply just the non-translation parts of AT to the consumer.
If you want to get really fancy with optimizations you could have an
inverseDeltaTransformConsumer() method that would calculate the
inversions on the fly to avoid construction of a scratch AT. Since it
is just weird transpose with signs and divide by the determinant in
the most general case and even simpler (invert Mxx
[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6775317: Improve performance of non-AA transformed rectangles and single wide lines in software pipelines
Changeset: 47cd69eff641 Author:flar Date: 2010-12-06 21:45 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/47cd69eff641 6775317: Improve performance of non-AA transformed rectangles and single wide lines in software pipelines Reviewed-by: jgodinez, prr ! make/sun/awt/Depend.mak ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-vers ! src/share/classes/sun/java2d/SurfaceData.java + src/share/classes/sun/java2d/loops/DrawParallelogram.java + src/share/classes/sun/java2d/loops/FillParallelogram.java ! src/share/classes/sun/java2d/loops/RenderLoops.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/native/sun/java2d/loops/Any3Byte.c ! src/share/native/sun/java2d/loops/Any4Byte.c ! src/share/native/sun/java2d/loops/AnyByte.c ! src/share/native/sun/java2d/loops/AnyInt.c ! src/share/native/sun/java2d/loops/AnyShort.c + src/share/native/sun/java2d/loops/DrawParallelogram.c + src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/LoopMacros.h ! src/solaris/native/sun/java2d/loops/java2d_Mlib.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c
