I'm pretty sure we can (and should) do this in less then 16ms. Especially for applications where latency is more noticeable and strongly avoided (i.e. VR/AR/Gaming).
Please .... please .... i want someone write an expert level book about all this stuff. I know the first part of it because thats how it was done since the days of Motif in 1992. But the second half with GPU acceleration needs much more exposure. I'm buying technical books and many others too. So a new "Petzold" for Android Internals.
How does the browser rendering differ from native rendering? At what point do rendering calls merge towards their way to the monitor? Is it possible for browser rendering to merge at DisplayList?
Why does invlidate() of a child needs to bubble up to the root view? Why traversal needs to happen exhaustively/top-down instead of just merging the changed part and the unchanged part? which doesn't sounds like need the root view to be involved
If my memory serves me, it's because the child may have changed its bounds. If that is the case, parents of that child may need to resize and that might cascade down the entire child/parent tree.
This is a simple case when HWUI and GPU don't involve rendering process directly like play a game. Anyway, those things almost seem to be said before. I wish something news were Vulkan and HWC 2.0 or how HWC compose layers :)
And all of this complexity in 16ms. This blows my mind away. We came really a long way since i did it by poking into my C64 memory buffer.
16 ms? But I want it now....
I'm pretty sure we can (and should) do this in less then 16ms. Especially for applications where latency is more noticeable and strongly avoided (i.e. VR/AR/Gaming).
everything flies with a big enaugh engine
Okay ,probably one of the few videos on the RUclips which I do not have to watch at 1.5X.
From Google I/O 2018, it's very little Frame and Graphics sessions. I think that should have more and more these sessions.
Ahhh... The "good ol' days"
Please .... please .... i want someone write an expert level book about all this stuff. I know the first part of it because thats how it was done since the days of Motif in 1992. But the second half with GPU acceleration needs much more exposure. I'm buying technical books and many others too. So a new "Petzold" for Android Internals.
Romain Guy is my spirit animal
Nice explanation.
Are the slides available somewhere ?
How does the browser rendering differ from native rendering? At what point do rendering calls merge towards their way to the monitor? Is it possible for browser rendering to merge at DisplayList?
Has anything changed in 2024,
If someone knows a videos or article with updates please share it with us.
Why does invlidate() of a child needs to bubble up to the root view? Why traversal needs to happen exhaustively/top-down instead of just merging the changed part and the unchanged part? which doesn't sounds like need the root view to be involved
If my memory serves me, it's because the child may have changed its bounds. If that is the case, parents of that child may need to resize and that might cascade down the entire child/parent tree.
Why use textureView instead of surfaceview in the older version of android?
What's the limits of the surface view compare to texture view? Why surface view cannot be sanwiched?
This is a simple case when HWUI and GPU don't involve rendering process directly like play a game. Anyway, those things almost seem to be said before. I wish something news were Vulkan and HWC 2.0 or how HWC compose layers :)
From where can we get the slides??
are you get the slides?
26:35 is this sync issue really fixed in android?
where is application code and app name, he referred at 34:10
Its "Grafika", on Github: github.com/google/grafika
Romain guy is his name or is he a guy from Romania?
Both, coincidentally
@@KangJangkrik Nah, he's French.
@@sebastienleclerc8772 How do you know?