Hi John,
Thanks, now you won't have to rewrite AWT :-) anyway, your tiling code
is close to perfection already. I'm confident that the rest will be
solved soon. This tiling part is an interesting programming "story":
Andreas started, then I did a bit, then you did a bit and each time it
improved.
And yes, the transformations are tricky :-(
Tilman
Am 28.02.2014 20:12, schrieb John Hewson:
Tilman, you are correct.
I wrote a standalone program to test the capabilities of AWT Paint without any
other
factors which would cause confusion. Some of the problems I was encountering
seem to be related to the pixilation bugs we saw with shadings which were caused
by Java 1.6.
My experiments with AWT Paint using Java 1.7 show that my initial hypothesis
that
PaintContext#getRaster always results in bitmap scaling after drawing is
*wrong*.
It is quite possible to draw crisp images using AWT taking into account the CTM
which is provided by the AffineTransform passed to getContext.
I’m working on getting the transforms right in my code. The main difficulty is
that its
easy to confuse the pattern matrix with the CTM (AffineTransform) or produce
some
sequence of transforms which works for the examples at hand but is actually
broken.
-- John
On 26 Feb 2014, at 23:14, Tilman Hausherr <[email protected]> wrote:
I still disagree, simply because I was able to render these images without the
effect. I haven't looked at your code yet, but my understanding is that the
problem you describe is solved by an AffineTransform passed in one of the paint
classes, which results in having to paint much more. Thats also the reason that
the shading images are not blocky at high resolutions, and take much longer.
Tilman
Am 25.02.2014 00:32, schrieb John Hewson:
I’ve given the current implantation of tiling patterns an overhaul so that it
supports uncoloured tilings
and to simplify the existing code.
However, the scaling issues are not resolved. I’ve use the same approach to
scaling the pattern as
in Tilman’s patch, it is indeed correct to apply the CTM to the new page.
However, the issue with AWT
paint cannot be resolved. The issue is that AWT calls PaintContext#getRaster(x,
y, w, h) with the same
values irrespective of the DPI which we are rendering at. So, when we render a
page at 144dpi AWT is
asking its PaintContext to generate a raster at 72dpi and then it is upscaling
it to 144dpi, which causes
it to become pixelated.
To confirm that AWT is the problem I created custom PaintContext which returned
a raster with alternating
red and black 1px stripes. When rendering at 72dpi the stripes are 1px wide,
but when rendering at 144dpi
the stripes are 2px wide, meaning that the raster was upscaled by AWT after it
was rendered.
-- John
On 24 Feb 2014, at 13:54, Tilman Hausherr <[email protected]> wrote:
You have been using the version of the trunk, which has a scaling problem. If
you use my proposed patch it looks much better (see the images I attached). I
didn't check it in because Andreas had assigned the issue to himself. I might
do it after having updated my local version to the current trunk, unless there
is protest.
Tilman
Am 24.02.2014 20:45, schrieb John Hewson:
Hi All
There’s been lots of work recently on shading and tiling patterns and I’ve been
testing out some
of the new rendering capabilities. However, I think I’ve discovered a
fundamental problem with
using AWT’s PaintContext for drawing.
I noticed that the PDF from PDFBOX-1094 looks fine when rendered at the default
72dpi however
if I render it at 144dpi then the tiling patterns appear pixelated. As
expected, RenderUtil creates a
proportionally larger BufferedImage to render to and then calls
graphics#scale(x,y) so that everything
drawn to the graphics is scaled. This seems to work as expected for vectors and
drawImage, we get
nice crisp graphics at large scales. However, for our custom PaintContext
classes we get pixellated
graphics.
I decided to instrument the calls to ColoredTilingContext#getRaster(x, y, w, h)
at 72 and 144 dpi to see
if the problem is caused by up-scaling of paint *after* it is rendered to a
raster. This is indeed, the cause
and I observed the following calls for the PDFBOX-1094 file:
72 DPI
----------
x y w h
getRaster 302 586 76 76
getRaster 396 586 76 76
getRaster 344 662 86 86
getRaster 340 623 94 82
getRaster 302 317 76 76
getRaster 396 317 76 76
getRaster 344 393 86 87
getRaster 340 355 94 82
144 DPI
—————
x y w h
getRaster 302 586 76 76
getRaster 396 586 76 76
getRaster 344 662 86 86
getRaster 340 623 94 82
getRaster 302 317 76 76
getRaster 396 317 76 76
getRaster 344 393 86 87
getRaster 340 355 94 82
Perhaps there is some rendering hint or Graphics setting we’re not aware of? If
not we will have to migrate
away from using PaintContext and do the painting ourselves using a clipping
path. :-(
-- John
