Standing on the shoulders of giants :) -- John
> On 2 Mar 2014, at 02:57, Tilman Hausherr <[email protected]> wrote: > > 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 >
