Microsoft-ui-xaml: ¿Por qué se debe descontinuar el acrílico de fondo en WinUI 3? Eso seguramente devastará y decepcionará a muchos, por razones obvias.

Creo que no es compatible temporalmente, mientras que la mayor parte del código que maneja Acrylic se elimina del sistema operativo y se codifica de nuevo en el proyecto de código abierto.

¿En serio? ¿Qué pasa con esto entonces? https://twitter.com/WithinRafael/status/1230192945355096064

Si bien no estoy seguro de a qué documento se refiere en la captura de pantalla, @ryandemopoulos dijo esto:
https://twitter.com/WithinRafael/status/1230197954280951808?s=20

Creo que el sistema operativo proporciona el telón de fondo que utiliza el pincel acrílico como capa subyacente, al que luego agrega las capas de ruido, tinte y luminosidad encima. El renderizador de la aplicación le da al Acrílico en la aplicación su capa subyacente.

El HostBackdrop no se puede hacer fuera del sistema operativo que proporciona la capa, por lo que encontrar una nueva forma de hacerlo es el desafío técnico que se menciona.

Esto probablemente requerirá una reingeniería del sistema operativo y, por lo tanto, también deberá adaptarse a todas las versiones del sistema operativo compatibles con WinUI 3.

Es posible que esto no suceda realmente y, en su lugar, es posible que el equipo de WinUI deba escribir un código de bajo nivel, que puede ejecutarse en el espacio del usuario, para replicar las mismas funciones.

No estoy seguro de cómo podrían hacerlo de otra manera, pero ciertamente no soy un programador adecuado, ni conozco el código fuente de Windows :) Solo que probablemente requiera acceso a UXTheme, que es un componente protegido del sistema operativo.

Ciertamente espero que lo consigamos para WinUI 3.1 en adelante, porque perder ese material visual sería devastador para el diseño de Fluent, y parece que Windows 10X ha encontrado una manera de hacerlo o las aplicaciones están llamando al espacio de nombres Windows.Xaml, lo que aparentemente no será posible desde las aplicaciones WinUI 3.x hechas por otros.

Si no recuerdo mal, las aplicaciones WPF pueden tener un fondo transparente. Dado que el cálculo real de un AcrylicBrush ya está (parcialmente) contenido en WinUI 2, el principal problema probablemente sea "solo" admitir este fondo transparente. Pero dado que las aplicaciones WPF pueden hacerlo, ya debería existir algún tipo de interfaz para eso.

Sin embargo, no puedo comentar cómo se implementará esto con WinUI 3, así que tome mi comentario con pinzas.

Si no recuerdo mal, las aplicaciones WPF pueden tener un fondo transparente. Dado que el cálculo real de un AcrylicBrush ya está (parcialmente) contenido en WinUI 2, el principal problema probablemente sea "solo" admitir este fondo transparente. Pero dado que las aplicaciones WPF pueden hacerlo, ya debería existir algún tipo de interfaz para eso.

Sin embargo, no puedo comentar cómo se implementará esto con WinUI 3, así que tome mi comentario con pinzas.

Si a la capa de Composición se le pudiera dar el "búfer de fotogramas" de la pantalla menos la ventana de la aplicación en sí, entonces seguro que se podría implementar un nuevo Pincel Acrílico. WPF se ejecuta con un sistema más permisivo de forma predeterminada, por lo que sospecho que es el lado UWP de la ecuación, el que tendrá más dificultades.

WinUI Desktop puede tener algunas soluciones alternativas que podrían permitirlo.

Una vez más, esperemos que no esté muy por detrás de WinUI 3.0

Por lo que recuerdo, las ventanas transparentes de WPF tampoco son nativas, están pirateadas en UpdateLayeredWindow, no usan renderizado directo sino que transfieren una imagen instantánea a través de una superficie GDI para cada cuadro renderizado. Probablemente cause muchos problemas técnicos para WinUI cuando intente mezclar este truco con la API de composición y las animaciones.

También está utilizando una representación alfa simple, creo que para el efecto acrílico necesita algún tipo de desenfoque, que necesita leer los píxeles de la superficie de fondo para mezclarlos.

Tampoco creo que haya ninguna instalación para entregar composiciones intermedias de la pantalla, por lo que antes de que WinUI pueda hacer algo aquí, el sistema operativo debe proporcionar una infraestructura completamente nueva.

