Andrea Aime a =E9crit :
> unfortunately due to severe lack of spare time I'm no longer an active=20
> developer, so
> you may want to create a JIRA issue that will be hopefully managed by=20
> Martin Desriusseaux...
> I think he's the only developer currently interested in mantaining the=20
> j2d renderer, since the
> Refractions guys have preferred to use and mantain my simpler lite=20
> renderer due to better
Of course I'm defending my baby, so I'm not impartial here. But we are=20
obviously in disagreement. Unfortunatly, I have been stuck with my Ph.D.=20
thesis much longer than I initially though (at least one year longer),=20
and I'm very sorry to have been unable to done any serious J2D work for=20
That said, I strongly believe that J2D renderer has way much more=20
potential than LiteRenderer, at the cost of its complexity. But J2S=20
renderer is complex because the problem *IS* complex. LiteRenderer is=20
doing some false assumptions regarding AffineTransform and projections=20
among other (I told that to Refractions Research guys in last OGC meeting=
I have been back as an active developper only since the begining of=20
February, as you can see from my commit. I must finish CRS first, then=20
work on GridCoverage, and J2D renderer will be next.
This is true that LiteRenderer is much mpre Geotools aware than J2D=20
renderer at this time. But the J2D architecture is closer than=20
LiteRenderer to GO-1, which is itself close in spirit to commercial=20
packages like ESRI in my understanding. J2D renderer will be ported to=20
GO-1; I'm not sure that LiteRenderer can. Please remember that I'm=20
strongly involved in GeoAPI development, up to the point that I have=20
sent feedback to some working groups, and some of my suggestions have=20
been accepted by OGC for the next ISO 19111 revision. I'm not putting=20
all those energy in standards (ISO 19111, ISO 19107, ISO 19115) for=20
So yes LiteRenderer is much more standard-aware than J2D renderer for=20
now, but expect the situation to be inversed before the end of this year.
As for performance and scalability, I swear you that J2D renderer will=20
blast LiteRenderer in performance (except at startup time) with=20
comparable scalability and better standard-compliance. But there is=20
months of work ahead before I reach this point.
In any case, the API will be significantly different after I make the=20
switch to GO-1. So no matter which renderer you use (LiteRenderer or J2D=20
renderer), I'm afraid that some significant refactoring will be hard to=20
avoid. On the bright side, the refactoring should be toward standards.