Esta é uma dica rápida caso você, assim como eu, tenha o mesmo problema ao instalar o Fedora 26 (alfa).
O instalador não conseguiu conectar no meu roteador wireless, um D-Link. Mais especificamente, ele não estava recebendo um endereço IP do roteador. Ao que parece, um problema relacionado a DHCP.
Se for este o caso, abra um terminal (pressione a tecla Windows, digite “Terminal” e aperte Enter), e digite o seguinte comando:
sudo sh -c 'echo "send dhcp-client-identifier = hardware;" > /etc/dhcp/dhclient.conf'
Agora reconecte na rede wireless. Depois do primeiro boot – com o sistema já instalado – repita o comando acima, uma única vez.
A propósito, esse bug não é recente. Aconteceu comigo no Fedora 25, mas somente no sistema instalado. Dentro do instalador tudo funcionou perfeitamente. Agora, no F26, tá acontecendo desde o começo. Aqui o link do bugzilla, para os curiosos: https://bugzilla.redhat.com/show_bug.cgi?id=1154200.
Espero ter ajudado. Bom Fedora pra vcs!
A rede internacional Another Roadmap for Arts Education (Outro Roteiro para a Educação Artística), que reúne educadores/as e pesquisadores/as em museus, universidades, escolas e projetos culturais e educativos passou a utilizar o Noosfero como plataforma de articulação e comunicação entre seus núcleos ao redor do mundo. A rede agrega 22 grupos ao redor do mundo com a proposta de trabalhar a educação artística inserida nas relações sociais e políticas, respeitando os contextos locais.
Another Roadmap surgiu do anseio de educadores/as e pesquisadores/as de fazer uma análise crítica do Roteiro para a Educação Artística da Unesco, definido em 2006, e da Agenda de Seul (2010), uma série de metas mundiais para o desenvolvimento da Arte e Educação. A rede, que deu início à Another Roadmap School (Escola Outro Roteiro), tem a perspectiva de questionar a hegemonia dos conceitos ocidentais de arte e educação e elaborar alternativas e novos paradigmas para as pesquisas e práticas relacionadas à educação artística.
A plataforma utilizada pela rede foi desenvolvida pela Colivre por meio de um serviço prestado à Universidade de Artes de Zurique na Suiça. Por utilizar o Noosfero, a plataforma permite autonomia para os grupos que fazem parte da rede porque possibilita que cada perfil de comunidade e usuário na rede possa ter seu próprio layout customizado além de possuir funcionalidades de blogs, fóruns, agendam, wiki, pastas de arquivos, galeria de imagens, entre outras.
O Noosfero é uma plataforma web livre para a criação de redes sociais autônomas com foco no compartilhamento de conteúdo. Desenvolvido pela Colivre e lançado em 2009 durante o III Encontro Nordestino de Software Livre, o Noosfero já garantiu o primeiro lugar em diversos prêmios nacionais à cooperativa como o 9º Prêmio Cooperativa do Ano em 2014, o Prêmio Pontos de Mídia Livre do Ministério da Cultura em 2015 e o Prêmio Especial Recursos Educacionais Abertos da Revista ARede Educa em 2016.
Para conhecer mais sobre a rede Another Roadmap for Arts Education acesse o site oficial através do endereço http://another.zhdk.ch/.
Like I wrote before, we at Collabora have been working on improving WebKitGTK+ performance for customer projects, such as Apertis. We took the opportunity brought by recent improvements to WebKitGTK+ and GTK+ itself to make the final leg of drawing contents to screen as efficient as possible. And then we went on investigating why so much CPU was still being used in some of our test cases.
The first weird thing we noticed is performance was actually degraded on Wayland compared to running under X11. After some investigation we found a lot of time was being spent inside GTK+, painting the window’s background.
Here’s the thing: the problem only showed under Wayland because in that case GTK+ is responsible for painting the window decorations, whereas in the X11 case the window manager does it. That means all of that expensive blurring and rendering of shadows fell on GTK+’s lap.
During the web engines hackfest, a couple of months ago, I delved deeper into the problem and noticed, with Carlos Garcia’s help, that it was even worse when HiDPI displays were thrown into the mix. The scaling made things unbearably slower.
You might also be wondering why would painting of window decorations be such a problem, anyway? They should only be repainted when a window changes size or state anyway, which should be pretty rare, right? Right, that is one of the reasons why we had to make it fast, though: the resizing experience was pretty terrible. But we’ll get back to that later.
So I dug into that, made a few tries at understanding the issue and came up with a patch showing how applying the blur was being way too expensive. After a bit of discussion with our own Pekka Paalanen and Benjamin Otte we found the root cause: a fast path was not being hit by pixman due to the difference in scale factors on the shadow mask and the target surface. We made the shadow mask scale the same as the surface’s and voilà, sane performance.
I keep talking about this being a performance problem, but how bad was it? In the following video you can see how huge the impact in performance of this problem was on my very recent laptop with a HiDPI display. The video starts with an Epiphany window running with a patched GTK+ showing a nice demo the WebKit folks cooked for CSS animations and 3D transforms.
After a few seconds I quickly alt-tab to the version running with unpatched GTK+ – I made the window the exact size and position of the other one, so that it is under the same conditions and the difference can be seen more easily. It is massive.
Yes, all of that slow down was caused by repainting window shadows! OK, so that solved the problem for HiDPI displays, made resizing saner, great! But why is GTK+ repainting the window even if only the contents are changing, anyway? Well, that turned out to be an off-by-one bug in the code that checks whether the invalidated area includes part of the window decorations.
If the area being changed spanned the whole window width, say, it would always cause the shadows to be repainted. By fixing that, we now avoid all of the shadow drawing code when we are running full-window animations such as the CSS poster circle or gtk3-demo’s pixbufs demo.
As you can see in the video below, the gtk3-demo running with the patched GTK+ (the one on the right) is using a lot less CPU and has smoother animation than the one running with the unpatched GTK+ (left).
Pretty much all of the overhead caused by window decorations is gone in the patched version. It is still using quite a bit of CPU to animate those pixbufs, though, so some work still remains. Also, the overhead added to integrate cairo and GL rendering in GTK+ is pretty significant in the WebKitGTK+ CSS animation case. Hopefully that’ll get much better from GTK+ 4 onwards.
I had a great time last week and the web engines hackfest! It was the 7th web hackfest hosted by Igalia and the 7th hackfest I attended. I’m almost a local Galician already. Brazilian Portuguese being so close to Galician certainly helps! Collabora co-sponsored the event and it was great that two colleagues of mine managed to join me in attendance.
It had great talks that will eventually end up in videos uploaded to the web site. We were amazed at the progress being made to Servo, including some performance results that blew our minds. We also discussed the next steps for WebKitGTK+, WebKit for Wayland (or WPE), our own Clutter wrapper to WebKitGTK+ which is used for the Apertis project, and much more.
One thing that drew my attention was how many Dell laptops there were. Many collaborans (myself included) and igalians are now using Dells, it seems. Sure, there were thinkpads and macbooks, but there was plenty of inspirons and xpses as well. It’s interesting how the brand make up shifted over the years since 2009, when the hackfest could easily be mistaken with a thinkpad shop.
Back to the actual hackfest: with the recent release of Gnome 3.22 (and Fedora 25 nearing release), my main focus was on dealing with some regressions suffered by users experienced after a change that made putting the final rendering composited by the nested Wayland compositor we have inside WebKitGTK+ to the GTK+ widget so it is shown on the screen.
One of the main problems people reported was applications that use WebKitGTK+ not showing anything where the content was supposed to appear. It turns out the problem was caused by GTK+ not being able to create a GL context. If the system was simply not able to use GL there would be no problem: WebKit would then just disable accelerated compositing and things would work, albeit slower.
The problem was WebKit being able to use an older GL version than the minimum required by GTK+. We fixed it by testing that GTK+ is able to create GL contexts before using the fast path, falling back to the slow glReadPixels codepath if not. This way we keep accelerated compositing working inside WebKit, which gives us nice 3D transforms and less repainting, but take the performance hit in the final “blit”.
Another issue we hit was GTK+ not properly updating its knowledge of the window’s opaque region when painting a frame with GL, which led to some really interesting issues like a shadow appearing when you tried to shrink the window. There was also an issue where the window would not use all of the screen when fullscreen which was likely related. Both were fixed.
André Magalhães also worked on a couple of patches we wrote for customer projects and are now pushing upstream. One enables the use of more than one frontend to connect to a remote web inspector server at once. This can be used to, for instance, show the regular web inspector on a browser window and also use IDE integration for setting breakpoints and so on.
The other patch was cooked by Philip Withnall and helped us deal with some performance bottlenecks we were hitting. It improves the performance of painting scroll bars. WebKitGTK+ does its own painting of scrollbars (we do not use the GTK+ widgets for various reasons). It turns out painting scrollbars can be quite a hit when the page is being scrolled fast, if not done efficiently.
Emanuele Aina had a great time learning more about meson to figure out a build issue we had when a more recent GStreamer was added to our jhbuild environment. He came out of the experience rather sane, which makes me think meson might indeed be much better than autotools.
It was a great hackfest, great seeing everyone face to face. We were happy to celebrate Igalia’s 15 years with them. Hope to see everyone again next year =)
Aê gente! Passada rápida aqui só pra dizer que foi muito bacana a nossa festinha do GNOME.
Tivemos 2 palestras “informais” e muito, mas muito bate papo acerca do GNOME: tecnologia, comunidade, meritocracia, GNU e FSF e afins
O Georges escreveu sobre a festa em inglês, quem puder dá uma olhada lá.
No final ficou um sentimento que seria bacana termos um próximo encontro com hands-on, mais hacking e menos talk Achei bacana a ideia e criei um meetup pra isso. Se tivermos gente interessada o suficiente podemos fazer. O que acham? Divulguem!
Next week our friends at Igalia will be hosting this year’s Web Engines Hackfest. Collabora will be there! We are gold sponsors, and have three developers attending. It will also be an opportunity to celebrate Igalia’s 15th birthday \o/. Looking forward to meet you there! =)
Carlos Garcia has recently released WebKitGTK+ 2.14, the latest stable release. This is a great release that brings a lot of improvements and works much better on Wayland, which is becoming mature enough to be used by default. In particular, it fixes the clipboard, which was one of the main missing features, thanks to Carlos Garnacho! We have also been able to contribute a bit to this release =)
One of the biggest changes this cycle is the threaded compositor, which was implemented by Igalia’s Gwang Yoon Hwang. This work improves performance by not stalling other web engine features while compositing. Earlier this year we contributed fixes to make the threaded compositor work with the web inspector and fixed elements, helping with the goal of enabling it by default for this release.
Wayland was also lacking an accelerated compositing implementation. There was a patch to add a nested Wayland compositor to the UIProcess, with the WebProcesses connecting to it as Wayland clients to share the final rendering so that it can be shown to screen. It was not ready though and there were questions as to whether that was the way to go and alternative proposals were floating around on how to best implement it.
At last year’s hackfest we had discussions about what the best path for that would be where collaborans Emanuele Aina and Daniel Stone (proxied by Emanuele) contributed quite a bit on figuring out how to implement it in a way that was both efficient and platform agnostic.
We later picked up the old patchset, rebased on the then-current master and made it run efficiently as proof of concept for the Apertis project on an i.MX6 board. This was done using the fancy GL support that landed in GTK+ in the meantime, with some API additions and shortcuts to sidestep performance issues. The work was sponsored by Robert Bosch Car Multimedia.
Igalia managed to improve and land a very well designed patch that implements the nested compositor, though it was still not as efficient as it could be, as it was using glReadPixels to get the final rendering of the page to the GTK+ widget through cairo. I have improved that code by ensuring we do not waste memory when using HiDPI.
As part of our proof of concept investigation, we got this WebGL car visualizer running quite well on our sabrelite imx6 boards. Some of it went into the upstream patches or proposals mentioned below, but we have a bunch of potential improvements still in store that we hope to turn into upstreamable patches and advance during next week’s hackfest.
One of the improvements that already landed was an alternate code path that leverages GTK+’s recent GL super powers to render using gdk_cairo_draw_from_gl(), avoiding the expensive copying of pixels from the GPU to the CPU and making it go faster. That improvement exposed a weird bug in GTK+ that causes a black patch to appear when shrinking the window, which I have a tentative fix for.
We originally proposed to add a new gdk_cairo_draw_from_egl() to use an EGLImage instead of a GL texture or renderbuffer. On our proof of concept we noticed it is even more efficient than the texturing currently used by GTK+, and could give us even better performance for WebKitGTK+. Emanuele Bassi thinks it might be better to add EGLImage as another code branch inside from_gl() though, so we will look into that.
Another very interesting igalian addition to this release is support for the MemoryPressureHandler even on systems with no cgroups set up. The memory pressure handler is a WebKit feature which flushes caches and frees resources that are not being used when the operating system notifies it memory is scarce.
We worked with the Raspberry Pi Foundation to add support for that feature to the Raspberry Pi browser and contributed it upstream back in 2014, when Collabora was trying to squeeze as much as possible from the hardware. We had to add a cgroups setup to wrap Epiphany in, back then, so that it would actually benefit from the feature.
With this improvement, it will benefit even without the custom cgroups setups as well, by having the UIProcess monitor memory usage and notify each WebProcess when memory is tight.
Some of these improvements were achieved by developers getting together at the Web Engines Hackfest last year and laying out the ground work or ideas that ended up in the code base. I look forward to another great few days of hackfest next week! See you there o/
Teremos festinha do GNOME em São Paulo!
Data: 01/10/2016 (Sábado) – 10h
Local: Red Hat Brasil – Av. Faria Lima, 3900 – 8º Andar. Mapa.
Como dito no post anterior a ideia é ser um evento informal, com algumas palestras e muito bate-papo. Quem quiser palestrar, acesse esse documento do Google Docs e adiciona seu nome lá. O importante é ser algo relacionado ao GNOME né
Quanto aos comes e bebes, acredito que podemos seguir o mesmo modelo colaborativo, né? Ou seja a gente mesmo leva os salgados, doces, refri, etc. O que vocês acham? Coloquem lá nesse mesmo documento o que vocês pretendem levar.
Temos um limite de vagas e, além disso precisamos do nome e RG de todos que comparecerão. Isso é pra controle de acesso ao prédio. Portanto, enviem para o e-mail email@example.com seu nome e RG para que possamos confirmar sua vinda e autorizar a entrada de vocês.
Ansioso pra encontrar essa galera! Abraços e até lá!
O GNOME 3.22 vai ser lançado essa semana, e como de costume vão rolar algumas comemorações ao redor do mundo. Aqui no Brasil a gente não tem muito o costume de celebrar esses lançamentos né?
Alguém anima fazer uma festinha?
Tem alguma regra pra fazer tais “festas”? Não! Basta juntar uns amigos e celebrar como quiser! Mas é bacana postar fotos e divulgar nas mídias né
Bom, dito isso, tava pensando em juntar um pessoal interessado numa festinha dessa em São Paulo. Pensei num esquema de mini-palestras abordando por exemplo as novidades da nova versão, como se tornar um colaborador, etc. Isso regado a salgados, refri, etc. Ambiente informal, conhecendo pessoas ou revendo amigos, fazendo networking e celebrando! Bacana né!
Dependendo da quantidade de pessoas interessadas, podemos usar o escritório da Red Hat em São Paulo pra isso. Só preciso ter uma noção de quantas pessoas iriam. Se você topa, me fala – via email, twitter, respondendo aqui nesse blog, sinal de fumaça, etc. de forma que eu vou montar uma lista. Se chegarmos num número bom (10?) eu fecho o lugar e atualizo a info aqui.
E aí, vamos animar?
Começando a estudar o JavaFX, e tentando utilizar a partir da IDE Eclipse, não conseguia fazer com que o Eclipse chamasse automaticamente o Scene Builder.
Por exemplo, neste projeto:
Clicar com o botão direito no arquivo "PersonOverview.fxml" e escolher "Open with Scene Builder", não fazia nada.
[ NOTA: estou querendo utilizar o Scene Builder disponibilizado no formato .jar, disponível em http://gluonhq.com/open-source/scene-builder/ ]
Pesquisando na Internet, encontrei a informação de que deveria indicar ao Eclipse a localização do Scene Builder,
em window | preferences | JavaFX:
Isso feito, ainda assim, nada do Eclipse conseguir chamar o Scene Builder abrindo o arquivo desejado. Aliás, novamente, nada acontecia...
A solução foi criar um shell script para chamar o Scene Builder, e indicar esse shell script como "executável" do SceneBuilder para o Eclipse:
java -jar /home/carlao2005/4_____PROJETOS/eclipse_workspace/SceneBuilder-8.1.1.jar
Opa! Sucesso parcial!! Agora o Eclipse abre o Scene Builder... mas vazio, não abre o arquivo desejado.
Imaginei que o Eclipse chama o Scene Builder, passando como parâmetro o nome do arquivo (com o caminho completo) com o qual se deseja trabalhar. Então, basta apenas inserir um parâmetro ($1) no final da linha que chama o Scene Builder:
java -jar /home/carlao2005/4_____PROJETOS/eclipse_workspace/SceneBuilder-8.1.1.jar $1
Pronto! Tudo funcionando!