[Geoserver-devel] Removing an old rendering optimization

GeoServer GeoServer Developer
1

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@anonymised.com/3217765574/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/3217765474/sizes/o/

USA population, with hatch fills:
default: http://www.flickr.com/photos/29313339@anonymised.com/3216912511/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/3216912387/sizes/o/

Tasmania:
default: http://www.flickr.com/photos/29313339@anonymised.com/3217765504/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/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.

2

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@anonymised.com/3217765574/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/3217765474/sizes/o/

USA population, with hatch fills:
default: http://www.flickr.com/photos/29313339@anonymised.com/3216912511/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/3216912387/sizes/o/

Tasmania:
default: http://www.flickr.com/photos/29313339@anonymised.com/3217765504/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/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.

3

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@anonymised.com/3217765574/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/3217765474/sizes/o/

USA population, with hatch fills:
default: http://www.flickr.com/photos/29313339@anonymised.com/3216912511/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/3216912387/sizes/o/

Tasmania:
default: http://www.flickr.com/photos/29313339@anonymised.com/3217765504/sizes/o/
opt off: http://www.flickr.com/photos/29313339@anonymised.com/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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

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 :slight_smile:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

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.

6

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

7

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.

8

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

9

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.

10

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