En mi opinión, WinUI no debería lanzarse hasta que sea correcto. Algo como Acrylic Brush es vital para crear consistencia.

Estoy de acuerdo con ésto.

@Austin-Lamb para tu información

Si no se puede hacer correctamente, haga una versión falsa que lo emule hasta que se haga correctamente, y luego, cuando se actualice, seguirá apareciendo.

Eso sería mucho mejor que no tenerlo en absoluto.

Si no se puede hacer correctamente, haga una versión falsa que lo emule hasta que se haga correctamente, y luego, cuando se actualice, seguirá apareciendo.

Eso sería mucho mejor que no tenerlo en absoluto.

Sugerí esto en el pasado tomando el fondo de escritorio/color y usándolo como capa base. Pensé que sería bueno como respaldo para el modo tableta, móvil y para dispositivos de baja potencia.

Efecto acrílico inactivo (CreateHostBackDropBrush): opciones alternativas/retroceso

Ejemplo

_Acrílico actual_

_Falso acrílico alternativo_

Sería genial tener algo de claridad en esto. Es uno de los elementos visuales clave que hacen que las aplicaciones de Fluent sean reconocibles (y visualmente muy agradables de ver :)). Además, es uno de los efectos visuales más comunes en Windows con controles predeterminados que lo admiten desde el primer momento.

¡Esta característica debería estar en 3.0, o al menos en 3.1!

@niels9001 El equipo ha dicho que el acrílico HostBackdrop no estará en WinUI 3.0 debido a los desafíos técnicos que surgen al sacar los componentes de WinUI de la pila del sistema operativo. También dijeron que quieren que esto funcione en el futuro. No creo que actualmente puedan dar ninguna actualización nueva sobre esto.

Mientras tanto, sugeriría que comiencen los votos positivos sobre este problema (o un nuevo problema destinado al seguimiento) para que, cuando WinUI 3.0 esté disponible, el equipo pueda ver que esta es una función muy solicitada por la comunidad, por lo que es más probable que se agregue soporte más temprano que tarde después del lanzamiento de WinUI 3.0.

Mientras tanto, se debe usar uno falso como @mdtauk publicado.

Estoy de acuerdo.

Si no se puede hacer correctamente, haga una versión falsa que lo emule hasta que se haga correctamente, y luego, cuando se actualice, seguirá apareciendo.
Eso sería mucho mejor que no tenerlo en absoluto.

Sugerí esto en el pasado tomando el fondo de escritorio/color y usándolo como capa base. Pensé que sería bueno como respaldo para el modo tableta, móvil y para dispositivos de baja potencia.

Efecto acrílico inactivo (CreateHostBackDropBrush): opciones alternativas/retroceso

Ejemplo

_Acrílico actual_

_Falso acrílico alternativo_

Esto se ve muy bien, excepto que parece que le falta la capa de ruido. Corríjame si me equivoco.

Esto se ve muy bien, excepto que parece que le falta la capa de ruido. Corríjame si me equivoco.

Está ahí, aquí está la imagen ampliada al 800%

Gracias por plantear este problema @carmellolb. Creo que hablas en nombre de mucha gente, incluida la gente del propio equipo de WinUI, al expresar que Background Acrylic es una característica querida y una pieza muy importante de la historia de Fluent.

@mdtauk y @weltkante hicieron un excelente trabajo al describir los detalles técnicos de alto nivel sobre por qué esto es realmente difícil de hacer después de desvincularnos del sistema operativo. Como escribí en el canal #winui del servidor UWP Community Discord, mi esperanza es que podamos solucionar esto lo antes posible después de WinUI 3.0; No sé el marco de tiempo posterior a 3.0 porque tenemos más ingeniería de desarrollo que hacer para decidir cómo abordarlo. Pero es una pregunta importante y la comunidad ha dejado muy claro que les importa mucho esto. También me gusta la sugerencia de que exploremos algún tipo de "efecto falso" en el ínterin; quizás después de //build podamos comenzar a tener discusiones más profundas sobre esa idea.

@shaheedmalik , simpatizo con su sentimiento de no querer enviar hasta que las cosas estén 'bien'; A menudo me siento así y siempre es un acto de equilibrio. Hemos estado trabajando con muchos clientes en los últimos meses, y una cosa que recuerdo a menudo es que WinUI 3.0 proporcionará un camino viable para una amplia gama de aplicaciones UWP y Win32, y hay muchas que podrá usarlo sin depender del efecto específico que logra el acrílico de fondo. No quiero retrasar el desbloqueo de la amplia gama de funciones que 3.0 traerá para estos clientes, por eso sigo presionando para enviar 3.0 este año y luego busco resolver las piezas faltantes más importantes (como el acrílico BG) tan pronto como sea posible. posiblemente podamos después. Espero que tenga sentido.

