Andrew,
How did you choose 165 as the OS X default value ?
Was it through experimentation or was there some documentation?
On other platforms we read the value from system settings.
Can we find this information on OS X ?
-phil.
On 07/15/2015 07:32 AM, Andrew Brygin wrote:
Hello,
could you p
It seems you are making an assumption that the code that creates the image is
somehow initiated from a paint method so that the display scale factor can be
obtained from the graphics context and used to determine the required image
resolution. That is not the scenario I am concerned about.
I am
I am commenting on your suggestion that I can determine which display the image
will displayed on.
> On Jul 15, 2015, at 7:42 AM, Alexander Scherbatiy
> wrote:
>
> On 7/15/2015 5:09 PM, Alan Snyder wrote:
>>
>> It seems you are making an assumption that the code that creates the image
>> i
This probably needs more examination and perhaps a more complex fix.
The observation that GDI bases bold-italic on the bold version not the
italic version is an implementation choice just as we had done the
opposite. It is possible some other time it does the opposite or some
other platform does t
On 7/15/2015 5:09 PM, Alan Snyder wrote:
It seems you are making an assumption that the code that creates the
image is somehow initiated from a paint method so that the display
scale factor can be obtained from the graphics context and used to
determine the required image resolution. That is
Hello,
could you please review a fix for 8098853?
bug: https://bugs.openjdk.java.net/browse/JDK-8098853
webrev: http://cr.openjdk.java.net/~bae/8098853/9/webrev.00/
By default, we use 140 as lcd contrast value. However, on macosx
this value causes significant discrepancy with results of nati
Hello,
could you please review a fix for 8078382?
bug: https://bugs.openjdk.java.net/browse/JDK-8078382
webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/
The problem is caused by following peculiarity of the Code New
Roman font: this font provides plain, italic and bold variants.
On 7/14/2015 3:18 AM, Alan Snyder wrote:
I have a concern about how custom multiresolution images are supported based on
a problem I ran into using the JDK 8 classes, which are similar.
The problem is that the selection of a variant image happens during painting.
That is a very bad time to act
Hello Phil,
the fix looks fine to me.
Thanks,
Andrew
On 7/15/2015 1:37 AM, Phil Race wrote:
If a child raster is created with a non-zero x-offset then
subsequently in the code that validates the raster for
imaging operations we may incorrectly calculate that
the image exceeds the data buffer.
