For 1.3 beta we added new parameters to the BasicStroke constructors
to allow the developer to control the bias of the center of the pen
with respect to the line being stroked.
For 1.3 FCS we believe that we should remove these constructurs for
reasons given below. (To summarize - they didn't solve the problem
we thought they would solve and there is no reason to add new APIs
with no known use.)
While beta APIs are subject to change without notice, I wanted to find
out if anyone was using those constructors for any constructive purpose
before we delete them for FCS. Please respond (to me) if you are using
these new constructors.
As to the reasons:
BASICSTROKE NOW IMPLEMENTED TO SPEC
In 1.3 we've finally implemented the 0.5 coordinate user space offset
that we originally spec'd for all BasicStroke operations. We did this
by adding the offset parameters to the BasicStroke class and then
defaulting them to (0.5, 0.5).
The benefits and tradeoffs were what we expected - consistent registration
of simple default fills and strokes to screen, antialiased, and to printer.
In various releases of 1.2 we had implemented this hard-coded offset in
some, but not all of the rendering pipelines so the different pipelines
were inconsistent and not compliant with the spec which stated that
BasicStrokes would be offset by 0.5 user space coordinates from their
paths.
In 1.3 we not only fixed the consistency problem, but added the ability
of the developer to control this offset if they should be unhappy with
the defaults or want to create some special stroking effect.
Note that in 1.3 Beta we added the parameters but gave them a default
of (0, 0) which means that they had no effect. Since then, we fixed the
default to be (0.5, 0.5) according to the original spec of the 2D
API, but this turned up a problem.
THE PROBLEM - BACKWARDS COMPATIBILITY
During the 1.2 development cycle, some of the pipelines implemented the
0.5 user space coordinate offset and some of them didn't. There were
some messages here on this list that complained about this inconsistency.
The fact that this was inconsistent was an annoying bug that we fixed
when we added the new parameter - now they all implement it uniformly.
Unfortunately, while the implementation was inconsistent during the
various releases that occured during the 1.2 development cycle, there
was one thing that was consistent. When 1.2 finally reached FCS (and
later with 1.2.2), it turned out that none of the pipelines implemented
the offset in user space any more. They were still inconsistent, but
they were inconsistent with whether they offset the line by half a
device pixel, not 0.5 user space coordinates.
Also, we have some test cases submitted with other bug reports whose
behavior drastically changes with the new system and its defaults. The
test cases usually establish a very large scale factor and then use very
small line widths and very small coordinates to do all of the rendering.
A typical example of this would be to scale the entire window to a
coordinate system of (0.0, 0.0) to (1.0, 1.0) and then just deal with
one set of coordinates that spans the window regardless of size.
The net effect for these test cases and anyone else using large scales
for rendering is that the 0.5 user space coordinate shift (that works
well on the screen and printer with line widths of 1) instead moves the
highly scaled lines by a large amount. For one test case that was using
a scale factor of 10000 and a line width of .003, the lines no longer
appeared on the screen at all.
This is a serious change in backwards compatibility that cannot be
justified by a shift towards consistency since it is consistent with
none of the FCS behaviors. (If any of the pipelines had still used
the 0.5 user space offset in FCS, it might have been arguable.)
A BETTER (MORE COMPATIBLE) SOLUTION
In order to preserve compatibility with 1.2.2, we will have to eliminate
the 0.5 user space coordinate offset from BasicStroke (at least by default).
But, what to do about keeping consistency between antialiased and non-
antialiased rendering?
Instead we are planning to implement a more intelligent "stroke normalization"
behavior that adjusts the endpoints of lines to the nearest pixel center (or
some other standardized offset within the pixel) to improve the consistency
of lines on the screen. Both antialiased and non-antialiased lines will
have approximately the same look (the non-antialiased lines will not
suddenly fade out to twice their width and half their opacity). But,
the registration of outlines and filled objects will look noticeably
different between the screen and the printer since the normalization
is happening at the device space level. It is also very compatible with
the 1.2.x behavior and it doesn't annoy people working with large scales.
Since the BasicStroke object, via its Stroke interface, is only allowed
to deal with user-space coordinates, we can't implement this new facility
as a generic adjustment performed by the BasicStroke object. Instead
this will have to be a built-in facility (for now) performed by the
various renderers themselves. Thus, the best way to control this new
facility will be with a RenderingHint, but we are still fighting to get
the API change (to add the hint constants) approved for the 1.3 final release.
BACK TO THE QUESTION AT HAND
So, the original purpose of this email was to find out if the BasicStroke
offset parameters that we added in 1.3 beta are useful to anyone.
Since they are no longer a part of the solution of rendering consistency
and since they mildly complicate the issue of performing intelligent
stroke normalization, we believe that things would be better off if we
just deleted them for 1.3 final.
Any objections?
...jim
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
