Сообщение Sciter в качестве движка для построения стилизуемого WM (?) от 12.08.2023 5:35
Изменено 12.08.2023 5:38 zx zpectrum
Sciter в качестве движка для построения стилизуемого WM (?)
Странный и необычный вопрос уважаемому Андрею.
А что если:
1. Взять Sciter Lite, который работает без всяких дескрипторов окон, и сравнительно легко интегрируется куда угодно, где есть аппаратно ускоренная отрисовка;
2. Завести его под Linux поверх DRM/KMS;
3. И заставить работать Wayland-композитором + оконным менеджером: рисовать декорации окошек, рабочий стол, менюшки, и, собственно, композировать содержимое UI-клиентов.
Реален ли такой эзотерический сценарий использования? Есть ли какие-либо невидимые со стороны подвохи и подводные камни, чтобы сразу сказать твердое "нет" данной долбонавтской затее?
Возможные преимущества-то очевидны. Легкость визуальной стилизации. HiDPI и врожденная независимость от физического разрешения подключенного(ных) дисплея(ев). Общая легковесность по сравнению с тем же монстроидальным Гномом, в котором крутится полновесный Webkit. Потенциальная возможность минимизировать расход энергии в портативных устройствах за счет легкости и быстроты. Скромный размер кодовой базы, что позволит малыми человеческими ресурсами проделать такие нетривиальные штуки, как мультиконтекстность и мульти-runloop-ность в случае несколькими дисплеев с разной частотой обновления (о чем страшно даже и задумываться в случае больших и толстых веб-движков, которые будут рисовать либо когда сами захотят, либо придется избыточно копировать кадры).
А что если:
1. Взять Sciter Lite, который работает без всяких дескрипторов окон, и сравнительно легко интегрируется куда угодно, где есть аппаратно ускоренная отрисовка;
2. Завести его под Linux поверх DRM/KMS;
3. И заставить работать Wayland-композитором + оконным менеджером: рисовать декорации окошек, рабочий стол, менюшки, и, собственно, композировать содержимое UI-клиентов.
Реален ли такой эзотерический сценарий использования? Есть ли какие-либо невидимые со стороны подвохи и подводные камни, чтобы сразу сказать твердое "нет" данной долбонавтской затее?
Возможные преимущества-то очевидны. Легкость визуальной стилизации. HiDPI и врожденная независимость от физического разрешения подключенного(ных) дисплея(ев). Общая легковесность по сравнению с тем же монстроидальным Гномом, в котором крутится полновесный Webkit. Потенциальная возможность минимизировать расход энергии в портативных устройствах за счет легкости и быстроты. Скромный размер кодовой базы, что позволит малыми человеческими ресурсами проделать такие нетривиальные штуки, как мультиконтекстность и мульти-runloop-ность в случае несколькими дисплеев с разной частотой обновления (о чем страшно даже и задумываться в случае больших и толстых веб-движков, которые будут рисовать либо когда сами захотят, либо придется избыточно копировать кадры).
Sciter в качестве движка для построения стилизуемого WM (?)
Странный и необычный вопрос уважаемому Андрею.
А что если:
1. Взять Sciter Lite, который работает без всяких дескрипторов окон, и сравнительно легко интегрируется куда угодно, где есть аппаратно ускоренная отрисовка;
2. Завести его под Linux поверх DRM/KMS;
3. И заставить работать Wayland-композитором + оконным менеджером: рисовать декорации окошек, рабочий стол, менюшки, и, собственно, композировать содержимое UI-клиентов.
Реален ли такой эзотерический сценарий использования? Есть ли какие-либо невидимые со стороны подвохи и подводные камни, чтобы сразу сказать твердое "нет" данной долбонавтской затее?
Возможные преимущества-то очевидны. Легкость визуальной стилизации. HiDPI и врожденная независимость от физического разрешения подключенного(ных) дисплея(ев). Общая легковесность по сравнению с тем же монстроидальным Гномом, в котором крутится полновесный Webkit. Потенциальная возможность минимизировать расход энергии в портативных устройствах за счет легкости и быстроты. Скромный размер кодовой базы, что позволит малыми человеческими ресурсами проделать такие нетривиальные штуки, как мультиконтекстность и мульти-runloop-ность в сценарии "N дисплеев с разной частотой обновления" (о чем страшно даже и задумываться в случае больших и толстых веб-движков, которые будут рисовать либо когда сами захотят, либо придется избыточно копировать кадры).
А что если:
1. Взять Sciter Lite, который работает без всяких дескрипторов окон, и сравнительно легко интегрируется куда угодно, где есть аппаратно ускоренная отрисовка;
2. Завести его под Linux поверх DRM/KMS;
3. И заставить работать Wayland-композитором + оконным менеджером: рисовать декорации окошек, рабочий стол, менюшки, и, собственно, композировать содержимое UI-клиентов.
Реален ли такой эзотерический сценарий использования? Есть ли какие-либо невидимые со стороны подвохи и подводные камни, чтобы сразу сказать твердое "нет" данной долбонавтской затее?
Возможные преимущества-то очевидны. Легкость визуальной стилизации. HiDPI и врожденная независимость от физического разрешения подключенного(ных) дисплея(ев). Общая легковесность по сравнению с тем же монстроидальным Гномом, в котором крутится полновесный Webkit. Потенциальная возможность минимизировать расход энергии в портативных устройствах за счет легкости и быстроты. Скромный размер кодовой базы, что позволит малыми человеческими ресурсами проделать такие нетривиальные штуки, как мультиконтекстность и мульти-runloop-ность в сценарии "N дисплеев с разной частотой обновления" (о чем страшно даже и задумываться в случае больших и толстых веб-движков, которые будут рисовать либо когда сами захотят, либо придется избыточно копировать кадры).