@ryandemopoulos Si el elemento AcrylicBrush Xaml puede estar presente, incluso si solo devuelve algún tipo de relleno de pincel falso inicialmente. Los dispositivos en modo 10X, Xbox y Tablet se verán casi idénticos ya que no hay ventanas superpuestas. Es solo en los dispositivos con Windows 10 donde el efecto será obviamente falso, pero si es solo para un marco de inicio 3.0 o 3.1, antes de que se solucione, al menos no romperá el código y seguirá dando la sensación correcta.

Si esto se puede lograr para 3.0, entonces eso es genial. Será menos discordante que una alternativa de color sólido. También permitirá que el efecto no se deshabilite en dispositivos de baja potencia, o en modo tableta como sucede actualmente, lo cual es un paso adelante en mi opinión.

@shaheedmalik , simpatizo con su sentimiento de no querer enviar hasta que las cosas estén 'bien'; A menudo me siento así y siempre es un acto de equilibrio. Hemos estado trabajando con muchos clientes en los últimos meses, y una cosa que recuerdo a menudo es que WinUI 3.0 proporcionará un camino viable para una amplia gama de aplicaciones UWP y Win32, y hay muchas que podrá usarlo sin depender del efecto específico que logra el acrílico de fondo. No quiero retrasar el desbloqueo de la amplia gama de funciones que 3.0 traerá para estos clientes, por eso sigo presionando para enviar 3.0 este año y luego busco resolver las piezas faltantes más importantes (como el acrílico BG) tan pronto como sea posible. posiblemente podamos después. Espero que tenga sentido.

Luego, mientras tanto, se debe hacer una versión falsa del efecto hasta que se resuelva el efecto correcto. Los cambios incrementales de Fluent Design en el pasado llevaron al problema de inconsistencia actual que Windows 10 está experimentando actualmente. Si el objetivo de WinUI 3 es solucionarlo, entonces crear un problema como este anula todo el propósito de la coherencia. Aplicaciones con y sin acrílico es una de las mayores inconsistencias en Fluent Design.

@shaheedmalik , simpatizo con su sentimiento de no querer enviar hasta que las cosas estén 'bien'; A menudo me siento así y siempre es un acto de equilibrio. Hemos estado trabajando con muchos clientes en los últimos meses, y una cosa que recuerdo a menudo es que WinUI 3.0 proporcionará un camino viable para una amplia gama de aplicaciones UWP y Win32, y hay muchas que podrá usarlo sin depender del efecto específico que logra el acrílico de fondo. No quiero retrasar el desbloqueo de la amplia gama de funciones que 3.0 traerá para estos clientes, por eso sigo presionando para enviar 3.0 este año y luego busco resolver las piezas faltantes más importantes (como el acrílico BG) tan pronto como sea posible. posiblemente podamos después. Espero que tenga sentido.

Luego, mientras tanto, se debe hacer una versión falsa del efecto hasta que se resuelva el efecto correcto. Los cambios incrementales de Fluent Design en el pasado llevaron al problema de inconsistencia actual que Windows 10 está experimentando actualmente. Si el objetivo de WinUI 3 es solucionarlo, entonces crear un problema como este anula todo el propósito de la coherencia. Aplicaciones con y sin acrílico es una de las mayores inconsistencias en Fluent Design.

Estoy completamente de acuerdo. No creo que WinUI 3 deba lanzarse hasta que se resuelva algo.

De hecho, prefiero el respaldo estático de @mdtauk sobre la transparencia real. El acrílico de fondo solo distrae cuando se arrastran las ventanas, especialmente con un fondo de pantalla oscuro y un tema claro, y me llevó a deshabilitar la transparencia por completo.

Tal vez deberíamos reinterpretar los fondos de colores para elementos no transitorios (barras laterales, barras de título, conchas, etc.) como puras decoraciones, no como semitransparencias para simbolizar una breve interrupción. Esto sería más como los temas de la barra de título para MS Office o Firefox (o IIRC la barra lateral del centro de control de Vista). Cuando se ve de esta manera, tiene más sentido usar solo el fondo de pantalla.

