On Fri, 11 Oct 2019 at 04:31, Andrea Aime <andrea.a...@geo-solutions.it> wrote:
> On Thu, Oct 10, 2019 at 11:36 PM Gabriel Roldan <gabriel.rol...@gmail.com> > wrote: > >> Maybe take the opportunity to fix the typo in "featureRenderer()" (it >> should be featureRendered(), shouldn't it?) and for the sake of consistency >> add feartureStart() and featureEnd(). So maybe >> deprecating featureRenderer() and make featureStart() a default that calls >> the deprecated one until it's removed? >> > > Hmm... this GSIP needs to be backportable, and the change you're > suggesting is not necessary to the task at hand. > Indeed it is not, I was regretting already while typing. It's just that I've seen that typo and FeatureCollection.accepts(visitor) instead of "accept()" far too long and felt like squeezing it in. But you're totally right. > Start/end of feature seems a bit too granular, but it's just a feeling, if > you want to go for it, > I'd suggest you make a separate proposal targeting only master, and a PR > to follow suite. A reminder, now deprecating an API implies migrating all > the calling points in GT/GWC/GS to the non deprecated > replacement, or the build will break (it's one of the checks in the QA > profile). > > >> Another question: do you expect feature events to be enclosed by >> layerStart/End events? I'm not sure how that'll play with multithreading, I >> think StreamingRenderer will do parallel rendering to separate backbuffers >> in some cases? >> > > Good point, they should be enclosed, meaning that the layer end needs to > be issued from the rendering thread. It can be done, matter of > implementation, something to be checked in the PR. > There is a case where that cannot be guaranteed though... when using > cross-layer z-ordering: > https://docs.geoserver.org/stable/en/user/styling/sld/extensions/z-order/syntax.html#z-ordering-across-layers > Not much we can do about it I'm afraid, but the javadocs and related > documentation should point that clearly at the very least. > > Speaking of MT, the rendering is only lightly multi-threaded, there are > two fixed threads, one reading the data, preprocessing it, preparing the > styles to be compatible with Java 2D, > and one actually rendering the geometries with the desired styles, > connected by a blocking queue. It was done like this to compensate for the > Ductus rasterizer > scalability issues, needs to be evaluated if it's still beneficial once we > move away from Java 8 (Oracle Java 8 is the last implementation based on > it, from Java 9 > onwards Marlin is built-in into the JDK). > Thanks for the clarification. So, SimpleFeatureRenderer's setThreadPool() says "Sets a thread pool to be used in parallel rendering". I guess its primary purpose is then not doing parallel rendering itself, but being given the thread pool it can borrow those two threads from, and allowing to set a limit on parallel rendering among multiple renderer instances (if the pool has an upper limit)? Cheers, Gabriel > > The backbuffers are used to handle multiple feature type styles applied to > the same layer, that does not cause multiple threads to be issued. > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* > -- Gabriel Roldán
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
