Re: [webkit-dev] Help regarding rendering in webkit2 port of haiku
On Mon, Jun 10, 2019 at 10:33 AM Adrien Destugues wrote: > On Mon, Jun 10, 2019 at 09:37:06AM +0300, Noam Rosenthal wrote: > > ~ (reposting from webkit email) > > Hi, > > Another limitation we hit on some websites is that it is not possible > for us to create too many drawable offscreen bitmaps. There is a > system-wide limit of 4096, which can be hit rather easily on Google > Maps, for example. So we will probably need a way to limit the use of > drawable bitmaps when possible. Maybe coordinated graphics would help > here, if it allows to share a single drawing context and bitmap, rather > than creating a separate one for each rendering layer. > I would consider using CoordinatedGraphics with something like a display list, where the drawing commands are sent via webkit2 to the UI process and then everything is painted in the UI process in one go. This would be the most memory-stingy approach, though it would mean zero acceleration and would cancel out any benefit of compositing - compositing uses memory to reduce drawing commands but when memory is what's expensive there's no point in that... you would need to play with this to get the best memory/cpu cost/benefit. > > On the way drawing works for us: the drawing primitives are all > implemented in our display server, there is no rendering done client > side in webkit processes. This means the display server has a pointer to > the bitmap data already, and ideally it would be able to pass this from > one application to another without needing to copy all the data. We may > need to make some changes to our display server to allow this, but > that's fine (it's the nice thing about Haiku, if we need to change > something in the OS, we can do that easily). > > Now we have to find out if coordinated graphics or some other way to do > things makes sense, and for this we have to understand how the rendering > work is split between web process and ui process, and what kind of data > they expect to exchange between them. Especially in our case where the > bitmap data is in fact already shared with the OS display server, so if > UI process does not do any drawing by itself, it doesn't actually need > to access the data. > > -- > Adrien. > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Help regarding rendering in webkit2 port of haiku
On Mon, Jun 10, 2019 at 09:37:06AM +0300, Noam Rosenthal wrote: > ~ (reposting from webkit email) Hi, I should pprobably give a little more context here, as the maintainer of the WebKitLegacy port for Haiku. Our main concern, as Rajagopalan mentionned, is that Haiku does not have any rendering acceleration, it's all done in software. We do have OpenGL but it may not be the best choice for rendering, because of this. As a result, we had to find a way to get things working, in what is indeed a little unusual setup. Currently we have coordinated graphics disabled: Source/cmake/OptionsHaiku.cmake:add_definitions(-DUSE_COORDINATED_GRAPHICS=0) We do however have a software rendering version of texture mapper, that was removed from webkit long time ago but we kept because we didn't want to use the OpenGL version. I have not reviewed its use recently, maybe it is not needed anymore. Another limitation we hit on some websites is that it is not possible for us to create too many drawable offscreen bitmaps. There is a system-wide limit of 4096, which can be hit rather easily on Google Maps, for example. So we will probably need a way to limit the use of drawable bitmaps when possible. Maybe coordinated graphics would help here, if it allows to share a single drawing context and bitmap, rather than creating a separate one for each rendering layer. On the way drawing works for us: the drawing primitives are all implemented in our display server, there is no rendering done client side in webkit processes. This means the display server has a pointer to the bitmap data already, and ideally it would be able to pass this from one application to another without needing to copy all the data. We may need to make some changes to our display server to allow this, but that's fine (it's the nice thing about Haiku, if we need to change something in the OS, we can do that easily). Now we have to find out if coordinated graphics or some other way to do things makes sense, and for this we have to understand how the rendering work is split between web process and ui process, and what kind of data they expect to exchange between them. Especially in our case where the bitmap data is in fact already shared with the OS display server, so if UI process does not do any drawing by itself, it doesn't actually need to access the data. -- Adrien. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Help regarding rendering in webkit2 port of haiku
>btw I might be able to help out (no promises), I haven't touched WebKit code in a few years but I was responsible for TextureMapper and the coordinated graphics system and I like bizarre >projects (a Haiku port sounds like one). Let's see how it goes :) Sure thank you for very great insite will look into to it and get back :) Regards G.Rajagoapalan On Mon, Jun 10, 2019 at 12:07 PM Noam Rosenthal wrote: > ~ (reposting from webkit email) > > Hello! > I suggest starting by learning one of the other ports - like GTK - how the > whole flow works from the windowing system to WebCore to the graphics > system. Read the code, run it in debug mode and put breakpoints, get those > aha moments of how it all works together. > > Note that coordinated graphics is not automatically the right choice for > every port - it was created for mobile windowing systems where window > context-switching was expensive and single-context hardware acceleration > was cheap. If you're looking for a guide check out > https://trac.webkit.org/wiki/CoordinatedGraphicsSystem, hopefully it's > still somewhat valid. I would start there by understanding the flow and how > it fits with the Haiku architecture, seems like you've started doing that > already. you're on the right track there. > > btw I might be able to help out (no promises), I haven't touched WebKit > code in a few years but I was responsible for TextureMapper and the > coordinated graphics system and I like bizarre projects (a Haiku port > sounds like one). Let's see how it goes :) > > > On Mon, Jun 10, 2019 at 9:05 AM Rajagopalan Gangadharan < > g.raju2...@gmail.com> wrote: > >> Hello everybody, >> >> A quick look back on what we have done so far. We are trying to port >> webkit2 to haiku and we have a working IPC with us. So the next step i >> presume is to be rendering. >> >> I did few amount of research and have few basic ideas. Correct me if I am >> wrong. >> >> 1) The rendering takes place in webprocess over a shared bitmap which is >> then rendered onto the client area in UIProcess. >> >> 2) Webkit uses coordinated graphics system which relies on OPENGL. >> >> So we look forward to get the rendering step done or is there anything we >> should take care in between? . >> Our platform doesnt have hardware accelerated OpenGL yet we have software >> implementation vesa which we tend not to use. >> We have a working texture mapper and compositing coordinator from our >> webkit legacy port. I think this makes up the entire compositing >> coordinator. >> >> So it would be of great help if any tells how could we proceed like what >> should be our next move. Perhaps a small guide would be better. >> >> Thank you >> >> Regards >> G.Rajagopalan >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Help regarding rendering in webkit2 port of haiku
~ (reposting from webkit email) Hello! I suggest starting by learning one of the other ports - like GTK - how the whole flow works from the windowing system to WebCore to the graphics system. Read the code, run it in debug mode and put breakpoints, get those aha moments of how it all works together. Note that coordinated graphics is not automatically the right choice for every port - it was created for mobile windowing systems where window context-switching was expensive and single-context hardware acceleration was cheap. If you're looking for a guide check out https://trac.webkit.org/wiki/CoordinatedGraphicsSystem, hopefully it's still somewhat valid. I would start there by understanding the flow and how it fits with the Haiku architecture, seems like you've started doing that already. you're on the right track there. btw I might be able to help out (no promises), I haven't touched WebKit code in a few years but I was responsible for TextureMapper and the coordinated graphics system and I like bizarre projects (a Haiku port sounds like one). Let's see how it goes :) On Mon, Jun 10, 2019 at 9:05 AM Rajagopalan Gangadharan < g.raju2...@gmail.com> wrote: > Hello everybody, > > A quick look back on what we have done so far. We are trying to port > webkit2 to haiku and we have a working IPC with us. So the next step i > presume is to be rendering. > > I did few amount of research and have few basic ideas. Correct me if I am > wrong. > > 1) The rendering takes place in webprocess over a shared bitmap which is > then rendered onto the client area in UIProcess. > > 2) Webkit uses coordinated graphics system which relies on OPENGL. > > So we look forward to get the rendering step done or is there anything we > should take care in between? . > Our platform doesnt have hardware accelerated OpenGL yet we have software > implementation vesa which we tend not to use. > We have a working texture mapper and compositing coordinator from our > webkit legacy port. I think this makes up the entire compositing > coordinator. > > So it would be of great help if any tells how could we proceed like what > should be our next move. Perhaps a small guide would be better. > > Thank you > > Regards > G.Rajagopalan > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Help regarding rendering in webkit2 port of haiku
Hello everybody, A quick look back on what we have done so far. We are trying to port webkit2 to haiku and we have a working IPC with us. So the next step i presume is to be rendering. I did few amount of research and have few basic ideas. Correct me if I am wrong. 1) The rendering takes place in webprocess over a shared bitmap which is then rendered onto the client area in UIProcess. 2) Webkit uses coordinated graphics system which relies on OPENGL. So we look forward to get the rendering step done or is there anything we should take care in between? . Our platform doesnt have hardware accelerated OpenGL yet we have software implementation vesa which we tend not to use. We have a working texture mapper and compositing coordinator from our webkit legacy port. I think this makes up the entire compositing coordinator. So it would be of great help if any tells how could we proceed like what should be our next move. Perhaps a small guide would be better. Thank you Regards G.Rajagopalan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