Incluso podría verse mejor (¿y mejorar aún más el rendimiento?) hacer que el fondo de acrílico sea independiente de la posición de la ventana: el fondo de pantalla podría estirarse sobre el área de la ventana o recortarse en la esquina superior izquierda (o la esquina que tenga más sentido). para el comportamiento de cambio de tamaño de la aplicación).

De hecho, prefiero el respaldo estático de @mdtauk sobre la transparencia real. El acrílico de fondo solo distrae cuando se arrastran las ventanas, especialmente con un fondo de pantalla oscuro y un tema claro, y me llevó a deshabilitar la transparencia por completo.

Tal vez deberíamos reinterpretar los fondos de colores para elementos no transitorios (barras laterales, barras de título, conchas, etc.) como puras decoraciones, no como semitransparencias para simbolizar una breve interrupción. Esto sería más como los temas de la barra de título para MS Office o Firefox (o IIRC la barra lateral del centro de control de Vista). Cuando se ve de esta manera, tiene más sentido usar solo el fondo de pantalla.

Incluso podría verse mejor (¿y mejorar aún más el rendimiento?) hacer que el fondo de acrílico sea independiente de la posición de la ventana: el fondo de pantalla podría estirarse sobre el área de la ventana o recortarse en la esquina superior izquierda (o la esquina que tenga más sentido). para el comportamiento de cambio de tamaño de la aplicación).

Todavía usaría la superficie del pincel como una máscara para que el fondo permanezca alineado con el escritorio y permanezca en su lugar mientras la ventana se mueve y cambia de tamaño. Simplemente no incluiría ninguna de las ventanas visibles, solo el fondo de pantalla.

Esto también tendría que funcionar con fondos de presentación de diapositivas, ya que el fondo de pantalla cambia, también lo haría el Faux Acrylic.

Creo que sería un poco extraño ver el fondo de pantalla del escritorio detrás de una ventana cuando las otras ventanas están detrás de la ventana. Anularía el propósito de la profundidad y mostrar capas, que era uno de los propósitos principales del acrílico. Debe ser idéntico en apariencia al acrílico real.

Creo que se vería poco profesional y un poco desordenado si no mostrara lo que está directamente detrás de él como lo hace actualmente, porque el aspecto material de Fluent Design está destinado a traer aspectos de la vida real, y en la vida real, algo transparente. Brilla a lo que está justo detrás de él.

Creo que si esto se convierte en algo, debería parecer visualmente idéntico al acrílico normal.

¿Algo como lo descrito antes, un falso acrílico pero que brilla en las ventanas traseras y se comporta y parece visualmente idéntico?

¿No es eso posible?

¿Por qué no usar la semitransparencia como actualmente?

¿Cómo se distrae? Creo que es todo lo contrario: creación de profundidad, que Microsoft también dijo que es cuando lo anunció.

Cambiarlo a simplemente una decoración como esta sería un paso atrás.

Necesitamos acrílico.

Creo que sería un poco extraño ver el fondo de pantalla del escritorio detrás de una ventana cuando las otras ventanas están detrás de la ventana. Anularía el propósito de la profundidad y mostrar capas, que era uno de los propósitos principales del acrílico. Debe ser idéntico en apariencia al acrílico real.

Creo que se vería poco profesional y un poco desordenado si no mostrara lo que está directamente detrás de él como lo hace actualmente, porque el aspecto material de Fluent Design está destinado a traer aspectos de la vida real, y en la vida real, algo transparente. Brilla a lo que está justo detrás de él.

Creo que si el falso acrílico se convierte en algo, debería parecer visualmente idéntico al acrílico normal.

¿No hay forma de mostrar las ventanas detrás?

¿Por qué no usar la semitransparencia como actualmente?

¿Cómo se distrae? Creo que es todo lo contrario: creación de profundidad, que Microsoft también dijo que es cuando lo anunció.

Cambiarlo a simplemente una decoración como esta sería un paso atrás.

Por el momento, existen obstáculos técnicos para que HostBackdrop AcrylicBrush funcione en WinUI 3.0

La esperanza es que esos obstáculos se superen en el futuro, pero no inicialmente para el lanzamiento de WinUI 3.0.

Lo que estamos discutiendo es si es posible tener algo más que los colores grises alternativos estándar hasta que puedan hacerlo funcionar.

Creo que si esto se convierte en algo, debería parecer visualmente idéntico al acrílico normal.

