-Поиск по дневнику

Поиск сообщений в rss_planet_mozilla

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 19.06.2007
Записей:
Комментариев:
Написано: 7


Mozilla GFX: WebRender newsletter #32

Четверг, 29 Ноября 2018 г. 16:18 + в цитатник

Hey there! Did you hear this? Me neither. The 32nd episode of WebRender’s newsletter made its way to your screen without a sound. In the previous episode, nic4r asked in the comments section a lot of technical and interesting questions. There is a lot to cover so I’ll start by answering a couple here by way of introduction and will go through the other questions in later posts.

How do the strategies for OMTP and WebRender relate? Would OMTP have benefits for expensive blob rasterization since that used Skia?

OMTP, for off-main-thread painting, is a project completely separate from WebRender that was implemented by Ryan. Without WebRender, painting used to happen on the main thread (the thread that runs the JS event loop). Since this thread is often the busiest, moving things out of it, for example painting, is a nice win for multi core processors since the main thread gets to go back to working on JS more quickly while painting is carried out in parallel. This work is pretty much done now and Ryan is working on project Fission.

What about WebRender? WebRender moved all of painting off of the main thread by default. The main thread translates Gecko’s displaylist into a WebRender displaylist which is sent to the GPU process and the latter renders everything. So WebRender and OMTP, while independent projects both fulfill the goal of OMTP which was to remove work from the main thread. OMTP can be seen as a very nice performance win while waiting for WebRender.

Expensive blob rasterization is already carried out asynchronously by the scene builder thread (helped by a thread pool) which means we get with blob rasterization the same property that OMTP provides. This is a good segue to another question:

How do APZ and async scene building tie together?

APZ (for Asynchronous Panning and Zooming) refers to how we organize the rendering architecture in such a way that panning and zooming can happen at a frame rate that is decoupled from the expensive parts of the rendering pipeline. This is important because the perceived performance of the browser largely relies on quickly and smoothly reacting to some basic interactions such as scrolling.

With WebRender there are some operations that can cost more than our frame budget such as scene building and blob image rasterization. In order to keep the nice and smooth feel of APZ we made these asynchronous. In practice this means that when layout changes happen, we re-build the scene and perform the rasterization of blob images on the side while still responding to input events so that we can continue scrolling the previous version of the scene until the new one is ready. I hope this answers the question. Async scene building is one of the ways we “preserve APZ” so to speak with WebRender.

Notable WebRender and Gecko changes

  • Jeff improved performance when rendering text by caching nsFontMetrics references.
  • Jeff removed some heap allocations when creating clip chains.
  • Jeff wrote a tool to find large memcpys generated by rustc.
  • Dan continued working on scene building performance.
  • Kats is helping with the AMI upgrade for Windows.
  • Kats Fixed crashes due to large draw target allocations.
  • Kats Got captures to work on Android.
  • Kvark removed non-zero origin of reference frames stacking contexts and iframes.
  • Kvark made a couple of memcpy optimizations.
  • Kvark fixed replaying a release capture with a debug version of wrench.
  • Kvark prevented tiled blob images from making captures unusable.
  • Matt Improved the performance of displaylist building.
  • Andrew fixed a rendering issue with animated images.
  • Andrew fixed a crash.
  • Glenn landed all of the primitive interning and picture caching patches, will probably enable picture caching soon. (1), (2), (3), (4), (5), (6), (8), (9) and (10). phew!
  • Glenn added a scratch buffer for transient data during frame building.
  • Glenn reduced the size of BrushPrimitive.
  • Glenn added support for float keys in interning.
  • Glenn fixed a bug with the update of uv rects in the texture cache.
  • Nical and Gankro simplified tracking image dirty rects in WebRender.
  • Nical stored tile dirty rects in local space.
  • Nical refactored the blob image related APIs to be able to express some of the things we need for blob image re-coordination.
  • Nical fixed a crash.
  • Nical fixed a memory leak.
  • Sotaro fixed a WebGL crash when Wayland is enabled.
  • Sotaro fixed a rendering issue with SurfaceTexture on Android.
  • Sotaro fixed an intermittent failure related to frame synchronization.
  • Doug put document splitting up for review.

Ongoing work

  • Bobby is working on improving the shader cache.
  • Nical is working on blob image re-coordination.
  • A lot of people in the team keep investigating performance with a focus on scene building and slow memcpys generated by rustc when medium/large structures are moved on the stack.
  • Kats keeps improving the situation on Android.
  • Lee continues improving font rendering.
  • Markus is getting profiling with full symbol information to work on android.

Enabling WebRender in Firefox Nightly

In about:config, set the pref “gfx.webrender.all” to true and restart the browser.

Reporting bugs

The best place to report bugs related to WebRender in Firefox is the Graphics :: WebRender component in bugzilla.
Note that it is possible to log in with a github account.

https://mozillagfx.wordpress.com/2018/11/29/webrender-newsletter-32/


 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку