Hi Mikael,
[EMAIL PROTECTED] wrote:
I don't know what to say. You go to great length explaining why circles aren't
round and why the corner radius on rounded rectangles are different on the
different sides, and why you will not fix it. I guess other platforms (Flash,
.NET and similar) also have these problems since they aren't fixable?
Actually, I wasn't sure - I just know that the rendering models that we
use are fairly industry standard and there are well-known techniques for
working around them, some can be implemented as heuristics within the
rendering engine (along with a way to turn them off since they aren't
always right) and we've done that, and others have to be implemented as
"care in how one constructs rendering requests".
I know that we've exercised about as much "magic" as we know how to
exercise internally here in the implementation in the heuristics we
created for path normalization, but I believe there could be more
"magic", it just isn't something we have sitting in our back pocket and
it can't be summoned up on command like a "bug fix" normally can. This
isn't a case of "whoops, we forgot to increment that variable" or "we
should probably keep more bits of resolution here", this is a limitation
of how advanced a set of heuristics we know how to create.
And, like I said, I wasn't totally sure about Flash - but I went and
downloaded it and played around with it for a few hours and discovered
that, basically, they use a rendering model that is fairly close to what
we've implemented - very close to the industry standard. If you render
small circles with Flash you get fuzzy outlines on the circles. If you
enable their form of "stroke hinting" then you get lopsided un-round
(but still fuzzy) circles. At least in our case I believe the circles
tend to be crisp (or at least our heuristics try to keep them crisp)
even though they are lop-sided. The "hinted" circles I saw with Flash
were neither crisp nor were they round.
I then tried a few more experiments and found that many of the issues
that people complain about with respect to Java2D rendering are exactly
the behaviors that Flash produces (and they have some problems that we
don't as well).
I haven't done the same experiment with .NET, but in either case - if
you have output from some other rendering engine that does what you want
then please share a real-world example, rather than "guessing" about the
other platforms.
It turns out that it is too hard to do Java2D graphics in a high fidelity way,
at least without resorting to hacks.
And are you sure that it is possible with other systems? I'd like to
see some examples.
Another problem I have is that one can not in Java2D in a generic way outline
and fill a Shape and make it look good. The outline will plot outside and
inside the shape depending on the direction of the vector (in degrees). This is
since you don't provide an INSIDE and OUTSIDE stroke. You have the hanging
right/left stroke and the pure stroke.
Flash provides a very similar rendering model. When you draw 1 pixel
wide strokes at 1:1 scales you get the same "hanging pen" strokes that
we render.
The pure stroke isn't usable since you either get the lines sharing two pixels
for vertical and horizontal lines or you do as you suggest and translate 0.5,
in which case you get good lines but shapes that are one pixel too big.
You get the "one pixel too big" problem with Flash too. The stroke
follows the outline and straddles the path - therefore the stroked
version will always be "linewidth" larger than the filled stroke.
One CAN solve the
one-pixel-too-big-shapes-when-using-PURE-and-translate.5-problem by scaling the
output with ((width - 1.0)/width) but that only works for rectangles (shapes
with equal but mirrored quadrants actually, so also for circles) but fails for
general paths, polygons and composite shapes of all kinds.
Scaling the output isn't a very general solution and can be tricky to
get right with oblong shapes - even if they are convex - as you say.
Other techniques for handling stroking involve things like:
- stroke then fill
(even widths == symmetric border)
(odd widths and STROKE_NORMAL == uneven border)
(odd widths and PURE == fuzzy symmetric border in AA)
- fill then stroke
(misalignment of stroke at odd sizes is hidden
behind the stroke)
- use linewidth=2x and stroke then fill
(gives a 1 pixel "outer/halo stroke",
but needs a fill to carve out the stroke)
- use linewidth=2x and compute [strokeShape SUB Shape]
(gives a 1 pixel "outer stroke shape")
- use linewidth=2x and intersect strokeShape and Shape
(gives a 1 pixel "inner stroke shape")
This problem has shown to unsolvable in a generic way. Only if one has prior
knowledge about what type of shape to paint and are in full control of the
rendering hints can one get good results for some types of shapes. You can not
create an API that takes a Shape, a fill and stroke color and do a decent job
painting those at some coordinates.
This is exactly why it is hard to come up with a heuristic that we can
implement for you. It seems that you understand the complexity of the
problem, but somehow perceive that what is "unsolvable" for you is "just
a bug fix" for us. I'm sorry to say that it isn't true. When you use
the PURE stroke hint you are getting the mathematically ideal rendering
and if it doesn't hit the pixels you want then change the geometry you
are using. You'd have to do this with most rendering systems -
professional or free - that I am familiar with.
Problems like these have appeared with tools like Illustrator for a long
time and the community has built up "strategies" and "techniques" for
creating artwork that agrees with the rendering models. The "hinting"
heuristics help in some common cases so that most programmers/designers
don't have to get involved in these strategies, but eventually everyone
outgrows the heuristics and needs more control.
If you (as in Sun) are sincere in your efforts to take on Flash and Silverlight
these kinds of rendering issues must be solved IMO. Given your stance as
explained above I guess they won't be until it's too late though. :(
We are sincere. You seem to feel that we lag Flash, but it seems to use
the same rendering model that we do so I'm not sure how we are lagging
there...? Do you have specific issues and examples?
...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".
