Hi Sergey,
It is quite interesting! But it would be good to check what code was
> affected by this parallelization. I meant we cannot draw much-much faster
> than OGL draw its primitives, so even w/o parallelization if we will call
> flush after each fillRect/etc(mimics the in-place rendering on
Hi Laurent,
Thanks for your interest in tuning the pipelines and all the work you did
in this regard with Marlin.
> I read again the source code and wanted to add metrics like wait_ratio
and make some new heuristics to auto tune the buffer capacity.
> I was also tempted to rewrite the buffer
Hi Sergey,
> The design is a little bit different, the XRender pipeline:
> - Many threads which call draw operations and sends them to the XServer
> - The XSerever decode the the draw operation and push the commands to
the "opengl buffer"
> - Some video driver code which decode the ogl
Hi,
With solid OpenGL support on Linux being ubiquitous these days and the
XRender pipeline being a bit of a dead-end (works quite well except
MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the
state/performance of the OpenGL pipeline.
Specifically why it performs sometimes worse
Hi Phil,
> Is there a regression test ?
> I don't see a noreg- label.
Sorry I forgot to mention, the regression test is in the "main"
directory of the bugfix:
http://cr.openjdk.java.net/~ceisserer/8235904/
Thanks and best regards, Clemens
Hi,
Please review the fix for bug 8235904 "Infinite loop when rendering
huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/
The issue was caused by integer overflow during clipping: While the
original native code used int or long depending on the coordinate
range, the java-port
Hi,
> This moves the Java 2D demo from "closed" to "open".
> It is now called "J2Ddemo" to avoid any trademark questions.
> This has already been reviewed internally and the images here are OK to
> keep.
This is awesome news :)
Java2Demo is such a handy tool to visually check various features
Hi Sergey,
> Thank you for contribution! If there is a chance to implement it soon(at an
> early test stage) then it is possible to push this to jdk11 and enable it by
> default to expose all possible issues. If no issues will be found, then we
> can release it as-is, otherwise we can disable it
Hi everybody,
I finally got my hands on a 10-year old NVidia GPU (8800GTS) and can
confirm Laurent's findings.
The proprietary nvidia driver is awesome for the MaskBlit workload,
for x11perf -shmput10 it is 32x faster
than my kaveri APU solution (despite it has to copy data via PCIe).
> Finally,
HI,
> As previously mentioned, I increased the RenderQueue buffer (see patchs at
> the end) to 4M (instead of 32K) and d3d & opengl get boosted.
It is great to see the tile-size improvements reach the other backends too :)
In case of the buffer size - I wonder is 4M really needed or was it an
Hi Laurent,
Thanks a lot for taking the time to test the deferred xrender pipeline.
Especially since the proprietary nvdia driver is the only one of
the accelerated xrender implementations I didnt test / benchmark against.
> On my linux laptop (i7 + nvidia quadro), xrender is already faster than
Hi,
After achieving huge speedups with Marlin Laurent Bourgès recently
proposed increasing the AA tile size of MaskBlit/MaskFill operations.
The 128x64 tiles size should help the Xrender pipeline a lot for
larger aa shapes. For smaller xrender stays rather slow.
To solve this issue am currently
Hi Jay,
> 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on
> SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color
> to pre-multiplied values.
Thanks a lot for identifying the issue and working on it.
The fix itself looks fine and low-risk.
Hi Jim,
> They do operate differently. They aren't meant to be mixed and matched.
Thanks a lot for the detailed description of the relationship between
SSI and ProcessPath.
I did some further digging as to why the xrender pipeline has issues
with the test attached to the mentioned bug report -
HI Jim,
> All of those conditions are optimized equivalents to getting the
> determinant.
>
> invert() is a destructive call, but since getTransform is documented to
> return a copy, that is fine - but getDeterminant() will involve less math to
> check the condition...
Thanks for the
Hi Sergey
> I guess you can use "getDeterminant()==0" to determine if this transform has
> no inverse?
Initially I had the same idea, but looking at the implementation of
invert(), I found several different conditions leading to an
NoninvertibleTransformException. So I decided to keep the call
Hello again,
> OK .. should be part of the patch tho'
Just noticed the reg tests are also open-source, until now I thought
they are integrated into some Oracle-only internal test collection.
Cool!
Please find the current version of the patch at:
http://93.83.133.214/8162591/webrev.03/
It
Thanks a lot for the feedback.
> The fix seems fine .. is there a possibility to have a regression test?
> Perhaps based on the code in the bug ?
Please find an automated regression test at:
http://93.83.133.214/8162591/HugeGradientTest.java
> Should we also check the transform?
> I guess we
Hello,
The cause of JDK-8162591 is Java2D's gradient implementation allowing
for coordinates to be specified using floating point values, whereas
XRender is limited to a 16.16 fixed point format - which can therefor
easily overflow.
This patch checks whether the supplied coordinates can be
Hi Sergey,
Actually it will do this for any blits to the window, because the swing
can use different paint strategy(w/ or w/o buffer) or the user can draw
something to the window directly via BufferStrategy.
Thanks for the clarification.
Is there a reason why AWT doesn't explicitly flush
Hi Jeroen,
I'm the submitter of JDK-8068529
https://bugs.openjdk.java.net/browse/JDK-8068529 and I'd like to
respond to the comments of this bug
Thanks for reporting this issue.
In reply to the comments of 2015-01-12: without xrender, XSync is indeed
called in X11SurfaceData.c, in
Hi Phil,
Do you want me to commit this ?
We'd then need a new bug for the next chunk
of course ..
Please.
I'll provide a seperate patch for removing the unused methods you
mentioned earlier.
Thanks best regards, Clemens
Hi Phil,
Fix looks good. Is there a way you can check in a regression test along-side
the fix
else you'll need to add a 'noreg-some reason' label on the JBS bug.
Thanks for the review - I'll write a regression test today.
- Clemens
Hi Phil,
Please find the regression test at:
http://cr.openjdk.java.net/~ceisserer/8054638/WhiteTextColorTest.java
Thanks, Clemens
It needs the GPL license (copied from another test to get the right one)
and there's one typo : wether - whether
Header added, thanks for finding the typo:
http://cr.openjdk.java.net/~ceisserer/8054638/WhiteTextColorTest.java
Otherwise looks fine.
In case no other issues pop up and a second
Hello,
Please review my fix for JDK-8054638 xrender: text drawn after
setColor(Color.white) is actually black.
The XRSolidSrcPict manages a small 1x1 pixmap which is used as source
surface for some operations.
To avoid redundant fillRect operations when setting it's color, the
currently set
Sorry, forgot to include the link to the webrev:
http://cr.openjdk.java.net/~ceisserer/8054638/webrev.00/
2014-08-13 7:32 GMT+02:00 Clemens Eisserer linuxhi...@gmail.com:
Hello,
Please review my fix for JDK-8054638 xrender: text drawn after
setColor(Color.white) is actually black
Hello,
Please review my changes for the first patch of a series to come to
cleanup the Xrender Java2D pipeline.
http://cr.openjdk.java.net/~ceisserer/8049757/webrev.00/
This patch removes support for the Jules rasterizer backend, which
relied on a modified version of the native Cairo library.
Hi Julien,
Mageia Linux' bug tracker most likely isn't the best place to file
this bug - most distributors simply package OpenJDK and aren't
involved in it's development (with redhat being one of the noteworthy
exceptions)
This bug is reproducible only with the XRender pipeline.
In your bug
Hi,
I would like to add that, beside higher performance for rasterization,
Marlin's capability to produce tiles larger than 32x32px also improves
the performance with the XRender pipeline für larger antialiased
shapes a lot.
For modern drivers uploading 32x32 small coverage masks is more
Hi Alex,
now that my OCA has been processed I would like to bring to attention a
proposal that
I posted earlier this year to this group.
And below a repost of the most recent version of the patch.
Glad to hear the OCA process did work out for you :)
I don't know if anyone remembers but
Hi Phil,
Thanks for the review.
Not that it impacts us now but I think the tricky question is can we ever
remove the workaround?
ie how will we ever know when we are using a fixed xrender lib.
I'd like to see core Xrender add a GetVersion() API so we can figure this
stuff out at runtime.
Hi,
Please review my fix for JDK-8028722: XRender: Drawing strings with
exactly 254 glyphs causes hangs available at
http://cr.openjdk.java.net/~ceisserer/8028722/webrev.00/
A test is available at:
http://cr.openjdk.java.net/~ceisserer/8028722/XRenderElt254TextTest.java
Problem description:
When
Hi Phil,
http://cr.openjdk.java.net/~prr/8027541/
In the case where there is an alpha color on the window, the
X11 pipeline looks at the color model of the GraphicsConfiguration
and upgrades the surface to one with alpha. This makes the Xrender
pipeline do the same. SQE test failure, so no
Hi,
One wish regarding pisces came into my mind:
Currently all AA tile generators feed 32x32 coverage tiles to the pipelines.
While this might be a good idea for software-only pipelines due to
good cache locality, it is a huge issue for at least the xrender
pipeline.
Each tile has to be
Hi,
PLEASE, PLEASE don't make us wait until JDK9 for something that worked really
well in Apple's JDK6.
An internal API doesn't mean you can't use it with JDK8, only that it
is not part of the default API (which is more or less the same as with
Apple's JDK6).
However wouldn't it better to
Hi Jim,
Thanks for taking the time to review this in-depth.
I guess that also explains why the source coordinates were multiplied by the
scale, though that seems a rather odd way to handle these issues.
Indeed, the offsets could be also stored as part of the transformation
(as it is done for
Hi Jim,
We should be looking to obsolete and delete getScaledInstance(), not giving
it a new lease on life with new capabilities...
Marking it deprecated would probably be a good idea, at least the JDK7
javadocs don't warn developers in any way about the implications of
using
Hi Alexander,
Please see the updated webrev:
http://cr.openjdk.java.net/~bae/8024767/webrev.01/
The fix looks fine to me.
Thanks for creating the test-case :)
- Clemens
Hi,
Ok, this starts to become embarrassing ... sorry for the review
request spam recently.
I was stressed that my changes would be submitted too late, so I
submitted as soon as I had a fix for an isolated issue.
During extensive testing I've found a few other issues within the
xrender pipeline
Please wait with the commit, there are a few other issues hidden in
the horrors of the xrender pipeline's gradient support.
2013/10/19 Andrew Brygin andrew.bry...@oracle.com:
Hello Clemens,
the fix looks fine to me.
Thanks,
Andrew
On 10/18/2013 8:59 PM, Clemens Eisserer wrote:
Please
Please review my fix for bug JDK-7082809 : xrender artifacts caused
by different interpretation of SRC operator located at:
http://cr.openjdk.java.net/~ceisserer/7082809/webrev.05/
A manual test-case is available at:
http://cr.openjdk.java.net/~ceisserer/7082809/CompositeTest.java
Problem
Hi Andrew,
a copyright header is missed in the new file XRSolidSrcPict.java.
Could you please add it?
Done.
Please find the updated webrev at:
http://cr.openjdk.java.net/~ceisserer/7082809/webrev.06/
Thanks, Clemens
Another revision was required, available at:
http://cr.openjdk.java.net/~ceisserer/fix12/webrev.04/
When the destination-area is quadratic, no geometry is stored inside
the mask and therefore the composition-window is used for clipping and
it's size has to be rounded properly.
In cases where it
Hi,
Please review my fix for the issue described below at:
http://cr.openjdk.java.net/~ceisserer/fix13/webrev.00/
Problem description:
Phil found an issue with TransformedPaintTest, where the center point
of radial gradients was stuck at (0,0) with the xrender-pipeline
enabled.
The center-point
Hi,
Please find an updated webrev with your suggestions at:
http://cr.openjdk.java.net/~ceisserer/fix12/webrev.01/
Am I reading this right. You are saying that it is used in a mixture of
cases and some of those will support full transforms?
Exactly.
What I was suggesting is that the adjust
As usual, seconds after sending a review request I somewhere find
another issue - sorry.
Please instead of webrev.01, review
http://cr.openjdk.java.net/~ceisserer/fix12/webrev.02/
In the previous version, I assumed not using a mask means a
quadrant-rotated transform, which is not correct as the
Hi,
As Jim pointed out, my earlier fix for bug JDK-7159455 wasn't entirely
correct as it allowed some shear-transformations to pass a check for a
fast-path although they should have been rejected. He proposed a way
of using the capabilities already provided by AffineTransform, which
is correct,
Hi Jim,
You should be able to use the same code as SRC for CLEAR, but you are
rejecting that operation. And, if the destination is opaque then SRC_IN is
identical to SRC, but you are rejecting that as well.
Perhaps the lower layers are ignoring ISCOPY and seeing the SRC_IN or CLEAR
and
Hi,
Please review my fix-suggestion for the problem described below
available at: http://cr.openjdk.java.net/~ceisserer/fix11/webrev.03/
A testcase is available at:
http://cr.openjdk.java.net/~ceisserer/fix11/TextCompTest.java
Problem description:
When rendering Text with AlphaComposite.SrcIn
Hi Jim,
Apologies as this is an old bug, but I just looked at the fix and it seems
to me that it will allow shearing transforms to pass because the tests are
incomplete. The 0or180 flag only tests if the horizontal lines stay
horizontal, but they could shift relative to each other in
Hi Vadim,
The fix itself looks fine to me - thanks for taking care about this.
- Clemens
PS: what is the reason for this bug is confidential?
Please review a fix for this bug:
https://bugs.openjdk.java.net/browse/JDK-8024343
Hi,
I am currently testing compatibility of the xrender pipeline with
different composition operations, and I noticed for AlphaComposite.SRC
the D3D and OGL pipelines store pre-multiplied colors in surfaces
without an alpha-channel.
For example the following code results in a black rectangle,
Hi Phil,
Shouldn't most of this be inside an ifdef _linux_ ?
Solaris (currently) even MacOS will compile this code.
Thanks for the pointer, I completely forgot about OSX (solaris should
work as-is).
Please find an updated version at:
http://cr.openjdk.java.net/~ceisserer/8007386/webrev.02/
-
Hi Phil,
the webrev and test need a little clean-up : adding the @test and @bug tag +
GPL
Please find a corrected version at
http://cr.openjdk.java.net/~ceisserer/8024895/webrev.01/
along with a (hopefully) jtreg conformant testcase at
Hi,
Please review my fix at http://cr.openjdk.java.net/~ceisserer/fix10/
I haven't created a an official bug-id, because due to the migration
to JIRA those user reports don't seem to be directly useable anyway.
Problem description:
For transformed blits the xrender pipeline uses caching-logic to
the fix looks fine to me.
Thanks. Please commit.
Regards, Clemens
Hi,
Please review my patch for 9006475 at:
http://cr.openjdk.java.net/~ceisserer/9006475/webrev.00/
Before this patch we were calling the native method
XRenderRectanglesNative() even in the case that there was only single
rectangle to be rendered (which is the case for Graphics.fillRect). As
Hello,
Please review my fix for: JDK-7179526 : xrender :
closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36
at http://cr.openjdk.java.net/~ceisserer/7179526/webrev.00/
Problem description: Lines weren't rendered in a consistent way when
they were clipped.
The issue originated
Hi Andrew,
Thanks for your feedback.
Do you know which versions of libXrender are supported? We can check the
version
at configure time:
$ pkg-config --modversion renderproto
0.11.1
and disable the extension at compile-time. This is especially true with 6
where,
IIRC, it's a
Hi Frank,
Recently our team discovered defect 7032904(XRender: Java2Demo : Infinite
loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64) still exists
in latest JDK (7u21) on SLES10SP4. It can be easily reproduced by running
SwingSet2 with Nimbus LAF. The issue is also seen in
Hi Laurent,
thanks for having some interest for my efforts !
As I got almost no feedback, I felt quite disappointed and was thinking
that improving pisces was not important ...
Glad to see work is ongoing to improve pisces's performance :)
I had a look at the patch just to be curious (I
Hi,
While performance testing to compare the different pipelines I noticed
the D3D pipeline doesn't work (Couldn't enable D3D pipeline) with
Intel's latest drivers on Sandy Bridge running Windows7.
As modern intel GPUs are feature-wise quite on par with real
discrete graphic cards, and I am able
for unsigned results and exact
non-overflowing integer results as well, but that would complicate any
backports to JDK7...)
...jim
On 4/13/12 9:46 AM, Clemens Eisserer wrote:
Hi,
Please take a look at the patch for bug 7105461, located at
http
Hi,
Automated test will require taking screenshot and comparing results, I'm not
sure if this mechanism works good.
It should be possible to render to a VolatileImage, which allows
direct readback without taking a screenshot.
- Clemens
Hi,
Unfourtunatly the situation is worse than I expected, currently
xrender doesn't seem to support anything better than billiniar
interpolation.
Because alias-names where used by the pipeline it didn't turn up
sooner (as they are guaranteed to be available, whereas the concrete
Hi Jim,
For a complex clip it is not enough to test the two endpoints so I don't
think this fix will work for a line that spans between two portions of a
non-rectangular clip over a region that is outside the clip...
This case is handled by the native clip, so it would just be a missed
Hi Phil,
Thanks for taking a look.
Fix looks reasonable and good to have a fix for this!
I do think it would be safer to be better than the X11 pipeline if possible
I reworked the original patch a bit and put the checks at a higher
level, based on the following two assumptions:
- Clipping
Hi Jim,
I don't understand. You are checking to see if the line is inside the clip,
but your test will think that something is inside the clip when it is not so
the fast path code will be used for lines outside the clip. If the case
can handle lines outside the clip then why test at all?
the delegation that you are doing now ...
Diagonal lines are quite a sad story with xrender anyway - I tried to
keep it simple.
For horizonal/vertical lines (which can be reduced to a fillRect) it
should have been a win, however.
Thanks, Clemens
-phil.
On 4/5/2012 5:49 AM, Clemens Eisserer
Hi,
Please take a look at the patch for bug 7150134, located at
http://cr.openjdk.java.net/~ceisserer/7150134/
The problem was caused by a fast-path in drawLine() which didn't take
clipping into account, therefor huge lines that would have been
clipped away caused OOMs in xrender's bresenham
Hi Mario,
The patch looks good to me.
Thanks for taking a look.
Just wondering what is the impact of those two checks:
+ if (compClip.contains(transX1, transY1)
+ compClip.contains(transX2, transY2)) {
for the most common cases?
I wasn't able to measure any
Hi Phil,
I think we should turn on Xrender by default in these early days in JDK 8
http://cr.openjdk.java.net/~prr/7077423/
I feared that day would come ... great :)
I know of two more-than-minor bugs, however I haven't had the time to file
reports:
- Problems with SRC + alpha values when
Hi Jim,
I'm pretty sure that BufImgSurfaceData does not lock the toolkit lock. I
think only the X11SD needs that as it needs to serialize access to X11 and
it may need to read back pixels or send pixels via Xlib.
Thanks for the clarification. That should help scalability a lot for
my use-case
Hi,
Just to be sure, Is it allowed/possible to use a per-surface locking
structure for SurfaceData's lock/unlock functions to improve
concurrency?
All OpenJDK pipeline implementations seem to lock the toolkit lock, so
maybe the software routines expect the toolkit lock to be locked.
How do
Hi Mario,
Unfourtunatly the OpenGL pipeline suffers a lot from broken drivers.
Drivers seem to be optimized a lot for the game-case, where a frame
is repainted over and over again.
I remember I read somewhere in nvidia's release-notes that some bugs
related to the opengl backend have been fixed
Forgot to mention, the version included in openjdk6 is really old - I
recommend JDK7.
- Clemens
2011/6/7 Clemens Eisserer linuxhi...@gmail.com:
Hi Mario,
Unfourtunatly the OpenGL pipeline suffers a lot from broken drivers.
Drivers seem to be optimized a lot for the game-case, where a frame
HI again,
I'll try to diagnose it a bit more, maybe I can get an idea whats
going wrong there.
But at least I have confirmation that it is supposed to honor the
default printer setting :)
Ok, its a bug in JasperReports. It queries the list of available
printers, and sets the first one -
Hi Phil,
And (forgive me for being nit picky), this is really more of a question for
one of the forums on using the APIs rather than the openjdk ones for
working on the implementation. That's my standard reminder on this to
be consistent.
I posted it on the forums about a week before writing
to be rather
common for many bug-numbers I see floating arround on the mailing
lists. Any idea why?
2011/3/22 Clemens Eisserer linuxhi...@gmail.com:
Hi Phil,
I'll have a look at this one soon.
I also hope to fix the bug causing intellij's editor to be completly
unuseable before jdk7's freeze phase
Hi,
I've recently encountered some BadMatch errors triggered by fallbacks.
Those are caused by reading outside of surface bounds using the cached
ShmPixmap.
Testcase and patch attached.
Running with -Dsun.awt.noisyerrorhandler=True the testcase causes a BadMatch:
Xerror BadMatch (invalid
Hi,
Some users reported problems with the IntelliJ Idea's editor when
running with xrender enabled.
It turned out that there are some differences between how Java and
xrender interpret the SRC operator.
Is the general rule, that SRC behaves like SRC_OVER when antialiasing
is enabled?
Are there
Hi Jim,
blendresult = PORTER_DUFF(rule, rendercolor, dstcolor, extraalpha)
// For SRC, blendresult = rendercolor modulated by extra alpha
storedresult = INTERP(dstcolor, blendresult, aacoverage)
// For full aa coverage, storedresult = blendresult
The only part of this that could possibly be
Hi,
While playing arround with the SRC composition rule I found what seems
to be a bug.
When rendering text with an AlphaComposite(SRC, EA) I get garbage when
enabling subpixel antialising:
g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC, 0.01f));
Hi Denis,
It's interesting to note that this doesn't happen on OpenJDK, and
on closed java the subpixel hint is not necessary to reproduce this.
Simply using VALUE_ANTIALIAS_ON and the SRC composite is enough.
I have to enable lcd text antialising to get the described result,
however I see it
Hi Phil,
It doesn't sound right to me that this behaviour is an implementation detail
of X.org.
Developers need to know that either it does or it doesn't. Were you given a
good rationale?
The explanation was that Pixmaps are reference counted, and therefor
stay alive if a XRender-picture
Hi again,
Any thoughts on this one that just got submitted a few minutes ago?
I'm guessing you don't have a SPARC System with OpenSolaris handy
so I'm just asking for ideas here.
The only thing I can think of is the copy code which copies/converts
the GlyphInfo image-data into the stream
Hi Phil,
I see the problem now. I looked at what T2K (the rasteriser) reports, but
in the non-T2K glue code we then make an adjustment in the case of LCD
glyphs
which simply should never have been applied in the case of an empty image.
It has never affected any of our code as I think we only
Hi Phil,
Strange, running your test I get width=-1 when uploading as well as
rendering the glyph - and the pipeline basically just reads the native
GlyphInfo structure by using Unsafe.
I'll have to think about it a bit more ..
Anything I could to to help to track that down?
Thanks, Clemens
Hi,
I would like to get two (very small) changes to the xrender-pipeline in:
1. http://93.83.133.214/ignore-whitespace-width.zip deals with the
fact that the closed-source
font rasterizer seems to generate width=65535 for whitespaces, which
resuts in software fallbacks.
Granted with height=0
By the way ...
The Jules cairo pisces replacement obviously isn't all that useful
without the backend .. is it likely the required cairo modifications
would ever make it into linux distros ? If not I'm not sure its
worth putting the java glue code into openjdk.
Wouldn't it be possible to put
Hi Andrew,
Which then has to be maintained with regard to security updates, etc.
IcedTea pulls out the in-tree libjpeg, libpng and zlib libraries and
uses the system ones to avoid this issue.
Can't it be made to work with the system cairo?
For XRender it would require rendering to an
Hi Phil,
Thanks for taking the time to review the code.
I uploaded the new/resulting webrev to:
http://93.83.133.214/webrev-xrender-jules-0.0.2.zip
The Jules cairo pisces replacement obviously isn't all that useful
without the backend .. is it likely the required cairo modifications
would
Hello,
I've merged the xrender pipeline with master, please take a look at the webrev:
http://93.83.133.214/webrev-xrender-jules-0.0.1.zip
It would be great to get the review-process rolling for the critical
parts like StrikeCache.java or sunFont.c
It also includes a preview of Jules, a cairo
Hi,
I am trying to install my own RenderingEngine implementation, however
I am not accustomed to the ServiceLoader concept:
ServiceLoaderRenderingEngine reLoader =
ServiceLoader.loadInstalled(RenderingEngine.class);
the ServiceLoader doesn't e.g.
Hi Andrew,
How close is what you have to what we have in IcedTea? I'm thinking
it might be a good idea to have your XRender work in the IcedTea
forest rather than as patches in IcedTea7. That would give you a
clean webrev against the latest JDK7 code.
Its a complete rewrite and doesn't
Hi,
Thanks for all your work, integrating and maintaining the pipeline.
So I should just ditch what we have in IcedTea7 and use this webrev?
I had to reroll all the patches for b74 anyway so get rid of that
maintenance headache would be nice.
Yes, in the long run I hope this code will
Hi Phil,
Thanks for taking a quick look.
Seems the webrev is in a rather chaotic state, I'll try to clean it
up a bit to make review easier.
I have a very few superficial comments from my quick look at a few files
that are *changed*.
X11SurfaceData and the glyph caching changes need a
Hi,
What is the offset-field in AATileGenerator.getAlpha used for? The
documentation/pseudo code in AATileGenerator seems to ignore this
parameter.
Does it mean I should rasterize moved by offset?
Thanks in advance, Clemens
1 - 100 of 135 matches
Mail list logo
