> On 04 Oct 2016, at 23:22, Jim Graham <james.gra...@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
