| title | Que Stack Gráfica Escolher? | ||||
|---|---|---|---|---|---|
| author | Daniel Margarido | ||||
| date | \today | ||||
| theme | CambridgeUS | ||||
| colortheme | beaver | ||||
| fontfamily | merriweather | ||||
| header-includes |
|
- Problema
- Estado atual
- Foco de Análise
- Consumos atuais
- Aplicação de Notas - GKT
- Aplicação de Notas - Swing
- Aplicação de Notas - FLTK
- Aplicação de Notas - X11 + Nuklear
- Comparação de resultados
- Dados de outros casos
- Outras Alternativas
- Conclusões
- Motivação
- Questões
-
Equipamentos ficam mais lentos ao longo do tempo.
-
A verdade é que não ficam.
-
O software que usamos diariamente gasta cada vez mais recursos.
-
E usufruimos assim tanto de mais funcionalidades do que era usado à uns 5 ou 10 anos?
\begincols{}
\column{0.49\textwidth}
- 2 Motores 92RPM
- 1GB de RAM
- 8GB de armazenamento
- 4× ARM Cortex-A53, 1.2GHz
- Robot Tank Chasis
\column{0.49\textwidth}
\stopcols
Consumo de RAM: 2.4GB
Consumo de RAM: 514MB
Consumo de RAM: 848MB
Consumo de RAM: 503.1MB
-
Windows ocupa para cima de 2GB e mesmo o Ubuntu atual ocupa quase 1GB de RAM.
-
20MB de RAM é quanto ocupa um servidor OpenBSD acabado de instalar.
-
Servidor que tem interface de linha de comandos vs um sistema com ambiente gráfico completo.
-
40x mais RAM, temos de tentar reduzir o máximo que conseguirmos.
-
Pesquisa de toolkit gráficos.
-
Implementação de aplicação de notas.
-
Inserção de notas no em ficheiro e a sua pesquisa.
-
Em cada teste vamos medir:
- Utilização de memória RAM
- Simplicidade de implementação
- Plataformas Suportadas
-
Tamanho de janela 400x300.
-
Implementar apenas a interface usando o toolkit gráfico.
\begincols{} \column{0.60\textwidth}
- Criado em 1998.
- Implementado em C.
- Desenvolvido pelo GNOME Project.
- Maioria dos ambientes gráficos mais utilizados em linux utilizam gtk.
\column{0.38\textwidth}
\stopcols
\begincols{}
\column{0.49\textwidth}
\column{0.49\textwidth}
\stopcols
- Utilização de memória RAM - 26.54MB
- Plataformas Suportadas - GNU/Linux, Unix, Windows e Mac OS X
- Simplicidade de implementação:
- Widgets baseados em GtkWidget.
- Manual de fácil pesquisa e com boa documentação.
- Glade para construção de interface só com drag and drop.
- Trabalhoso usar as caixas de layout que são para definir posição dos widgets.
\begincols{} \column{0.60\textwidth}
- Criado em 1997
- Implementado em Java
- Alternativa lightweight ao java AWT
- Desenha os próprios widgets sem utilizar os do sistema
\column{0.38\textwidth}
\stopcols
\begincols{}
\column{0.49\textwidth}
\column{0.49\textwidth}
\stopcols
- Utilização de memória RAM - 55.60MB
- Plataformas Suportadas - Platform-Independent
- Simplicidade de implementação:
- Documentação nos standards do java mas sem pesquisa rápida.
- Escassos exemplos de utilização.
- Utilização simples permite posicionamento usando layouts e posicionamento directo na frame.
\begincols{} \column{0.60\textwidth}
- Criado em 1998
- Implementado em C++
- Usa um design mais leve e restringe-se apenas à funcionalidade de GUI
- Normalmente linkado de forma estática
\column{0.38\textwidth}
\stopcols
\begincols{}
\column{0.49\textwidth}
\column{0.49\textwidth}
\stopcols
- Utilização de memória RAM - 9.84MB
- Plataformas Suportadas - GNU/Linux, Unix, Windows, macOS, AmigaOS 4
- Simplicidade de implementação:
- Desenho de elementos na interface simples
- Gestão de linhas e margens precisou de calculos manuais
- Documentação tem os widgets bem documentados e aborda a maioria dos casos de uso
- FLUID permite construir a interface com drag and drop
- Criado em 2015
- Implementado em ANSI C
- Immediate mode graphical user interface toolkit
- Zero dependências, recebe o input do estado atual e gera comandos de desenho de primitivas como output
- Backends atuais para desenhar estas primitivas - x11, d3d9, d3d11, gdl, gdlp, glfw, sdl com opengl, sfml com opengl, allegro5
\begincols{}
\column{0.49\textwidth}
\column{0.49\textwidth}
\stopcols
- Utilização de memória RAM - 3.9MB
- Plataformas Suportadas - Depende dos backends de render
- Simplicidade de implementação:
- Utilização de contextos para desenhar demora um pouco a entender
- Desenho por layout e posições absolutas
- Documentação limitada
- Utilização envolve ainda alguma leitura de código para escolher backends e perceber como é a integração
\begincols{}
\column{0.70\textwidth}
- Hello World utiliza 125MB de RAM
- Rapidamente flutua para valores mais altos
- Chromium com aplicação no topo
\column{0.20\textwidth}
\stopcols
\begincols{}
\column{0.70\textwidth}
- Hello World utiliza 9.8MB de RAM
- Utiliza Lua para scripting
- Permite mudar estilos com CSS
- Cross-Platform
\column{0.20\textwidth}
\stopcols
\begincols{}
\column{0.70\textwidth}
- Hello World utiliza - 868KB de RAM
- Disponibiliza um pixelbuffer
- É preciso implementar toda a stack
- Alternativa Wayland + ImGui
\column{0.20\textwidth}
\stopcols
- QT
- .NET
- tk
- motif
- IUP
- SDL
- Win32
- X.org
- Toolkits mais apelativos
- Maximizar a produtividade
- Cross-platform
- É possivel reduzir o consumo de memória
- Manter o raspberry como máquina de trabalho durante mais uns 5 anos
- Não ter de trocar de hardware de 2 em 2 anos
\begincols{}
\column{0.64\textwidth}
-
Email:
-
Apresentação:
-
Github:
-
Bitbucket:
-
Itch.io:
\column{0.35\textwidth}
\stopcols