Message-ID: <80262073.4687.1394525158034.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4686_1653389579.1394525158034" ------=_Part_4686_1653389579.1394525158034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
David Blasby sent in the following request....=20
(sending this out quickly for the IRC meeting)=20
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 clea= n-up to get rid of the evidence of a long period of people slapping stuff i= nto it.=20
A) The path through the renderer is a bit confused. For example, where i= s CRS transformation done? Its actually done by wrapping the FeatureReader = in a CRS-transforming feature reader. But, there's also code (now in LiteSh= ape2 - it used to be partially in LiteShape2 and partially in the Graphics2= D segment Iterators) that takes a geometry, decimates it, transforms it,the= n does a pixel-level generalization. The CRS transformation code should be = done here since you can save a bunch of complex math by generalizing first.= Its also just really confusing to read since there's 3 sets of generalizat= ion code! There's other cases of confusion.=20
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 the= new one was made by bolting tonnes of extras on.=20
B) All the Graphics2D Iterators need to be re-written. I just rewrote th= e LiteIterator (which can get re-used by all the other Iterators). The Iter= ators are extreamly difficult to read.=20
Once (A) is done, this should be much easier since they seem to be "= ;doing too much" right now.=20
C) The renderer should be segmented into two classes. The first one shou= ld be concerned with "setting things up". These are things like d= ealing with the MapContext, optimizing the styles, getting optimized Featur= eReaders. The second will basically take the FeatureTypeStyle (which has = the Graphics2D and actual Styles) and FeatureReader and do the actual drawi= ng. This break is currently in the Renderer approximately at the function &= quot;processStylers()"/"processSymbolizers()".=20
This will allow for more code-reuse, and simplify the current (giant) c= lass. Its not too much work since the renderer is conceptually already brok= en up like this. It will make it very easy to write a parallel renderer tha= t would render more than one layer at a time (good for multiprocessor machi= nes and/or datasets that block while reading from the disk/network/socket).==20
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?