[webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the WebKit implementation. Others are also (based on bugs reported) working on this. BR Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accelerated 2D Tesselation Implementation
I think Mr. Russell has changed tesseleration code from glu tesseleration to LoopBlinn algorithm. Does it mean that LoopBlinn algorithm is better than glu tesseleration? If yes, why? You mentioned your second trial was Kokojima's algorithm that was detrimental to performance. Why is the LoopBlinn algorithm better than glu tesseleration although Kokojima's algorithm is horrible? I think Kokojima's algorithm is faster than LoopBlinn algorithm. And what are really horrible edge cases on Kokojima's algorithm? 2010/8/28 Chris Marrin cmar...@apple.com On Aug 27, 2010, at 4:21 PM, Kenneth Russell wrote: On Fri, Aug 27, 2010 at 10:18 AM, Chris Marrin cmar...@apple.com wrote: Hi Ken, It would help me, and I think many others, if we could have a discussion of how exactly your tessellation logic works and what it is intended to do. For instance, is the algorithm you're using based on Loop-Blinn? I'm a bit familiar with that algorithm and some of the problems it has with rendering this type of geometry. For instance, there are typically anti-aliasing artifacts at the points where the interior triangles touch the edges. These are described in section 5.1 of the paper and the authors added additional (and not well described) logic to solve the problem. If you could describe your algorithm a bit and show some expected results with typical cases, that would be really helpful. For those not familiar with Loop-Blinn, here is a link to their original paper, presented at Siggraph 2005: Resolution Independent Curve Rendering using Programmable Graphics ... It's a great algorithm for rendering resolution independent 2D objects using the GPU. It has potential to render both 2D shapes (as used in Canvas and SVG) and text glyphs. It's advantage is that once you generate the triangles for the shape, you can render the shape at any resolution. It's disadvantage is that the triangle generation is quite expensive, so mutating shapes can potentially be slower than a simpler resolution dependent tessellation. The code that is out for review (see https://bugs.webkit.org/show_bug.cgi?id=44729 ) is, as described in the bug report, precisely an implementation of Loop and Blinn's algorithm. It comes from their simplified reformulation in Chapter 25 of GPU Gems 3, which can be found online at http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html . Ok, great, thanks. That makes everything much more clear. Their GPU Gems chapter discusses the antialiasing artifacts you mention, where interior triangles not handled by their shader touch the surface of the shape. They point out that enabling multisampling antialiasing solves this problem; the contents of these pixels are antialiased via MSAA, and the pixels covered by their shader are handled by their antialiasing formula. My own experience has been that this works very well; there are no distinguishable bumps or aliasing artifacts with both MSAA enabled and using the antialiasing version of their shader. Yeah, this is what I thought might be the solution. The problem with multisampling is that it's not hardware accelerated everywhere and where it is, it increases expense in both storage and rendering time. I'm not saying this is a showstopper, it's just an issue. So here's my concern. If you have to multisample for anti-aliasing anyway, why not just tesselate the shape at an appropriate sampling resolution and multisample the resulting triangle rendering. That would have the disadvantage of not being resolution independent, but it would be much simpler. And you can control the re-tessellation by oversampling the curve and only re-tesselating every few frames (maybe in the background) or only re-tesselating when not animating, or something like that. Would it be significantly faster or slower? Would the quality be better or worse? We'd have to run some tests. I just don't want to jump into a big expensive algorithm when something simpler would suffice. This is actually the second implementation of this algorithm I have done. In the first, we did much more experimentation, including trying Kokojima et al's stencil buffer algorithm rather than tessellating the interior of the shape. We found that the increased fill rate requirements of Kokojima's technique was detrimental to performance, and that it was better to tessellate to reduce overdraw. Yeah, I can see that algorithm have some really horrible edge cases. In my first implementation of this algorithm, we found that detecting and resolving overlaps of cubic curve control points (section 25.4 in the GPU Gems 3 chapter) was by far the most expensive part of the algorithm. It is also absolutely necessary in order to handle arbitrary inputs. After some investigation I realized that the plane-sweep algorithm mapped well to the problem of detecting overlaps of control point triangles, and
Re: [webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
For those interested, the cover bug for this work is here: https://bugs.webkit.org/show_bug.cgi?id=56459 -Tony On Fri, May 13, 2011 at 8:27 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the WebKit implementation. Others are also (based on bugs reported) working on this. BR Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question on Inline element
On Thu, May 12, 2011 at 10:52 PM, Mustafizur Rahaman mustaf.h...@gmail.comwrote: So my question is - Can a paragraph element contain an image element= the html spec does not say NO. Yes. There are two specs at play here. HTML and CSS. Ignore anything prior to HTML5 as it was proscriptive rather than descriptive and does not match what browsers and web authors actually use! image (aka img) is just an inline element. (Like span or b or i, etc.) and flows with inline children per the CSS spec. (See CSS 2.1). So Paragraph, which is a block, can contain as many inline children as its little heart desires. img happens to be a replaced element, so it has intrinsic size (again see CSS 2.1). Inline children (with the exception of inline blocks, which are blocks which flow as inlines) CANNOT contain box children (blocks are boxes), so for example spanp/p/span would be invalid and cause a special type of craziness called a continuation, where the spans inline contents are split in two, wrapped in anonymous blocks, and the two anonymous wrappers and the P are all children off the parent instead of the P being a child of the span. - If we make the image element neither float/nor positioned, it creates an anomynous block everything is rendered properly. But I am not sure whether that is the right approach. Images will only end up getting wrapped in anonymous blocks when they're in a block with other box children. For example: divimgdiv/div/div will cause the img to get wrapped in an anonymous block. This is due to he CSS rule that blocks may contain either all inline children OR all box/block children. Thus since it has one block child (the div) the img has to get wrapped in an anymous block to keep with the rule. http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level Can any one please throw some light here help us out. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
That sounds like about 8 features. Seems we should think about this in smaller chunks... On the surface peer to peer video conferencing does not seem like something appropriate to add to WebCore/WebKit. Just like an API for reading my email is out of scope for the project. (But certainly lots of people build such things on top of WebKit.) :) -eric On Fri, May 13, 2011 at 6:19 AM, Tony Gentilcore to...@chromium.org wrote: For those interested, the cover bug for this work is here: https://bugs.webkit.org/show_bug.cgi?id=56459 -Tony On Fri, May 13, 2011 at 8:27 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the WebKit implementation. Others are also (based on bugs reported) working on this. BR Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On 05/12/2011 05:16 PM, Lucas De Marchi wrote: Hi Holger Freyther, I'm glad to hear you will use CMake as the build system. Take a look on the email I sent yesterday porting GTK to CMake, maybe it will help you. Since Android and Chromium/Linux have overlaps, do you think it'd be easy to build the Chromium port as well? I am not sure about Chromium. When one tries to build Chromium a lot of external code will be downloaded, I don't have the things in my tree right now but IIRC these external modules are all having Gyp files so one would need to convert these dependencies and it will be quite some work. I am having one specific issue with CMake right now, do you think it would be possible to have defaults for WEBKIT_FEATURE(ENABLE_AS_IMAGE Enable SVG as image DEFAULT ON SVG)? E.g. I need to define ENABLE_GLIB as otherwise I end up having a '#define ENABLE_GLIB' in the cmakeconfig.h breaking the build. regards holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On Fri, May 13, 2011 at 5:35 PM, Holger Freyther ze...@selfish.org wrote: On 05/12/2011 05:16 PM, Lucas De Marchi wrote: Hi Holger Freyther, I'm glad to hear you will use CMake as the build system. Take a look on the email I sent yesterday porting GTK to CMake, maybe it will help you. Since Android and Chromium/Linux have overlaps, do you think it'd be easy to build the Chromium port as well? I am not sure about Chromium. When one tries to build Chromium a lot of external code will be downloaded, I don't have the things in my tree right now but IIRC these external modules are all having Gyp files so one would need to convert these dependencies and it will be quite some work. Hummn... too bad. Looking at the gyp files, it doesn't seem difficult to convert them. But indeed it's quite some work. I am having one specific issue with CMake right now, do you think it would be possible to have defaults for WEBKIT_FEATURE(ENABLE_AS_IMAGE Enable SVG as image DEFAULT ON SVG)? E.g. I need to define ENABLE_GLIB as otherwise I end up having a '#define ENABLE_GLIB' in the cmakeconfig.h breaking the build. This is exactly the reason why I committed r86370 when doing the GTK port. Now you can do as I did for GTK: WEBKIT_FEATURE(ENABLE_GLIB_SUPPORT Enable Glib support ALWAYS ON) or ALWAYS OFF if you meant to unconditionally disable it. regards, Lucas De Marchi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On 05/13/2011 10:48 PM, Lucas De Marchi wrote: This is exactly the reason why I committed r86370 when doing the GTK port. Now you can do as I did for GTK: WEBKIT_FEATURE(ENABLE_GLIB_SUPPORT Enable Glib support ALWAYS ON) or ALWAYS OFF if you meant to unconditionally disable it. Is it a worthy goal to get the OptionsPort.txt file smaller (e.g. by having the default defaults)? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On Fri, May 13, 2011 at 5:59 PM, Holger Freyther ze...@selfish.org wrote: On 05/13/2011 10:48 PM, Lucas De Marchi wrote: This is exactly the reason why I committed r86370 when doing the GTK port. Now you can do as I did for GTK: WEBKIT_FEATURE(ENABLE_GLIB_SUPPORT Enable Glib support ALWAYS ON) or ALWAYS OFF if you meant to unconditionally disable it. Is it a worthy goal to get the OptionsPort.txt file smaller (e.g. by having the default defaults)? Humn... now I see what you're saying. I don't know if it's worth because that would give the user the option to turn it on. Not all options work with every port and doing so will result in a build break. So what we did is let all options turned off by default, without giving the option to turn it on. This is done by letting the #define ENABLE_BLA in cmakeconfig.cmake. The macro ENABLE(BLA) will expand to 0 in this case. If it doesn't (like you said about GLIB, IMO that is a bug). I'll take a look if it's expanding as it should. Lucas De Marchi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
Am 13.05.2011 um 23:07 schrieb Lucas De Marchi: Humn... now I see what you're saying. I don't know if it's worth because that would give the user the option to turn it on. Not all options work with every port and doing so will result in a build break. So what we did is let all options turned off by default, without giving the option to turn it on. This is done by letting the #define ENABLE_BLA in cmakeconfig.cmake. The macro ENABLE(BLA) will expand to 0 in this case. If it doesn't (like you said about GLIB, IMO that is a bug). We should have some usual defaults, so not every port needs to define all of them. E.g. SVG will work with nearly every port. The OptionsXXX.cmake files should only override the defaults provided by OptionsCommon.cmake. I don't think it's a good idea to maintain new/removed defines for every port. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On Fri, May 13, 2011 at 1:35 PM, Holger Freyther ze...@selfish.org wrote: On 05/12/2011 05:16 PM, Lucas De Marchi wrote: Hi Holger Freyther, I'm glad to hear you will use CMake as the build system. Take a look on the email I sent yesterday porting GTK to CMake, maybe it will help you. Since Android and Chromium/Linux have overlaps, do you think it'd be easy to build the Chromium port as well? I am not sure about Chromium. When one tries to build Chromium a lot of external code will be downloaded, I don't have the things in my tree right now but IIRC these external modules are all having Gyp files so one would need to convert these dependencies and it will be quite some work. When I investigated switching the Chromium port to CMake, there were two approaches that seemed plausible. One approach would be to have CMake generate GYP files and then build using the generated GYP files, but that seemed to telescope in complexity. Another approach would be to have GYP essentially be a wrapper around CMake and have CMake drive the building of webkit.a (or whatever the static library is called). In that approach, we'd then build the dependencies as usual with GYP and link everything together at the end. Of the two, the second seemed more desirable. Adam I am having one specific issue with CMake right now, do you think it would be possible to have defaults for WEBKIT_FEATURE(ENABLE_AS_IMAGE Enable SVG as image DEFAULT ON SVG)? E.g. I need to define ENABLE_GLIB as otherwise I end up having a '#define ENABLE_GLIB' in the cmakeconfig.h breaking the build. regards holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
One approach we talked about at the contributor's meeting to dealing with the ever-growing feature list of WebCore is modularity. Looking at the specification for this feature, there doesn't seem to be much interdependence between these APIs and the rest of WebCore. For example, there's nothing that couples with dom, css, or rendering. Would it make sense to try building this feature as a self-contained module? For example, you could imagine the following dependency diagram: WebKit - WebP2P || |\/ + WebCore Ideally, WebCore would have some moderately well-defined interface for these modules, much like the WebKit -- WebCore interaction is mediated by clients. Ideally, these modules would just describe themselves using WebIDL and we could just generated bindings for them. As another example, webaudio might also profit from such as design. Of course, splitting this feature off into its own module doesn't remove all the costs of the new feature, but it would make it easier to work on WebCore proper without having to deal with all the complexities of every feature. Adam On Fri, May 13, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote: That sounds like about 8 features. Seems we should think about this in smaller chunks... On the surface peer to peer video conferencing does not seem like something appropriate to add to WebCore/WebKit. Just like an API for reading my email is out of scope for the project. (But certainly lots of people build such things on top of WebKit.) :) -eric On Fri, May 13, 2011 at 6:19 AM, Tony Gentilcore to...@chromium.org wrote: For those interested, the cover bug for this work is here: https://bugs.webkit.org/show_bug.cgi?id=56459 -Tony On Fri, May 13, 2011 at 8:27 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the WebKit implementation. Others are also (based on bugs reported) working on this. BR Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On Fri, May 13, 2011 at 6:07 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: So what we did is let all options turned off by default, without giving the option to turn it on. This is done by letting the #define ENABLE_BLA in cmakeconfig.cmake. The macro ENABLE(BLA) will expand to 0 in this case. If it doesn't (like you said about GLIB, IMO that is a bug). I'll take a look if it's expanding as it should. The build indeed breaks in this case. Proposed solution: https://bugs.webkit.org/show_bug.cgi?id=60820 Lucas De Marchi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
