Hi Laurent,
On 5/29/13 2:01 AM, Laurent Bourgès wrote:
Two comments:
- hotspot takes some time to optimize the very large
Renderer.endRendering() and ScalineIterator.next() methods: probably
because these methods represents too many byte codes (many loops ...)
- I tried merging them but it seems
I'd have to look, but I think we could raise our precision in the X
direction without costing too much in performance since it just affects
the scale of our sub-pixel contributions per pixel. But, raising it in
the Y direction is where the performance starts to hurt us because it
means more di
Hi Laurent,
On 6/11/13 5:21 AM, Laurent Bourgès wrote:
Dear Java2D members,
Sorry to ask but does anybody care about improving java2D rendering
(quality, performance) ?
I sent several emails for one month and nobody answered.
Should I consider that there is no interest and give up ?
I apolo
Jim,
I think I found the source of the 'poor' quality of line rendering:
the alpha coverage is only computed for the 2 sub pixels (x0, x1) at the
current x-coordinate of an edge ie it does not take into account the span
of a line having a very flat slope:
for (i = 0, sum = 0, prev
Dear Java2D members,
Sorry to ask but does anybody care about improving java2D rendering
(quality, performance) ?
I sent several emails for one month and nobody answered.
Should I consider that there is no interest and give up ?
I am still waiting for feedback and support before going on worki
Phil,
As I am currently working hard on improving pisces rendering engine
(performance and quality if possible), I am looking for interesting
algorithms, optimization tricks ... i.e. I need to study different
approaches (subpixel rendering, rasterizer, scanline renderer, coordinate
conversions).
From http://www.oracle.com/technetwork/community/oca-486395.html
"The OCA gives Oracle and the contributor joint copyright interests in
the code ..."
So you can't use AGG since you don't have the rights to contribute it under
OCA terms.
Also I don't think we want to swap out pisces and start
On Wed, May 29, 2013 at 2:05 PM, Laurent Bourgès
wrote:
> Seems very interesting ... I just looked at the documentation.
>
> AGG code would be worth to look at but somebody should check if their
> license is compatible with openjdk license terms.
>
>
I'm not a lawyer, so take this with a grain of
Seems very interesting ... I just looked at the documentation.
AGG code would be worth to look at but somebody should check if their
license is compatible with openjdk license terms.
Apparently AGG uses integers to convert float values (24.8 ie float are
multiplied by 256 and then converted to in
On Wed, May 29, 2013 at 11:01 AM, Laurent Bourgès wrote:
> Finally I propose to focus on optimizing these 2 algorithms (methods) as
> it represents 55% of cpu time:
> - optimize / modify algorithms: integer instead of float ops, reduce
> number of condition statements (if) to improve branch predi
Andrea, Jim and java2d members,
I am going back to my work on java2d pisces improvements (scanline
rendering optimization).
Two comments:
- hotspot takes some time to optimize the very large
Renderer.endRendering() and ScalineIterator.next() methods: probably
because these methods represents too
Hi Laurent,
On 5/9/13 11:50 PM, Laurent Bourgès wrote:
Jim,
I think that the ScanLineIterator class is no more useful and could be
merged into Renderer directly: I try to optimize these 2 code paths
(crossing / crossing -> alpha) but it seems quite difficult as I must
understand hotspot optimiz
Jim,
FYI, I am working on optimizing the 2 hotspot methods annotated by oprofile
(see specific emails) :
- ScanLineIterator.next() ~ 35%
- Renderer.endRendering(...) ~ 20%
I think that the ScanLineIterator class is no more useful and could be
merged into Renderer directly: I try to optimize these
This is amazing work, Laurent! I'll look over the code changes soon.
Note that the "2 edge arrays" issue goes away if we can use native
methods and C structs. It may be faster still in that case...
...jim
On 5/6/13 6:43 AM, Laurent Bourgès wrote:
Jim, Andrea & java2d
Andrea,
Thanks and I am impatient to see your benchmark results.
If you have time, could you perform two benchmark runs to compare
ThreadLocal vs ConcurrentLinkedQueue modes:
In RenderingEngine class:
/** use ThreadLocal or ConcurrentLinkedQueue to get the thread
RendererContext */
/* TOD
On Mon, May 6, 2013 at 3:43 PM, Laurent Bourgès
wrote:
> Jim, Andrea & java2d members,
>
> I am happy to announce an updated Pisces patch that is faster again:
>
Laurent, I cannot comment from the code point of view (haven't really read
the patches), but from
the performance standpoint: amazing w
Jim, Andrea & java2d members,
I am happy to announce an updated Pisces patch that is faster again:
- Patched Pisces vs OpenJDK Pisces (ref): ~ 2.5 to 4.5 times faster
score small *1* 20 248,04% 247,90% 464,65% 248,04% *253,49%* 232,64%
207,77% *2* 40 276,49% 276,09% 1317,15% 279,32% *308,52%
Dear Clemens & Jim,
As you know I am currently improving pisces performance (a lot) and I would
like to compare its performance with your JulesRenderingEngine (cairo).
FYI, my last pisces patch performs a bit slower than native ductus renderer
with only 1 thread (only 10-20% slower), but it very
Hi Laurent,
On 5/2/13 1:48 AM, Laurent Bourgès wrote:
xc = computed crossing value for the current scan line;
ceil(xc - 0.5);
Agreed; however, pisces code never performs such rounding: for me,
ceil(x - 0.5) means (int) Math.round(x).
(int) Math.round(x) is almost the same function, b
Jim,
thanks for this long explanations and I agree you approach using semi-open
intervals.
I have the feeling that pisces was not so accurate implementing it.
My comments in the text:
I have few questions regarding renderer edge handling and float ceil calls:
>>
>
> I have a personal philosoph
Hi Laurent,
There's a lot here to go over... ;)
On 4/30/13 9:29 AM, Laurent Bourgès wrote:
Jim,
here is the latest webrev:
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-3/
I'll answer questions first and then have a look...
I have few questions regarding renderer edge handling and fl
Jim,
here is the latest webrev:
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-3/
I tried to revert some syntax mistakes (indentation, moved constants +
cleanup) : code cleanup is still in progress;
so please don't have a frawny face while looking at the code!
I fixed also Ductus and Jules
Jim,
Sorry for the delay: I was busy on reworking the tile generation to cache
only a single line of tiles: it allows me to have ROWAARLE[32][] and
touchedTile a 1d array.
I simply do the rendering when nextTile() detects a tile line end !
Now it is working and the thread local cache is smaller:
On 4/24/13 1:59 AM, Laurent Bourgès wrote:
Jim,
First, here are both updated webrev and benchmark results:
- results: http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_opt_night.log
- webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-2/
Some comments on the webrev:
- This caching o
Hi Laurent,
On 4/24/13 1:59 AM, Laurent Bourgès wrote:
Originally the version that was used in embedded used RLE because it
stored the results in the shape itself. On desktop I never found
that to be a necessary optimization especially because it actually
wastes memory for no ga
Jim,
First, here are both updated webrev and benchmark results:
- results: http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_opt_night.log
- webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-2/
Note: the webrev is partially "cleaner" - work still in progress !
Changes made:
- optimize
Hi Laurent,
Originally the version that was used in embedded used RLE because it
stored the results in the shape itself. On desktop I never found that
to be a necessary optimization especially because it actually wastes
memory for no gain during animations, but that was why they used RLE as
Jim,
I am preparing an updated patch that will contain less syntax changes and
boiler plates. Sorry again.
I have optimized few array cleaning and it perform as fast as ductus on the
biggest map test : in average equals !!
i will send results and comparisons tomorrow.
Hint: alpha array cleaning
One thing about modifying the iterators. I originally commented that I
thought an object there was a bit much but it helped Denis, who was
doing all the work after all, keep the code organized in his mind. I'm
not sure what kind of measurements he made, but he didn't feel that they
were hurti
Hi clemens
Le 17 avr. 2013 23:16, "Clemens Eisserer" a écrit :
>
> 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
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 do
> whereas on Windows / Mac it is client compiler (c1).
For Mac we only have a 64 bit VM which SFAIK should be c2 as well,
yet in that case native was presumably still faster. So its also a matter
of factoring in how good the code is that is generated by the C compiler.
-phil.
On 4/17/2013 1:26
>
> Also, this is with the Java version, right?
>
> Yes, my patch is pure java given as webrev:
> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>
> We got a decent 2x speedup in FX by porting the version of Open Pisces that
> you started with to C code (all except on Linux w
Jim,
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 ...
Here are ductus results and comparison (open office format):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ductus_det.log
http:/
If I'm reading this correctly, your patch is faster even for a single
thread? That's great news.
One of the problems we've had with replacing Ductus is that it has been
faster in a single thread situation than the open source versions we've
created. One of its drawbacks is that it had been d
Jim, Andrea,
I updated MapBench to provide test statistics (avg, median, stddev, rms,
med + stddev, min, max) and CSV output (tab separator):
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/
Here are the results (OpenJDK8 Ref vs Patched):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_de
On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourgès
wrote:
> Dear Java2D members,
>
> Could someone review the following webrev concerning Java2D Pisces to
> enhance its performance and reduce its memory footprint (RendererContext
> stored in thread local or concurrent queue):
> http://jmmc.fr/~bourge
37 matches
Mail list logo
