denen, die mit Material Design und seinen Konzepten für Oberflächen, Beleuchtung
und Höhe geliefert wurden. Und falls Sie es noch nicht wussten: Compose nutzt viele der gleichen
Grafik-APIs wie das View-Framework, einschließlich derjenigen, die für die genannten
Schatten verantwortlich sind, sodass es den gleichen Fehler aufweist wie View< /code>s schon, zumindest vorerst.

Das ist ein FloatingActionButton, ein ExtendedFloatingActionButton und eine Karte
mit durchscheinendem Hintergrund, der den Defekt zeigt.
Aus Gründen, auf die ich hier nicht näher eingehen werde,* glaube ich das dort nicht ist
Keine geeignete Lösung dafür – d. h. ich glaube nicht, dass die Plattform eine
Methode oder Konfiguration bietet, um dieses Artefakt auszuschneiden oder auf andere Weise zu entfernen –,
so bleiben uns Problemumgehungen. Darüber hinaus besteht eine Hauptanforderung darin, dass die Schatten genau so aussehen, wie die Schatten auf der Plattform normalerweise aussehen würden, also jede Methode, die Schatten mit anderen Techniken zeichnet, wie etwa einem gleichmäßigen Farbverlauf oder einer Unschärfe oder so weiter nicht akzeptabel.
Können wir vor diesem Hintergrund eine robuste, allgemein anwendbare Lösung in Compose erstellen?
Ich persönlich bin auf einen Gesamtansatz zur Deaktivierung des gestoßen Originalschatten und
Zeichnung einer beschnittenen Replik an seiner Stelle. (Mir ist klar, dass Schatten nicht realistisch wirken, wenn einfach ein Loch
durchgestanzt wird, aber das scheint der
überwiegend erwartete Effekt zu sein.) Ich habe ein Beispiel der Compose-Version von
Dies in einer Antwort unten, aber die Hauptmotivation für diese Frage bestand darin,
nach besseren Ideen zu suchen, bevor diese in eine Bibliothek gestellt werden.
Ich bin mir sicher, dass es welche gibt technische Details in meinem Beispiel, die verbessert werden können,
Aber ich bin hauptsächlich neugierig auf grundlegend andere Ansätze oder Vorschläge.
Ich bin beispielsweise nicht daran interessiert, stattdessen irgendwie drawBehind() oder Canvas
zu verwenden im Wesentlichen das Gleiche tun oder Parameter umgestalten, nur um
den Inhalt einzufügen usw. Ich denke eher in die Richtung:
- Können Sie eine andere (leistungsstärkere) Möglichkeit finden, dieses Artefakt zu trimmen? ohne
ein separates Schattenobjekt zu erstellen und auszuschneiden? Bei Ansichtens bestand die einzige
Möglichkeit, die ich gefunden habe, darin, die Ansicht zweimal zu zeichnen, wobei der Inhalt in einer Zeichnung abgeschnitten
und der Schatten in der anderen deaktiviert wurde. Ich habe mich jedoch letztendlich dagegen entschieden,
aufgrund des Mehraufwands. - Kann dies in einen Modifikator extrahiert werden und Erweiterung, ähnlich den *GraphicsLayerModifiers undshadow()/? Ich habe mich noch nicht
Code: Select all
graphicsLayer()
vollständig mit allen Konzepten und Fähigkeiten von Compose beschäftigt, aber ich
glaube das nicht.
< li>Gibt es eine andere Möglichkeit, dies allgemein anwendbar zu machen, ohne
zusätzliche Verkabelung zu erfordern? Das Schattenobjekt in meinem Beispiel hängt von drei optionalen
Parametern mit Standardwerten aus dem Ziel-Composable ab, und mir fällt keine Möglichkeit ein, diese zu erreichen, außer das Ziel mit einem anderen Composable zu umschließen.< /p>
Klarstellungen:
- Es ist notwendig, die Transluzenz des Composable zu erhalten/ Transparenz, sodass
wir immer noch sehen können, was sich dahinter verbirgt. Das Festlegen einer undurchsichtigen Hintergrundfarbe funktioniert hier nicht. Das Artefakt muss repariert und nicht nur abgedeckt werden.
Wenn eine undurchsichtige Farbe für Ihr spezielles Setup funktionieren würde – z. B. wenn der zugrunde liegende Inhalt eine einzelne Volltonfarbe ist – Sie können einfach
die Funktion „Color#compositeOver()“ verwenden, um die undurchsichtige Farbe zu ermitteln, die sich ergeben würde, wenn Ihre durchscheinende Farbe mit der Farbe dahinter verschmilzt. - Bei dieser Frage geht es speziell um Material-Schatten, die
von Views/ geworfen werden.s, und die mit der Zeichenroutine auf dem Bildschirm und ihrem Zwei-Quellen-Beleuchtungsmodell zusammenarbeiten. Die Schattenebene von android.graphics.Paint ist ein separater Mechanismus, der nicht mit diesem Modell interagiert und daher keine materiellen Schatten erzeugt. Es handelt sich lediglich um das Zeichnen eines statischen,Code: Select all
RenderNode
einheitlichen Farbverlaufs, was oben als inakzeptabel erwähnt wurde, da er
völlig anders aussieht als die materiellen Schatten.
Wenn Paint für Ihr spezielles Setup geeignet wäre,
sind viele Beispiele bereits vor Ort verfügbar, wie die auf
dieser Frage. Es ist nicht nötig, sie hier zu wiederholen.