Hello there Just a quick note from our experience: we also realized that blindly parallelizing the rendering would get us nowhere. But we did not get into Andrea's (quite nice) ideas of automatically dividing the map into zones according to the physical resource.
What we did was to create a similar concept (we called it "map sections"), and allowed the user to manually divide their map into these sections of layers. So, the idea would be that the user can have a section with a bunch of "background" or "base" static layers, another one for more dynamic or animated ones, another one for user interaction, and so on. Each section would then have its own rendering thread (and surface), and it would be up to the user to control how many of those he/she wants. Our goal was to allow for quick and nice feedback when editing features or animating, without having to render the rest. It was also useful if the user could prepare its data and keep large heavy-weight layers in different sections. Cheers Milton PS: hmm, ok, forgot to say - we here developed the idea of a "map" as a collection of layers with a given structure (i.e., more than a list of layers to be rendered) Andrea Aime wrote: > Michael Bedward ha scritto: >> Hi Andrea, Jody, >> >> I'm reworking the RenderingExecutor class in the swing module. At >> present, RenderingExecutor is designed to work with one map pane, >> running one rendering task at a time. In the new swing code >> RenderingExecutor will offer multiple threads (from a cached thread >> pool) and be able to work with more than one map pane. My main reason >> for doing this is to allow for "linked" panes... >> >> http://jira.codehaus.org/browse/GEOT-3106 >> >> I have a dim memory of the two of you discussing multithreaded >> rendering for better performance. Is this something that would be >> useful to allow for in the new swing code, and if so, how (just in >> general terms) ? > > Multithreaded rendering has to be dealt with very carefully. > > Just some random notes: > - streaming renderer is not thread safe, if you need to render > from multiple threads please use multiple streaming renderers > - blindly parallelizing all layer rendering will most likely > thrash your machine and make rendering slower. > > Parallel rendering can improve things if you partition your > layers in "zones", where each zone is hitting a different > kind of physical resource: one zone for the local machine, > one zone for each server you contact. > As a rule of thumb never make more than X requests in parallel > to the same zone, where X is somewhere between 2 and 6 (the > actual value may vary depending on the hardware, network bandwidth > and so on). Plus all the renderer will in the end fight for the > same set of CPUs on the rendering machine, again, a rule > of thumb may be no more than 2 * numcores parallel operations. > Parallel rendering also means you'll have to prepare N different > rendering surfaces, each one will use memory (eventually lots > of it), this gives you another limit to the number of things > you can do in parallel. > > Given you cannot render everything at once a policty to > prioritize certain layers might affect how people perceive > rendering: > - remote layers are slow to render, better start them sooner > - small local layers can render fast enough to provide sufficient > context for people to keep zooming/panning around without > waiting the whole map to be rendered, better start them > sooner as well > > Hope this helps > Cheers > Andrea > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