¿Algo como lo descrito antes, un falso acrílico pero que brilla en las ventanas traseras y se comporta y parece visualmente idéntico?

¿No es eso posible?

¿Por qué no usar la semitransparencia como actualmente?

¿Cómo se distrae? Creo que es todo lo contrario: creación de profundidad, que Microsoft también dijo que es cuando lo anunció.

Cambiarlo a simplemente una decoración como esta sería un paso atrás.

Necesitamos acrílico.

El acrílico actual no es posible debido a una limitación técnica. Estamos sugiriendo un acrílico falso para propósitos de consistencia.
El punto es tener algo temporal que no interrumpa el uso actual y futuro de las aplicaciones de Acrylic hasta que se solucione la limitación técnica.

Algo es mejor que nada.

Creo que si esto se convierte en algo, debería parecer visualmente idéntico al acrílico normal.
¿Algo como lo descrito antes, un falso acrílico pero que brilla en las ventanas traseras y se comporta y parece visualmente idéntico?
¿No es eso posible?
¿Por qué no usar la semitransparencia como actualmente?
¿Cómo se distrae? Creo que es todo lo contrario: creación de profundidad, que Microsoft también dijo que es cuando lo anunció.
Cambiarlo a simplemente una decoración como esta sería un paso atrás.
Necesitamos acrílico.

El acrílico actual no es posible debido a una limitación técnica. Estamos sugiriendo un acrílico falso para propósitos de consistencia.
El punto es tener algo temporal que no interrumpa el uso actual y futuro de las aplicaciones de Acrylic hasta que se solucione la limitación técnica.

Algo es mejor que nada.

Estoy de acuerdo, solo creo que sería un poco extraño si las ventanas no se mostraran. Sin embargo, supongo que este sería el mejor enfoque si nada más es posible.

Sin embargo, no creo que esto deba usarse después de encontrar una solución al problema, porque no estoy seguro de que sea bueno para la coherencia o incluso solo para las imágenes en general a largo plazo. Creo que sería mejor solo hasta que el acrílico pueda funcionar normalmente después de WinUI 3. @mdro

Sin embargo, no creo que esto deba usarse después de encontrar una solución al problema, porque no estoy seguro de que sea bueno para la coherencia o incluso solo para las imágenes en general a largo plazo. Creo que sería mejor solo hasta que el acrílico pueda funcionar normalmente después de WinUI 3. @mdro

Cuando lo arreglen en 3.1, los desarrolladores de las aplicaciones no tendrán que hacer nada y la aplicación se actualizará uniformemente.

Sin embargo, no creo que esto deba usarse después de encontrar una solución al problema, porque no estoy seguro de que sea bueno para la coherencia o incluso solo para las imágenes en general a largo plazo. Creo que sería mejor solo hasta que el acrílico pueda funcionar normalmente después de WinUI 3. @mdro

Por el momento, las aplicaciones que se ejecutan en modo tableta retroceden y pierden su acrílico. Los dispositivos de baja potencia y las máquinas virtuales también recurren a un color sólido. Si se implementa este Faux Acrylic, podría usarse en esos escenarios como una alternativa de rendimiento.

Sin embargo, no creo que esto deba usarse después de encontrar una solución al problema, porque no estoy seguro de que sea bueno para la coherencia o incluso solo para las imágenes en general a largo plazo. Creo que sería mejor solo hasta que el acrílico pueda funcionar normalmente después de WinUI 3. @mdro

Por el momento, las aplicaciones que se ejecutan en modo tableta retroceden y pierden su acrílico. Los dispositivos de baja potencia y las máquinas virtuales también recurren a un color sólido. Si se implementa este Faux Acrylic, podría usarse en esos escenarios como una alternativa de rendimiento.

Sí, estoy de acuerdo con esto. Me refería a que no debería reemplazar el acrílico normal una vez que esté arreglado.

¿Cómo se distrae?

no lo se exactamente Supongo que la combinación de dos capas que se mueven entre sí significa que se registra en mi cerebro como un cambio en lugar de solo moverse, lo que hace que sea una razón para enfocar mis ojos allí.

De todos modos, esto no es un gran problema para mí, no me importa el estilo "sin transparencia".
Pero si agrega el respaldo de todos modos, sería bueno si se tomara un poco de tiempo extra y dividiera la configuración de los efectos de transparencia:

1. Efectos de interacción (revelar, etc.) - encendido/apagado
2. Transparencia (acrílico): completa/reducida (el respaldo que se analiza aquí y dentro de la aplicación)/desactivada

