[OpenJDK 2D-Dev] RFR: 8242004: TextLayout throws Exception with a non-invertible transform

[Philip Race]

Oh and if you do draw it, it still goes through the GV path so nothing 
should draw there.

This is what I meant by :
 > Subsequent rendering of the TextLayoutwill be handled by the other 
checks being added.

The shape returned might be not be null but I don't think you'll get 
more than a line ..

-phil.

On 4/10/20, 12:57 AM, Philip Race wrote:
>
>
> On 4/9/20, 10:26 PM, Jayathirth D v wrote:
>> Hi Phil,
>>
>> I went through all use cases captured in test case (TextLayout, 
>> drawXXXX).
>>
>> With updated change there is difference in behaviour between how we 
>> interpret non-invertible transform between TextLayout.draw() and 
>> drawXXXX() API’s.
>> In case of TextLayout.draw() we are overriding non-invertible 
>> transform and allowing text rendering to happen, but in case of 
>> drawXXXX() we just return and doesn’t allow text rendering to 
>> continue. Is it okay to have this difference in behaviour?
>
> It becomes tricky.
> Do you have a suggestion ?
> Remember that the TextLayout is returned and does not have to be 
> drawn, but could be
> by both drawing it directly or asking for the outline shape and 
> rendering that.
> It can also be queried for the layout etc. There needs to be something 
> returned that
> does not cause other problems. And patently there can't be apps that 
> would care because
> today they can't get that far.
> And there's no defined behaviour in this case.
>
> So if you have specific code suggestions ..
>>
>> Also in test case its better if we continue to test all use cases and 
>> then fail instead of failing at first instance and added test case 
>> needs change in Copyright year from 2015 to 2020.
>
> oops.
>
> -phil.
>
>>
>> Thanks,
>> Jay
>>
>>> On 10-Apr-2020, at 7:53 AM, Philip Race <philip.race at oracle.com 
>>> <mailto:philip.race at oracle.com>> wrote:
>>>
>>> D**n copy/paste, yes you correctly inferred the webrev is at
>>> <cr-url>/<my openjdk id>/<bugid> ie : 
>>> http://cr.openjdk.java.net/~prr/8242004/ 
>>> <http://cr.openjdk.java.net/%7Eprr/8242004/>
>>>
>>> -phil.
>>>
>>>
>>> On 4/9/20, 7:00 PM, Jayathirth D v wrote:
>>>> Hi Phil,
>>>>
>>>> Please share webrev link, you have added JBS link for webrev.
>>>> I went to path where you usually share webrev's and found 
>>>> http://cr.openjdk.java.net/~prr/8242004/ 
>>>> <http://cr.openjdk.java.net/%7Eprr/8242004/>
>>>>
>>>> Thanks,
>>>> Jay
>>>>
>>>>
>>>>> On 10-Apr-2020, at 12:49 AM, Philip Race <philip.race at oracle.com 
>>>>> <mailto:philip.race at oracle.com>> wrote:
>>>>>
>>>>> Any takers ?
>>>>>
>>>>> -phil
>>>>>
>>>>> On 4/3/20, 1:29 PM, Philip Race wrote:
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8242004
>>>>>> webrev: https://bugs.openjdk.java.net/browse/JDK-8242004
>>>>>>
>>>>>> Several code paths can end up in the method shown in the bug report
>>>>>> with a non-invertible transform.
>>>>>>
>>>>>> As much as possible, we can prevent them reaching here by 
>>>>>> checking in the rendering code.
>>>>>>
>>>>>> If we do get here, which should now be possible only when 
>>>>>> directly creating
>>>>>> a TextLayout, we can use a default TX. Subsequent rendering of 
>>>>>> the TextLayout
>>>>>> will be handled by the other checks being added.
>>>>>>
>>>>>> A regression test is provided which checks various APIs to make 
>>>>>> sure no
>>>>>> exception is thrown.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200410/0d472b9a/attachment.htm>