The first part means that if the scale is uniform in X and Y
(AffineTransform has some logic to determine this property in its
getType() method) then we can use X11 to do line widening by just giving
it a scaled line width. Also, X11 is limited to integer line widths so
we would only want to do this if the SPEED hint is specified (not
QUALITY) or if the scaled line width was close to an integer.
If we are going to use a software rasterizer to widen the line and then
send over spans to render, it may be faster to just give X11 the
original path and a scaled line width and ask it to widen the line.
Even if it uses a software renderer the reduction in protocol traffic is
a win, and their rasterizer is probably optimized for integer polygons
and may likely be faster than our more general curve-handling code.
But, I would rank this low on optimizations at this point...
...jim
Clemens Eisserer wrote:
Hi Denis,
In sun.java2d.x11.X11Renderer, line 340, it says:
// REMIND: X11 can handle uniform scaled wide lines
// and dashed lines itself if we set the appropriate
// XGC attributes (TBD).
Also, it is a known issue that Pisces does not support the STROKE_CONTROL
hint.
I have been wanting to implement these two features, and I have a few questions:
Has anything been decided on the first issue? Do we still want to implement it?
If yes, can anyone give me some rough suggestions as to how I can get started?
Its just my personal opinion, but I would recommend not implementing it.
Xorg falls back to software anyway for anything more complex than
solid rectangles and blits
and those code-paths will only be triggered for non-antialised
rendering with solid colors.
Implementing it in Pisces would help every backend OpenJDK supports :)
Just checked and I also ignore the STROKE_CONTROL stuff completly in
the cairo based Jules rasterizer.
Curious how that could be mapped to Cairo, do you know any more
in-depth explanation how it works - or examples how it should look
like?
Thanks, Clemens
