[OpenJDK 2D-Dev] HiDPI support issues on Windows

[Anton Tarasov]

> On 04 Oct 2016, at 23:22, Jim Graham <james.graham at oracle.com> wrote:
> 
> On 10/4/16 1:01 PM, Anton Tarasov wrote:
>>> - Simply ask for a large enough integer to make sure you got the entire clip to fit in it and let the allocator give
>>> you an even larger image. It doesn't matter if you paint into a larger image (other than having to allocate an extra
>>> row/column on occasion). After that, as long as you set the translates and clip to exact pixel locations within the
>>> temp image, you should be fine.  You also have to deal with limiting your blit to the destination, probably using
>>> drawImage(dxy12, sxy12) variant
>> That's not quite clear, sorry. Are you talking about a scale-aware image? How does its size helps if we still
>> translate/clip?
> 
> Usually it isn't an issue if an image allocation mechanism returns a larger-than-necessary image for use as a temp image.  In fact, most places that use a temp image will keep an old image around and only reallocate it if it is too small, but reuse it if it is larger than needed.
> 
> In that case, we don't necessarily need to tell the image allocation mechanisms the exact pixel size of the image we want, we just need to make sure it returns an image with "at least" as many pixels as we need.  In that case, while it would be nice to be able to say specifically how many pixels we want, all that we need in a case like RepaintManager is to know what math it is doing so we can name a number that is large enough that it doesn't give us something too small.

Ok, I see, RepaintManager already caches images to perform intermediate drawing.

Thanks,
Anton.

> 
> On the other hand, things like setting the clip and setting the translation on the graphics and blitting the result to the destination - all of those will absolutely need a way for us to be pixel accurate in the numbers we provide...
> 
> 			...jim