Menu
▾
▴
geotools-devel
|
From: Andrea A. <aa...@op...> - 2009-01-22 10:07:22
|
Hi all, I'm writing to build some consensus on how to handle a compatibility breaking change. Years ago, way before my involvement in GeoServer, I introduced a rendering optimization for lines. The observation was that if the line width was less than 1.5 pixels, setting it to 0 flat would make the rendering quite a bit faster (30%+ if my memory serves me right) and the visual result would have been the same. Now, at the time I was not using antialiasing, as it made rendering times untolerable on my Athlon 700Mhz, and I did not notice how that optimization affected antialiased rendering. These days more than one people complains that they cannot control the thickness of thin lines. No wonder, it's the above optimization kicking in. And with antialiasing rendering on, well, you can tell a difference between line withs of 0.5, 1, and 1.5 pixels (just to make an example). So, what can we do? Kicking off the optimization the hard way does not seem like a good option to me. People have been creating styles based on the current behaviour, changing it would change the way maps are rendered. To give you some examples, here are maps that have been rendered with the optimization on (the current behaviour) and off (the proposed change). USA population: default: http://www.flickr.com/photos/29313339@N03/3217765574/sizes/o/ opt off: http://www.flickr.com/photos/29313339@N03/3217765474/sizes/o/ USA population, with hatch fills: default: http://www.flickr.com/photos/29313339@N03/3216912511/sizes/o/ opt off: http://www.flickr.com/photos/29313339@N03/3216912387/sizes/o/ Tasmania: default: http://www.flickr.com/photos/29313339@N03/3217765504/sizes/o/ opt off: http://www.flickr.com/photos/29313339@N03/3216912443/sizes/o/ As you can see the rendering changes, in some cases, significantly. It's still possible to get back the old "thin line" rendering, you just have to go and specify a thinner line with, such as 0.5, in the SLD. What I'm proposing is to create an option that allows to toggle the optimization on and off at the renderer level, and at the SLDStyleFactory level (since this is where the optimization really kicks in). For the 2.5.x series, we leave the option on by default, so no change in rendering occurs unless you tell the code otherwise. For the trunk series, I'd say that we should turn the optimization off by default, but leave the toggle around for one more release cycle, after which, we remove it completely. How does this sound? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Justin D. <jde...@op...> - 2009-01-22 15:09:21
|
Sounds like a reasonable approach to me. What will the option look like to the user? Will it be a vendor parameter in an SLD? Or what did you have in mind? Andrea Aime wrote: > Hi all, > I'm writing to build some consensus on how to handle a > compatibility breaking change. > > Years ago, way before my involvement in GeoServer, I > introduced a rendering optimization for lines. The > observation was that if the line width was less than > 1.5 pixels, setting it to 0 flat would make the rendering > quite a bit faster (30%+ if my memory serves me right) > and the visual result would have been the same. > > Now, at the time I was not using antialiasing, as it > made rendering times untolerable on my Athlon 700Mhz, > and I did not notice how that optimization affected > antialiased rendering. > > These days more than one people complains that they > cannot control the thickness of thin lines. No wonder, > it's the above optimization kicking in. > And with antialiasing rendering on, well, you can > tell a difference between line withs of 0.5, 1, > and 1.5 pixels (just to make an example). > > So, what can we do? Kicking off the optimization > the hard way does not seem like a good option to me. > People have been creating styles based on the current > behaviour, changing it would change the way maps > are rendered. > To give you some examples, here are maps that > have been rendered with the optimization on (the > current behaviour) and off (the proposed change). > > USA population: > default: http://www.flickr.com/photos/29313339@N03/3217765574/sizes/o/ > opt off: http://www.flickr.com/photos/29313339@N03/3217765474/sizes/o/ > > USA population, with hatch fills: > default: http://www.flickr.com/photos/29313339@N03/3216912511/sizes/o/ > opt off: http://www.flickr.com/photos/29313339@N03/3216912387/sizes/o/ > > Tasmania: > default: http://www.flickr.com/photos/29313339@N03/3217765504/sizes/o/ > opt off: http://www.flickr.com/photos/29313339@N03/3216912443/sizes/o/ > > As you can see the rendering changes, in some cases, significantly. > It's still possible to get back the old "thin line" rendering, you > just have to go and specify a thinner line with, such as 0.5, in the > SLD. > > What I'm proposing is to create an option that allows to toggle > the optimization on and off at the renderer level, and at the > SLDStyleFactory level (since this is where the optimization > really kicks in). For the 2.5.x series, we leave > the option on by default, so no change in rendering occurs > unless you tell the code otherwise. > > For the trunk series, I'd say that we should turn the > optimization off by default, but leave the toggle around for > one more release cycle, after which, we remove it completely. > > How does this sound? > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
|
From: Jesse E. <jes...@ca...> - 2009-01-22 15:28:41
|
I think I am in agreement as well. Is there a list of Geotools SLD Vendor parameters? Jesse On 22-Jan-09, at 4:09 PM, Justin Deoliveira wrote: > Sounds like a reasonable approach to me. What will the option look > like > to the user? Will it be a vendor parameter in an SLD? Or what did you > have in mind? > > Andrea Aime wrote: >> Hi all, >> I'm writing to build some consensus on how to handle a >> compatibility breaking change. >> >> Years ago, way before my involvement in GeoServer, I >> introduced a rendering optimization for lines. The >> observation was that if the line width was less than >> 1.5 pixels, setting it to 0 flat would make the rendering >> quite a bit faster (30%+ if my memory serves me right) >> and the visual result would have been the same. >> >> Now, at the time I was not using antialiasing, as it >> made rendering times untolerable on my Athlon 700Mhz, >> and I did not notice how that optimization affected >> antialiased rendering. >> >> These days more than one people complains that they >> cannot control the thickness of thin lines. No wonder, >> it's the above optimization kicking in. >> And with antialiasing rendering on, well, you can >> tell a difference between line withs of 0.5, 1, >> and 1.5 pixels (just to make an example). >> >> So, what can we do? Kicking off the optimization >> the hard way does not seem like a good option to me. >> People have been creating styles based on the current >> behaviour, changing it would change the way maps >> are rendered. >> To give you some examples, here are maps that >> have been rendered with the optimization on (the >> current behaviour) and off (the proposed change). >> >> USA population: >> default: http://www.flickr.com/photos/29313339@N03/3217765574/sizes/ >> o/ >> opt off: http://www.flickr.com/photos/29313339@N03/3217765474/sizes/ >> o/ >> >> USA population, with hatch fills: >> default: http://www.flickr.com/photos/29313339@N03/3216912511/sizes/ >> o/ >> opt off: http://www.flickr.com/photos/29313339@N03/3216912387/sizes/ >> o/ >> >> Tasmania: >> default: http://www.flickr.com/photos/29313339@N03/3217765504/sizes/ >> o/ >> opt off: http://www.flickr.com/photos/29313339@N03/3216912443/sizes/ >> o/ >> >> As you can see the rendering changes, in some cases, significantly. >> It's still possible to get back the old "thin line" rendering, you >> just have to go and specify a thinner line with, such as 0.5, in the >> SLD. >> >> What I'm proposing is to create an option that allows to toggle >> the optimization on and off at the renderer level, and at the >> SLDStyleFactory level (since this is where the optimization >> really kicks in). For the 2.5.x series, we leave >> the option on by default, so no change in rendering occurs >> unless you tell the code otherwise. >> >> For the trunk series, I'd say that we should turn the >> optimization off by default, but leave the toggle around for >> one more release cycle, after which, we remove it completely. >> >> How does this sound? >> Cheers >> Andrea >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Geoserver-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
From: Andrea A. <aa...@op...> - 2009-01-22 17:48:44
|
Jesse Eichar ha scritto: > I think I am in agreement as well. > > Is there a list of Geotools SLD Vendor parameters? Hum, not a full one. Most of the vendor extensions were developed by Dave Blasby afaik, and are documented in the GeoServer wiki here: http://geoserver.org/display/GEOSDOC/LabelingOptions For the new labeller I added quite a number, and a colleague of mine was supposed to document them since December but... nothing has popped up thus far. I kept on pinging him, he told me the doc is almost ready... Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Andrea A. <aa...@op...> - 2009-01-22 17:35:40
|
Justin Deoliveira ha scritto: > Sounds like a reasonable approach to me. What will the option look like > to the user? Will it be a vendor parameter in an SLD? Or what did you > have in mind? No, not in the SLD, as I would have to amend the schema even more. At the moment we just added three elements inside a text symbolizer, Priority, Graphics and VendorOption, I would like to avoid adding more unless they buy us something that cannot be expressed in any other way. What I was thinking was more in the lines of adding a GeoServer wide parameter like we did for the new labeller. That is, you pass a system variable like -DOPTIMIZE_LINE_WIDTH=false, or set a param in the web.xml, to disable the line width optimization. I have a patch already, the above param is used in GeoServer, the renderer(s) take a new rendering hint: rendererParams.put(StreamingRenderer.LINE_WIDTH_OPTIMIZATION_KEY, false); to disable the optimization. In 2.6.x I'll just flip the defaults, provided that does not get uDig users too crazy :) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Jody G. <jod...@gm...> - 2009-01-23 03:19:03
|
Hey Andrea; I am still trying to figure out what your optimization did ... > Years ago, way before my involvement in GeoServer, I > introduced a rendering optimization for lines. The > observation was that if the line width was less than > 1.5 pixels, setting it to 0 flat would make the rendering > quite a bit faster (30%+ if my memory serves me right) > and the visual result would have been the same. > This magic number of 1.5 only makes sense if anti-alias is turned off right. To keep in the spirit of the optimization it should be set to 1.25 (if we assume 4x subsampling); or turned off completly if anti-aliasing is turned on? > For the trunk series, I'd say that we should turn the > optimization off by default, but leave the toggle around for > one more release cycle, after which, we remove it completely. > > How does this sound? > That sounds fine; I am still looking at the pictures and trying to decide what has changed. The "thin line" pictures are very thin indeed. > Cheers > Andrea > > |
|
From: Andrea A. <aa...@op...> - 2009-01-23 08:35:38
|
Jody Garnett ha scritto: > Hey Andrea; > > I am still trying to figure out what your optimization did ... >> Years ago, way before my involvement in GeoServer, I >> introduced a rendering optimization for lines. The >> observation was that if the line width was less than >> 1.5 pixels, setting it to 0 flat would make the rendering >> quite a bit faster (30%+ if my memory serves me right) >> and the visual result would have been the same. >> > This magic number of 1.5 only makes sense if anti-alias is turned off > right. To keep in the spirit of the optimization > it should be set to 1.25 (if we assume 4x subsampling); or turned off > completly if anti-aliasing is turned on? It should be turned off completely. But judging from you comments there must be some misunderstanding. The two samples I've attached for each map are both drawn with antialiasing turned on. The one with "thin lines" is what we are drawing today, without me touching the code. The one with the thick lines is instead the code running without that old optimization. The SLD is exactly the same, but it should be easy to see that the rendered line is easily twice as thick. Now what do you think will happen when uDig users discover all of their maps render differently, and they have no way to change them back? In GeoServer people can change the SLD to force a 0.5 pixels line width and they get pretty much the same result as before. But in uDig, the UI does not allow you to enter 0.5 as the value for a line width. This is the kind of change that makes people do work only to get back what they already have, so expect some pissed off people. That's why I'm trying to take a soft change path in GeoServer, so that people that do have fine control of their line width can, but everyone else can happily keep moving along without noticing (at least for some time). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Jody G. <jod...@gm...> - 2009-01-27 07:43:23
|
Andrea Aime wrote: > It should be turned off completely. But judging from you comments > there must be some misunderstanding. > > The two samples I've attached for each map are both drawn with > antialiasing turned on. The one with "thin lines" is what > we are drawing today, without me touching the code. Okay I got it. > The one with the thick lines is instead the code running > without that old optimization. The SLD is exactly the same, > but it should be easy to see that the rendered line is easily > twice as thick. My understanding is that the SLD is now being followed correctly right? > Now what do you think will happen when uDig users discover all > of their maps render differently, and they have no way to > change them back? In GeoServer people can change the SLD > to force a 0.5 pixels line width and they get pretty much > the same result as before. I am going to hide behind the SLD specification for a bit; and apologize for the earlier mistake. however I would like to confirm that non integral widths are allowed. > But in uDig, the UI does not allow you to enter 0.5 as the value for a > line width. See above; I would like to make sure that can be typed in. > This is the kind of change that makes people do work only to get back > what they already have, so expect some pissed > off people. That's why I'm trying to take a soft change path in > GeoServer, so that people that do have fine control > of their line width can, but everyone else can happily keep moving > along without noticing (at least for some time). Understood; thanks for rolling this out Andrea. As part of being on trunk udig will get thrown around a bit. Jody |
|
From: Andrea A. <aa...@op...> - 2009-01-27 08:03:57
|
Jody Garnett ha scritto: > Andrea Aime wrote: >> It should be turned off completely. But judging from you comments >> there must be some misunderstanding. >> >> The two samples I've attached for each map are both drawn with >> antialiasing turned on. The one with "thin lines" is what >> we are drawing today, without me touching the code. > Okay I got it. >> The one with the thick lines is instead the code running >> without that old optimization. The SLD is exactly the same, >> but it should be easy to see that the rendered line is easily >> twice as thick. > My understanding is that the SLD is now being followed correctly right? Correct. We also have an issue with font height, as we specify the number we get directly to Font, whose size is not pixels, whilst SLD size is pixels, generally getting smaller fonts compared to MapServer which instead follows the spec. That will be another backward incopatible fix. >> Now what do you think will happen when uDig users discover all >> of their maps render differently, and they have no way to >> change them back? In GeoServer people can change the SLD >> to force a 0.5 pixels line width and they get pretty much >> the same result as before. > I am going to hide behind the SLD specification for a bit; and apologize > for the earlier mistake. > however I would like to confirm that non integral widths are allowed. In our code they are. Schema wise there are no restrictions as CSSParameter can be anything (mixed mode with embedded expressions). But yeah, the SDL 1.0 standard says (page 36): The “stroke-width” CssParameter element gives the absolute width (thickness) of a stroke in pixels encoded as a float So yeah, it's possible to specify a non integral number. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Jody G. <jod...@gm...> - 2009-01-27 09:04:55
|
Andrea Aime wrote: > Correct. We also have an issue with font height, as we specify > the number we get directly to Font, whose size is not pixels, > whilst SLD size is pixels, generally getting smaller fonts compared > to MapServer which instead follows the spec. That will be another > backward incopatible fix. I think I have already supplied some font height manipulating code in uDig to account for some of these issues (we needed to account for it when working with the printed page where high DPI makes the font height in pixelsapproach look pretty silly. >>> the same result as before. >> I am going to hide behind the SLD specification for a bit; and >> apologize for the earlier mistake. >> however I would like to confirm that non integral widths are allowed. > In our code they are. Schema wise there are no restrictions as > CSSParameter can be anything (mixed mode with embedded expressions). > But yeah, the SDL 1.0 standard says (page 36): > > The “stroke-width” CssParameter element gives the absolute width > (thickness) of a stroke in pixels encoded as a float > > So yeah, it's possible to specify a non integral number. Thanks; I can also make the "default" style for uDig line work to be 0.5 if needed; and add 0.5 to the list of pre-canned options in the combo box. Cheers, Jody |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X