> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(x20 time faster) with use of
>
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(x20 time faster) with use of
>
On Tue, 3 Aug 2021 22:03:54 GMT, Sergey Bylokhov wrote:
>
> I am fine to do that, if there are no objections I can change the whole fix.
Modifying the entire changeset seems like an overkill.
Using static imports in only one file is _inconsistent_, yet it makes the
places where the encodings
On Tue, 3 Aug 2021 21:54:08 GMT, Alexey Ivanov wrote:
>> it is aligned already, the StandardCharsets.UTF_8 is parameter of "new
>> String()", not the getTransferData.
>
> Ah, right!
> But it's confusing: it looks as if `StandardCharsets.UTF_8` is a parameter to
> `getTransferData`. Maybe avoid
On Tue, 3 Aug 2021 21:18:40 GMT, Alexey Ivanov wrote:
>> Sergey Bylokhov has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains two additional
>>
On Tue, 3 Aug 2021 19:37:04 GMT, Sergey Bylokhov wrote:
>> This is a request to clean up a desktop module as was done in JDK-8233884
>> for "java.base" module.
>>
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>>
>> This
On Tue, 3 Aug 2021 19:53:22 GMT, Sergey Bylokhov wrote:
>> Looks like making MTLLayer opaque by default require much more time that I
>> expected. I tried different things to resolve artefacts that I mentioned
>> before but nothing seems to work. So, I suggest to stick with my latest
>>
On Tue, 3 Aug 2021 06:46:07 GMT, Alexey Ushakov wrote:
>> I need to look at it closely, I do not understand why we made the native
>> layer opaque=NO by default while the java code uses opaque=true by default.
>> And then we reset the native code from NO to yes by the code above. Why we
>>
On Tue, 3 Aug 2021 19:51:30 GMT, Alexey Ushakov wrote:
>> Yes, sounds reasonable. Moreover, It was my initial attempt but I faced with
>> some regressions in SwingSet2 demo. In some cases background of tree nodes
>> become black and this artifact was reproducible only if some other tabs were
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(x20 time faster) with use of
>
On Tue, 3 Aug 2021 09:11:07 GMT, Jayathirth D V wrote:
>> We are incorrectly passing source offset to ImageInputStream.readFully()
>> which is getting used on destination buffer. streamPos maintained in each
>> implementation of stream maintain's appropriate source offset while reading
>> the
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be
On Tue, 3 Aug 2021 13:30:28 GMT, Alexander Zvegintsev
wrote:
>> This is a request to clean up a desktop module as was done in JDK-8233884
>> for "java.base" module.
>>
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>>
>>
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be
> We are incorrectly passing source offset to ImageInputStream.readFully()
> which is getting used on destination buffer. streamPos maintained in each
> implementation of stream maintain's appropriate source offset while reading
> the data. Since we are completely utilizing destination buffer
On Sat, 24 Jul 2021 03:17:11 GMT, Sergey Bylokhov wrote:
>> We are incorrectly passing source offset to ImageInputStream.readFully()
>> which is getting used on destination buffer. streamPos maintained in each
>> implementation of stream maintain's appropriate source offset while reading
>>
On Mon, 2 Aug 2021 21:53:02 GMT, Sergey Bylokhov wrote:
>> Yes, and we need this call here to initialise content view with correct
>> default value
>> CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque);
>
> I need to look at it closely, I do not understand why we made the
18 matches
Mail list logo