(Yo usaría Interacción en + transparencia reducida).

Por cierto, noté algunas rarezas mientras jugaba un poco más con la configuración:

• Acrílico en la barra lateral de Configuración solo está activo mientras la ventana tenga el foco. Cuando pierde el foco, cambia instantáneamente al gris no transparente. Entonces, cuando tengo la Configuración maximizada e interactúo con la bandeja o las notificaciones, en el rabillo del ojo veo un área grande en el otro lado de la pantalla parpadeando a otro color. ¿Tal vez debería mantener su textura acrílica actual cuando se suspende la actualización del acrílico debido al rendimiento?
• Al activar los efectos de transparencia mientras está en el modo de ahorro de energía, el fondo de la barra de tareas desaparece (los íconos y los resaltados de desplazamiento aparecen en el fondo de pantalla puro, no oscurecido ni borroso).
  
  (visto en Surface Pro 6, actualización de 1909)
• En la misma superficie, vi temporalmente una barra lateral gris oscuro en Configuración siempre que la transparencia estuviera habilitada; ¿Quizás la textura de fondo no se llenó y permaneció negra? El problema desapareció mientras jugaba más.

Acabo de descubrir este problema mientras probaba WinUI3.

Para mí, la razón principal por la que estuve mirando WinUI3 es precisamente para tener un fácil acceso al pincel de fondo y al pincel acrílico (que todos los clientes esperan) basado en él, fuera de UWP con una aplicación de C# sin empaquetar.

