Message-ID: <1726973750.1509.1369229368615.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1508_1690797322.1369229368614" ------=_Part_1508_1690797322.1369229368614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
David Blasb= y sent in the following request....
(sending this out quickly for the IRC meeting)
Okay, I've been fixing up the StreamingRenderer the last little while, a= nd here's what I think needs to be done. Most of these are just little cle= an-up to get rid of the evidence of a long period of people slapping stuff = into it.
A) The path through the renderer is a bit confused. For example, where= is CRS transformation done? Its actually done by wrapping the FeatureRead= er in a CRS-transforming feature reader. But, there's also code (now in Li= teShape2 - it used to be partially in LiteShape2 and partially in the Graph= ics2D segment Iterators) that takes a geometry, decimates it, transforms it= ,then does a pixel-level generalization. The CRS transformation code shoul= d be done here since you can save a bunch of complex math by generalizing f= irst. Its also just really confusing to read since there's 3 sets of gener= alization code! There's other cases of confusion.
This is mostly a clean-up than writing new code - just make the path thr= ough the renderer obvious and itemize the steps (AND WRITE DOX). Currently= its confusing, mostly because the original renderer was dead-simple and th= e new one was made by bolting tonnes of extras on.
B) All the Graphics2D Iterators need to be re-written. I just rewrote t= he LiteIterator (which can get re-used by all the other Iterators). The It= erators are extreamly difficult to read.
Once (A) is done, this should be much easier since they seem to be "= ;doing too much" right now.
C) The renderer should be segmented into two classes. The first one sho= uld be concerned with "setting things up". These are things like= dealing with the MapContext, optimizing the styles, getting optimized Feat= ureReaders. The second will basically take the FeatureTypeStyle (which h= as the Graphics2D and actual Styles) and FeatureReader and do the actual dr= awing. This break is currently in the Renderer approximately at the functi= on "processStylers()"/"processSymbolizers()".
This will allow for more code-reuse, and simplify the current (giant) = class. Its not too much work since the renderer is conceptually already br= oken up like this. It will make it very easy to write a parallel renderer t= hat would render more than one layer at a time (good for multiprocessor mac= hines and/or datasets that block while reading from the disk/network/socket= ).
The end result will be a renderer that is much easier to understand and =
maintain. I'd bet there will be minor speed improvements too.
Anyone got any time to help in this?