feat: Introduce RCTUIImage (2/2) #2766
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Saadnajmi
force-pushed
the
borders-shadows
branch
2 times, most recently
from
cf2a071 to
3ffb7f9
Compare
Saadnajmi
force-pushed
the
borders-shadows
branch
2 times, most recently
from
3aea85d to
9981fbb
Compare
Saadnajmi
changed the title
Saadnajmi
added a commit
that referenced
this pull request
Dec 23, 2025
## Summary: This PR is split out from #2766 to help make it smaller. Previously we had the code `@compatibility_alias UIImage NSImage` which is basically an objective C runtime way of doing `#define UIImage NSImage`. We don't quite like this, since we are defining the symbol `UIImage` in an Appkit context. We have a better pattern we can copy from RCTPlatformView --> RCTPlatformImage. The `RCTPlatform` prefix basically means it's NS<blah> on Appkit and UI<blah> on UIKit. This is as opposed to something like RCTUIView, where on iOS it's a typedef, but on macOS it's a subclass that adds stuff to NSView to make it more compatible with UIView. All in all, this should mostly be a rigorous find/replace to make the code slightly more strict, but have no behavioral changes ## Test Plan: RNTester runs locally.
Saadnajmi
force-pushed
the
borders-shadows
branch
2 times, most recently
from
1092a5f to
96efd22
Compare
Saadnajmi
force-pushed
the
borders-shadows
branch
from
96efd22 to
903a82d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Needs #2783 to merge first.
Resolves #2738
There were a couple of issues with our macOS image rendering code that caused borders and shadows to not render properly in Fabric:
UIGraphicsImageRendereron macOS (RCTUIGraphicsImageRenderer) called[NSImage imageWithActions:flipped:drawingHandler], which would not render the imade right away but instead when it's about to be displayed (presumably so that it can generate a properCGContextfor the screen the image is on). This meant that CGImage bitmap would sometimes just return as0x0NSImageunlikeUIImagedoes not have aCGImageproperty, so we used the methodCGImageForProposedRect:to get one. Unfortunately, that returns an autoreleased CGImage, and when we later set that to RCTViewComponentViews'layer.contents, it would not be retained.This manifested as borders and shadows not rendering, or rendering and then dissapearing on a resize.
To fix the first issue, apparently we can just call
[image lockFocus]and[image unlockFocus]in succession to force it to render a bitmap.To fix the second issue, we need some way to cache the CGImage. I propose a new class:
RCTUIImage.RCTUIImage, likeRCTUIViewis a subclass ofNSImagewith some extra properties and methods to make it more compatible with iOS code. In our case, we add the extra code to cache a CGImage, with proper retain and release calls. We can then haveRCTUIGraphicsImageRendererreturn our new subclass, and update all callers appropiately. The end result it we can actually remove some diffs, and have our macOS image handling behave closer to iOS.While doing this work, I realized our
NSImage/UIImageshims were kinda messy, and with the new subclass to introduce weird runtime edge cases. I split out #2783 to help clean up and clarify what image class we're using in the rest of the codebase.Test Plan:
RNTester seems better :)
Screen.Recording.2025-11-26.at.3.39.04.PM.mov