Esto es algo que hoy es técnicamente imposible de tener sin usar Dcomp (y es intimidad con DWM, y esa es probablemente la razón por la que es difícil mantener WinUI3 si WinUI3 quiere ser independiente de Windows). Hoy en día, se puede acceder a esto mediante la API pública de WinRT (C#, etc.) a través de los métodos Windows.UI.Composition.Compositor.CreateBackdropBrush / CreateHostBackdropBrush.

Si no está en WinUI, puedo (debo) continuar usando y creando manualmente un pincel personalizado de acrílico+telón de fondo (de hecho, reutilizando las recetas de WinUI 2 ya que son de código abierto). Pero dado que Dcomp tiene un nivel tan bajo técnicamente, todo se basa en él, o no se basa en absoluto. Entonces no puedo usar WinUI3 en absoluto. Algo así como la gallina y el huevo.

@mdtauk y @weltkante hicieron un excelente trabajo al describir los detalles técnicos de alto nivel sobre por qué esto es realmente difícil de hacer después de desvincularnos del sistema operativo. Como escribí en el canal #winui del servidor UWP Community Discord, mi esperanza es que podamos solucionar esto lo antes posible después de WinUI 3.0; No sé el marco de tiempo posterior a 3.0 porque tenemos más ingeniería de desarrollo que hacer para decidir cómo abordarlo. Pero es una pregunta importante y la comunidad ha dejado muy claro que les importa mucho esto. También me gusta la sugerencia de que exploremos algún tipo de "efecto falso" en el ínterin; quizás después de //build podamos comenzar a tener discusiones más profundas sobre esa idea.

La construcción ha ido y venido. No estoy seguro de si esto se abordó en Build o en la llamada de la comunidad justo después, pero esto debe hacerse antes de que WinUI3 se publique en un nivel al menos falso para fines de coherencia al menos.

Si no, habrá un montón de aplicaciones que son inconsistentes que considerarán WinUI3 una gran pérdida de tiempo.

lol entonces el que piensa que hace que este marco no sea inútil está siendo empujado hacia arriba. Seguro que Windows no sabe cómo priorizar las cosas (a menos que esta versión me permita alternar las barras de título universalmente porque entonces todo está perdonado, e hicieron lo correcto como la prioridad número 1).

No tengo mucha experiencia con las partes internas de la interfaz de usuario de Windows, pero tal vez en lugar de omitir por completo el acrílico de fondo para la versión original, ¿por qué no reutilizar internamente el acrílico antiguo en Windows 10 y volver a un color sólido en versiones anteriores de Windows? ? Creo que sería un mejor compromiso hasta que pueda implementarse adecuadamente.

Dado que Background Acrylic no hará 3.0, ¿podemos tener un acrílico falso en 3.0 mientras tanto?

No tengo mucha experiencia con las partes internas de la interfaz de usuario de Windows, pero tal vez en lugar de omitir por completo el acrílico de fondo para la versión original, ¿por qué no reutilizar internamente el acrílico antiguo en Windows 10 y volver a un color sólido en versiones anteriores de Windows? ? Creo que sería un mejor compromiso hasta que pueda implementarse adecuadamente.

En mi opinión, también sería aceptable un pincel acrílico de fondo de marcador de posición que solo represente el color alternativo; de esa manera, el pincel puede comenzar a usarse en las interfaces de inmediato. Más tarde, cuando el pincel acrílico de fondo se implemente correctamente con los efectos de translucidez adecuados, se aplicaría retroactivamente a aquellas interfaces que usaron el marcador de posición, sin necesidad de cambios en el código.

Algo más que contribuye (o hasta donde puedo decir) a esto es # 1247

También relacionado: #761

@mdro

Sería bueno si se tomara un poco de tiempo extra y dividiera la configuración de los efectos de transparencia:

• Efectos de interacción (revelar, etc.) - encendido/apagado
• Transparencia (acrílico): completa/reducida (el respaldo que se analiza aquí y dentro de la aplicación)/desactivada

Señalé algo similar en el n. ° 816, pero dijeron que no es su problema. Bienvenido al mundo Microsoft. Lo más que he visto hacer a Microsoft por sí mismo recientemente es agregar API a Windows para Edge (Chromium) y mejorar WinUI para PowerToys y Terminal. Se niegan a actualizar los estilos de sus otras interfaces de usuario que obviamente todavía usan en Windows. jajaja

¿Microsoft va a lanzar en serio WinUI 3.0 sin un falso acrílico para cubrir el fondo acrílico con fines de consistencia?

Si quieren que sea independiente, solo necesitan hacer lo que hace Linux y tener un compositor que siempre funcione y funcione que maneje acrílico. Borrón.

Si quieren que sea independiente, solo necesitan hacer lo que hace Linux y tener un compositor que siempre funcione y funcione que maneje acrílico. Borrón.

Apple parece ser capaz de manejar su translucidez sin ningún impacto significativo en el rendimiento; sé que Windows es una base de código más antigua en muchos sentidos, pero ya existe una capa visual de composición, WinUI solo necesita poder invocarla y para que sea ​​tan eficaz como sea posible.

Si quieren que sea independiente, solo necesitan hacer lo que hace Linux y tener un compositor que siempre funcione y funcione que maneje acrílico. Borrón.

Apple parece ser capaz de manejar su translucidez sin ningún impacto significativo en el rendimiento; sé que Windows es una base de código más antigua en muchos sentidos, pero ya existe una capa visual de composición, WinUI solo necesita poder invocarla y para que sea ​​tan eficaz como sea posible.

Aquí está la esperanza de que aguas arriba no señale con el dedo a otras personas pidiéndoles que lo arreglen de una manera de mierda porque pueden hacer una solución de mierda.

Me pregunto si volver a Windows 7: WinUI/Reunion podría proporcionar un controlador que proporcione la capa Renderizada necesaria para manejar Acrylic. Las aplicaciones de WinUI en implementación y las nuevas versiones del sistema operativo podrían incluir el controlador que proporciona la representación visual de la capa base, a través de la Tienda.

Windows 7 y Vista antes debían tener la capacidad para el renderizado Aero Glass. Windows 8/8.1 tenía la capa de composición visual. Entonces, tal vez esto sea más una pregunta de Reunión, pero si el controlador manejó las cosas dependientes del sistema operativo, el resto podría permanecer en el nivel de Usuario, ¿verdad?

Sí, encontré este concepto de interfaz de usuario fluida en Reddit y pensé que se veía limpio y "fluido".

Fluent se creó originalmente debido a las quejas de falta de transparencia de los usuarios. Pero ahora lo estás eliminando por completo.

Fluent se creó originalmente debido a las quejas de falta de transparencia de los usuarios. Pero ahora lo estás eliminando por completo.

Microsoft ha dicho que necesitan más tiempo para hacer que Acrylic funcione, cuando WinUI ya no sea parte del sistema operativo, sino que se ejecute por separado.

De todos modos, no me importa el acrílico, sin embargo, espero que no lo eliminen por completo.

No entiendo por qué WinUI 3 no es compatible con Acrylic. WinUI 3 no necesita hacer el trabajo, deja que lo maneje el compositor en la plataforma compatible y no es necesario que sea de código abierto.