You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Tilman Hausherr <TH...@t-online.de> on 2014/03/02 11:57:44 UTC
Re: Scaling issues with PaintContext
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 <TH...@t-online.de> 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 <TH...@t-online.de> 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
>>>>>
>>>>>
>
Re: Scaling issues with PaintContext
Posted by John Hewson <jo...@jahewson.com>.
Standing on the shoulders of giants :)
-- John
> On 2 Mar 2014, at 02:57, Tilman Hausherr <TH...@t-online.de> 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 <TH...@t-online.de> 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 <TH...@t-online.de> 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
>