<AWT Dev> [9] Review Request: 7124417 [macosx] failure in Window.initGC on Mac with monitor sleeping

[Sergey Bylokhov]

On 3/19/14 10:43 PM, Anthony Petrov wrote:
> Why would there be a regression? Displays using hardware mirroring are 
> never included in the list by either CGGetActiveDisplayList or 
> CGGetOnlineDisplayList. So in this case the results should be the same 
> independent from the function used.
>
> Similarly, when using software mirroring, both functions return all 
> the mirrored displays. And again, there wouldn't be a regression from 
> just using another function.
>
> Please clarify what regression you're talking about.
On my system they return different results. In the mirroring 
CGGetActiveDisplayList returns only 1 device, but CGGetOnlineDisplayList 
returns 2.
>
> -- 
> best regards,
> Anthony
>
> On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
>> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>>> the new code that you're adding at lines 84-92 might be better
>>>>> integrated as a separate fix.
>>>> Before the fix we use CGGetActiveDisplayList, which returns only 
>>>> active
>>>> device w/o device in sleep or mirror state. The new function
>>>> CGGetOnlineDisplayList return all of them and we should filter out
>>>> mirror device.
>>>
>>> The specification of CGGetActiveDisplayList suggests that in the case
>>> of software mirroring the returned list includes all mirror devices.
>>> Therefore I still think that this is a separate bug.
>> You are right! It seems that on my system always a hardware mirroring is
>> used. But I am not sure that it is better to fix it in separate CR. If I
>> remove filtering then I'll introduce a new regression for hard
>> mirroring. Actually the fix is targeted to fix the problem in graphics
>> initialization and it fix that, No?
>>>
>>>
>>>>> 2. Before the fix, the list of display devices returned from
>>>>> getDisplayIDs was in the same order as reported by the native system.
>>>>> After your fix the order is reversed. For instance, if previously the
>>>>> main display was always at index [0], not it's always at the tail of
>>>>> the array. This may or may not be a problem for Java applications
>>>>> (likely not a serious problem). However, keeping the same order
>>>>> between Java and native APIs might be a good thing for debugging
>>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>>> preserve the order?
>>>> It is not necessary, because we store them in the Map on java side
>>>> anyway.
>>>
>>> Thanks for the clarification. This part looks fine then.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk 9.
>>>>>> After the fix we use screen in sleep state as normal screen, 
>>>>>> where we
>>>>>> can create new windows, etc.
>>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>>
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>>


-- 
Best regards, Sergey.