There was refactoring in WebKit's GraphicsContext class (nativecode)
https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63
GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't
adapted after GraphicsContext's refactoring integration into JFX. As t
Context's refactoring integration into JFX. As the
> result, the methods were not invoked, so TransparencyLayer couldn't be added
> to a rendering queue.
>
> Now the methods are fixed to be used properly in GraphicsContext inheritance
> chain.
Roman Marchenko has updated
On Wed, 11 Jan 2023 07:32:20 GMT, Roman Marchenko
wrote:
> There was refactoring in WebKit's GraphicsContext class (nativecode)
> https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63
>
>
> GraphicsContextJava's methods begin/endPlatformT
On Wed, 11 Jan 2023 07:49:50 GMT, Roman Marchenko
wrote:
>> There was refactoring in WebKit's GraphicsContext class (nativecode)
>> https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63
>>
>>
>> GraphicsContextJava's met
Context's refactoring integration into JFX. As the
> result, the methods were not invoked, so TransparencyLayer couldn't be added
> to a rendering queue.
>
> Now the methods are fixed to be used properly in GraphicsContext inheritance
> chain.
Roman Marchenko has updated
On Wed, 11 Jan 2023 16:24:04 GMT, Kevin Rushforth wrote:
>> Roman Marchenko has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains one commit:
>>
>> Fixed the opacity issue
>
> I might add it elsewhe
Context's refactoring integration into JFX. As the
> result, the methods were not invoked, so TransparencyLayer couldn't be added
> to a rendering queue.
>
> Now the methods are fixed to be used properly in GraphicsContext inheritance
> chain.
Roman Marchenko has updated
Context's refactoring integration into JFX. As the
> result, the methods were not invoked, so TransparencyLayer couldn't be added
> to a rendering queue.
>
> Now the methods are fixed to be used properly in GraphicsContext inheritance
> chain.
Roman Marchenko has updated
On Wed, 11 Jan 2023 07:32:20 GMT, Roman Marchenko
wrote:
> There was refactoring in WebKit's GraphicsContext class (nativecode)
> https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63
>
>
> GraphicsContextJava's methods begin/endPlatformT
All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr
[esi+0x30], xmm0`".
"`movaps`" must operate with aligned addresses as
> When the source or destination operand is a memory operand, the operand must
> be aligned on a 16-byte boundary or a general-protection exception (#G
dress 0x`" from `hs_err` file
> implicitly says it is GP, not a real "reading address 0x".
>
> It might be related to clang-cl bug, see
> https://github.com/llvm/llvm-project/issues/55844
>
> The workaround is to disable SSE when building 32bit on Windo
On Tue, 8 Apr 2025 15:49:44 GMT, Roman Marchenko wrote:
>> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr
>> [esi+0x30], xmm0`".
>>
>> "`movaps`" must operate with aligned addresses as
>>> When the
On Tue, 8 Apr 2025 07:48:19 GMT, Roman Marchenko wrote:
> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr
> [esi+0x30], xmm0`".
>
> "`movaps`" must operate with aligned addresses as
>> When the source or destinati
13 matches
Mail list logo
