Ivan,
Are you available anytime soon to talk about this or should I wait for
the next GNUstep monthly meeting?
Thanks,
Ethan C
On 12/20/24 12:11, Ethan C wrote:
Ivan,
We talked a bit about the CAAppKitBridge during the monthly meeting
last week, but I had to leave. Was there anything that you needed to
talk to me about it, and is there any more information you have on it?
Thanks,
Ethan Charoenpitaks
On 10/19/24 12:32, Fred Kiefer wrote:
Hi Ethan,
looks like there isn’t much interest in the CoreAnimation AppKit
bridge. As far as I remember Ivan mentored the GSoC student. I was
only involved after the project to see what is actually working. What
I remember is that I fixed some RGB bug and removed much of the data
copying that happened in Opal. And I don’t remember anything like
that Github gist that you linked.
So nobody will resolve the issue for you, but if you start to work on
it yourself I am willing to support you and I am sure Ivan will come
to help too.
Cheers,
Fred
Am 18.10.2024 um 00:49 schrieb Ethan C <[email protected]>:
Hi all,
Does anyone know anything about the status of the CAAppKitBridge?
Since CAAppKitBridge doesn't work, it prevents the porting of many
macOS applications, and it prevents Chameleon from building
(preventing us from having UIKit support on top of AppKit).
Thanks,
Ethan
On 7/24/24 12:01, Ethan C wrote:
Hi everyone,
A common topic that comes up is the completion of the
CoreAnimation-AppKit bridge. This is used by many macOS
applications, and is the main way that macOS apps do advanced
drawing and animations. I am interested in it because the app I am
porting, GitUp, requires it. CAAppKitBridge was the subject of a
2017 GSoC (Google Summer of Code) project by Stjepan Brkic:
https://gist.github.com/sbrki/efe8b94444946bde1bd3fa241071c8b2. He
said that there was a "mysterious bug in Opal" that prevented the
CAAppKitBridge from working:
<<< The issue is present during a call to
displaIgnoringOpacity:inContext: method on NSView. All the code in
that method works correctly. All the contexts that are eventually
passed to it are being used correctly. The issue may be that
something is "reseting" the global context to the context of the
window, thus rendering in the wrong place. The issue was followed
back to the DPSrectfill function inside of the Opal backend, where
it finally draws into the wrong context. >>>
He says he had more details on his blog, but his blog is no longer
accessible and I could not find it in any web scraper archives. If
anyone has any copies of his blog, or otherwise knows about this
bug, that'd be helpful. Additionally, is anyone else interested on
working on the CAAppKitBridge?
Thanks,
Ethan
