Cómo identificar Wayland y Xwindow en uso
Nota: La comprensión del autor sobre X Window se limita a la superficie. Habrá muchos errores técnicos e históricos en el artículo. Si alguien puede señalarlo, ¡se lo agradecería!
La antigua X Window y la moderna tecnología de escritorio
X Window fue desarrollado por el MIT en 1984. Uno de sus conceptos de diseño es proporcionar mecanismos en lugar de estrategias. Para tomar el ejemplo más simple, X Window proporciona un método para generar ventanas, pero no especifica cómo se muestran (mapa) o se colocan (la estrategia la determina el programa externo (administrador de ventanas); Otra característica clave de X Window es el modelo de red servidor/cliente. Las aplicaciones locales y remotas se unifican a través del modelo servidor/cliente, permitiendo que las aplicaciones remotas se ejecuten localmente, por ejemplo.
X Window se desarrolló rápidamente después de su lanzamiento. En 1987, el protocolo central se había desarrollado hasta la versión 11, denominada x11. Esta versión implementó completamente el concepto de "proporcionar mecanismos en lugar de estrategias", y el núcleo. El protocolo era básicamente estable. No se requieren modificaciones importantes. El protocolo central ahora es lo suficientemente estable como para que no sean necesarios cambios importantes. Entonces, como puede ver, estamos en 2010, 23 años después, y X Window sigue siendo X11.
Quizá le sorprenda saber que el protocolo central de X Window no ha cambiado significativamente en 23 años, entonces, ¿podrá mantenerse al día con el rápido ritmo del escritorio moderno?
Esto se remonta a las ventajas de diseño de X Window: proporciona una capa de extensión fuera de la capa central, lo que permite a los desarrolladores desarrollar extensiones para implementar sus propios protocolos de extensión, como:
La ventana estándar es un rectángulo, entonces, ¿cómo la uso para dibujar una ventana circular? El protocolo X Window no proporciona esta funcionalidad, pero a través de la extensión "forma", X Window puede lograr formas irregulares.
Así que, durante los últimos 23 años, X Window ha seguido mejorando el protocolo central y los controladores, pero en gran medida, son las extensiones las que lo han mantenido "actualizado":
Para admitir la visualización de archivos con múltiples encabezados, la extensión "Xinerama" implementa esto;
Para admitir la reproducción de video multimedia, la extensión "X Video" implementa esto;
OpenGL La extensión "GL" proporciona soporte 3D;
¿Qué pasa con los efectos de escritorio sintéticos como Compiz? Así es, necesitamos una nueva extensión: "
¡Incluso la compatibilidad con el teclado está disponible a través de las "Extensiones de teclado X" (también conocidas como "XKB")!
El núcleo de X Window Básicamente maneja servidores/clientes, controladores, etc., y el soporte externo se realiza básicamente a través de "extensiones". No hay nada de malo en eso, X Window está muy bien estructurado, e incluso si son extensiones, no tienen problemas de rendimiento. te permiten implementar fácilmente soporte para nuevas tecnologías y cosas nuevas, y son fáciles de mantener, lo cual es muy bueno
Así que cuando ves GNOME y KDE basados en X Window en 23. Cuando sigue siendo competitivo durante años. más tarde, e incluso supera a Windows y Mac OS
Aunque muchas extensiones no han causado ningún problema a X Window y están en línea con el concepto de diseño de X Window, la arquitectura servidor/cliente ha sido cuestionada:
Eficiencia de X Window
Algunas personas suelen decir que la arquitectura servidor/cliente de X Window afecta seriamente la eficiencia
A menudo se dice que la arquitectura servidor/cliente de X Window afecta seriamente la eficiencia.
A menudo se dice que la arquitectura servidor/cliente de X Window afecta seriamente la eficiencia, haciendo que el escritorio Linux sea menos eficiente que Windows y Mac OS X. Hablemos de cómo funciona esto.
Esta es la arquitectura actual del sistema X Window, explícala un poco:
Cliente X: aplicaciones gráficas, como Firefox, Pidgin, etc.
>X Server: el centro de control que no puedes ver;
Compositor: la composición de los sistemas de escritorio, como Compiz;
Kernel/KMS/evdev: este es el kernel de Linux Más adelante hablaremos sobre la tecnología KMS, que también incluye evdev para administrar dispositivos de entrada.
Arquitectura X
A través de estas flechas, ya puede comprender algunos de los principios de funcionamiento de X Window, pero para explicarlo desde el escenario de la aplicación, imagine que cuando hace clic en Firefox ( X Cuando haces clic en el botón Actualizar en el cliente, sucede lo siguiente:
Esta es la primera vez que se utiliza X Window en una aplicación.
Haces clic en el botón "Actualizar" de Firefox con el mouse y el kernel recibe el evento del mouse y lo envía al servidor X a través del controlador de entrada evdev. En realidad, el kernel hace muchas cosas, incluida la conversión de diferentes señales de diferentes marcas de ratones en mensajes de entrada estándar "evdev".
El servidor X determinará qué ventana debe recibir el mensaje y enviará el mensaje al cliente X Firefox de que el botón fue presionado en una determinada coordenada, pero el servidor X en realidad no sabe si lo recibió. ¡Información correcta sobre Windows! ¿Por qué sucede esto? Porque el escritorio Linux actual es diferente al de hace 10 años. Ahora es la era del "compuesto", es decir, el escritorio compuesto. Una característica del escritorio compuesto es que el Compositor (como Compiz) administra todo en la ventana. ¡X Server solo puede saber lo que hay en la pantalla en algún momento! El servidor X sólo sabe que un punto en la pantalla recibió el mensaje del mouse, pero no sabe si hay una ventana debajo de ese punto. ¿Quién sabe si Compiz está haciendo una animación lenta y agradable para reducir la ventana?
Suponiendo que el escenario de la aplicación no es complicado, Firefox recibirá el mensaje con éxito. En este momento, Firefox debe decidir cómo operar: se debe presionar el botón. Por lo tanto, Firefox envía otra solicitud al servidor X: "Dibuje el efecto cuando se presiona el botón".
Cuando el servidor X recibe este mensaje, está listo para comenzar el dibujo real: primero le indicará al controlador de gráficos el efecto a dibujar, luego calculará el área modificada y le indicará a Compiz que las áreas deben ser resintetizado.
Cuando Compiz recibe el mensaje, obtendrá los gráficos renderizados por la tarjeta gráfica del búfer y los volverá a sintetizar en la pantalla; por supuesto, la operación de "composición" de Compiz también es una "renderización". operación. (Por supuesto, la operación "compuesta" de Compiz también es una operación de "renderizado", que implica realizar una solicitud al servidor X "Quiero dibujar esto", y luego el servidor X responde "Puedes dibujarlo".
Es posible que todo el proceso ya sea muy claro. Las acciones de solicitud y representación son desde X Client->X Server, y luego desde X Server->Compositor, y de hecho requieren más tiempo, pero esto. no es el caso.
Existe un mecanismo entre X Window. Aunque Compiz ha sido responsable de todos los efectos finales de renderizado del escritorio, X Server todavía necesita hacer algo de "trabajo" después de recibir la solicitud de "renderizado" de Compiz, como: juzgar la superposición de ventanas y juzgar la superposición. de ventanas de cobertura, cálculo de recorte de ventanas de cobertura, etc. (De lo contrario, ¿cómo sabe que las coordenadas del mouse hacia abajo son la ventana de Firefox)? Estas son tareas repetitivas sin sentido, a Compiz no le importarán, Compiz seguirá dibujando su propia animación en su propio "lienzo" de pantalla completa Efecto .....
De este proceso, básicamente se pueden sacar las siguientes conclusiones:
El Cliente X <-> Servidor X <->.
X Server y Compositor han realizado mucha duplicación innecesaria de trabajo y cambios de tema.
Por supuesto, no dije directamente aquí si este modo trae problemas de eficiencia a X Window, porque todavía carecemos de un grupo de control. Antes de estudiar el grupo de control, echemos un vistazo a otra tendencia de X Server:
De "hacer todo" a "hacer cada vez menos" X Window
Cuando apareció X Window por primera vez , proporcionó principalmente una capa de abstracción sobre el núcleo del sistema operativo para implementar un entorno gráfico. Los principales contenidos del entorno gráfico son gráficos y texto. X Window proporciona un mecanismo para "dibujar" y "presentar" texto. Los gráficos y el texto del escritorio gráfico los compone y dibuja X Window.
Un ejemplo típico es que si quieres usar X para dibujar un punto, debes hacerlo en el programa a través de "XDrawPoint", y luego el servidor X recibe el mensaje y dibuja el punto correspondiente.
Ahora bien, cualquiera que tenga un poco de contacto con el desarrollo de gráficos sabe que en la ventana X, el dibujo de gráficos generalmente se realiza a través de GTK+ y Qt. Profundizando más, los gráficos se dibujan a través de Cairo (este no es el caso con Qt). Es un motor de dibujo + renderizado. El famoso navegador Firefox utiliza Cairo para representar páginas web y texto.
Cairo es una biblioteca de gráficos vectoriales multiplataforma con todas las funciones y, aunque se desarrolló originalmente para X Window, no es sólo un contenedor para bibliotecas de gráficos específicas de cada plataforma. Cairo ahora admite varios backends diferentes para generar gráficos, como X, Windows GDI, Mac OS X Quartz y múltiples formatos de archivo: PNG, PDF y, por supuesto, SVG. Se puede decir que Cairo es una biblioteca de dibujo muy completa y versátil, no importa qué gráficos se dibujen ahora, no se considerará XLib.
Fuera de El Cairo, también hay una biblioteca de diseño de texto: Pango. También es obvio que cuando se trata de diseño de texto, no utilizará XFont o similar, sino que dibujará directamente con Pango. Por supuesto, Pango también es multiplataforma.
Aunque en la plataforma Linux, la jugabilidad de Cairo y Pango todavía se basa en X Window, X Window es, en el mejor de los casos, sólo un "backend" y no funcionará sin él. De manera similar, GTK+ y Qt multiplataforma solo son compatibles con X como uno de sus backends, por lo que si un día X desaparece, puedes reemplazarlo con un nuevo backend, y los actuales GNOME y KDE podrán completar su ejecución en tierra.
Otro ejemplo clásico de "X alguna vez lo hizo, pero ya no lo hace" es la "configuración de modo", también conocida comúnmente como "configuración de resolución".
Aunque la "configuración de resolución" se mencionará en un capítulo posterior, su significado es mucho más que eso.
Como todos sabemos, Linux es solo un kernel, solo tiene una consola con la que puedes interactuar a través del shell, y la configuración predeterminada de la consola es 80x24 (en caracteres), por lo que para poder ingrese la resolución en modo gráfico 1024x768 o superior, debe realizar la "configuración de modo" en la X para configurar la resolución correcta, etc.
Aunque Linux posteriormente admitió varias configuraciones de modo de espacio de usuario para permitir que el terminal admita resoluciones estándar, la configuración de modo para La pantalla "parpadeará" al ingresar a la interfaz de usuario. La pantalla "parpadeará" y la "configuración del modo" está en progreso; aquí se debe usar la palabra "configuración del modo" porque aunque el terminal es 1024, sigue siendo una buena idea ingresar el gráfico X. 1024, los gráficos X también son 1024, todavía requiere un cambio de modo.