Re: [webkit-dev] Implementing new WebSocket protocol
There seems to be no strong objection to adding a runtime flag, and I think it will take some time and need multiple patches to get the implementation in good shape. Therefore, I'd like to start to implement behind a runtime flag. It allows each port to control the time to switch protocols, too (of course all ports should be migrated eventually). As a starting point, could somebody review a patch in bug 60348 ( http://webkit.org/b/60348), which only adds a flag? Regards, Yuta ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing new WebSocket protocol
I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? Simon On Jun 23, 2011, at 6:07 AM, Yuta Kitamura wrote: There seems to be no strong objection to adding a runtime flag, and I think it will take some time and need multiple patches to get the implementation in good shape. Therefore, I'd like to start to implement behind a runtime flag. It allows each port to control the time to switch protocols, too (of course all ports should be migrated eventually). As a starting point, could somebody review a patch in bug 60348 (http://webkit.org/b/60348), which only adds a flag? Regards, Yuta ___ 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] Implementing new WebSocket protocol
On 2011-06-23 17:15, Simon Fraser wrote: I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? It does. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Switching away from integers for layout
We’ve been getting an increasing number of complaints lately about the zooming support in webkit and how hard it is to correctly support zooming in complex web applications. To address this we plan to convert the rendering tree to float to allow for better zooming and scaling support. Furthermore this could be expanded to support sub-pixel layout and positioning which in turn would allow higher precision layout when zoomed. We’re the only rendering engine that hasn’t yet made this change. Changing rendering (and hit testing) to use floats does not necessarily mean that we need to expose floats through the dom api, however if we are to support sub-pixel layout (i.e. style=”left: 12.3px”) this would be required. Specifically we’d need to change the offsetLeft/Top/Width/Height properties to return floating point values [2]. We tried two strategies for building a proof of concept, one of which involved accumulating error when laying out with an applied zoom, and the other was a wholesale swap of integers for floats in the layout engine. Ultimately, we discovered that our hopes of the former being a less-invasive solution were lost when the patch grew to the size of the more-invasive latter, and we decided to focus our efforts there. In the span of 10 days, we built a working prototype that passes over 90% of our layout tests and renders most webpages correctly, including our original zooming test cases. There are still numerous rounding errors, but tracking these down and fixing them is beyond the scope of our proof of concept. We’ve uploaded the resulting patch on the meta bug [1] tracking our work. It’s been tested on the Mac and QT ports. To make this transition as painless as possible (read: to avoid landing one massive patch), we plan on first moving our current int values to an abstraction that will begin as a typedef to int and its progeny IntRect, IntPoint, and IntSize. We’ll also implement requisite rounding functionality behind a USE(FLOAT_OFFSETS) [or other name, pending discussion] flag. These steps are transitional only, and this abstraction and USE flag will both be removed once we successfully make the jump from int-float. -- Levi Emil 1: https://bugs.webkit.org/show_bug.cgi?id=60318 - Meta bug, has proof of concept patch and a couple of test cases. 2: https://bugs.webkit.org/show_bug.cgi?id=54018 - Convert offset* to float. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub le...@chromium.org wrote: To address this we plan to convert the rendering tree to float to allow for better zooming and scaling support. Furthermore this could be expanded to support sub-pixel layout and positioning which in turn would allow higher precision layout when zoomed. We’re the only rendering engine that hasn’t yet made this change. I thought Gecko eschewed floats in favor of some sort of more complex fixed-point-esque system. Am I mistaken? I looked on the metabug to see if Hyatt had made comments, but didn't see any. Do you have feedback from him yet? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
I know you made some consideration of fixed point vs. float point in your investigation. I suspect that decision is orthogonal to work of plumbing more precise types through the engine... but I am still curious to know if there was a decision if fixed point or float point might be the eventual unit type for the layout engine? Have you done any investigation as to what sorts of rounding code will be needed? How many places we'll have to round? It seems to me the harder part in getting this right is not the (largely mechanical) plumbing of Float (or whatever precise) types everywhere, but rather deciding which places to round. Do you have some fancy screen shots to share? :) I know you did some investigation as to possible perf affect of this change. Could you share those results too? (Either here or in a bug.) -eric On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub le...@chromium.org wrote: We’ve been getting an increasing number of complaints lately about the zooming support in webkit and how hard it is to correctly support zooming in complex web applications. To address this we plan to convert the rendering tree to float to allow for better zooming and scaling support. Furthermore this could be expanded to support sub-pixel layout and positioning which in turn would allow higher precision layout when zoomed. We’re the only rendering engine that hasn’t yet made this change. Changing rendering (and hit testing) to use floats does not necessarily mean that we need to expose floats through the dom api, however if we are to support sub-pixel layout (i.e. style=”left: 12.3px”) this would be required. Specifically we’d need to change the offsetLeft/Top/Width/Height properties to return floating point values [2]. We tried two strategies for building a proof of concept, one of which involved accumulating error when laying out with an applied zoom, and the other was a wholesale swap of integers for floats in the layout engine. Ultimately, we discovered that our hopes of the former being a less-invasive solution were lost when the patch grew to the size of the more-invasive latter, and we decided to focus our efforts there. In the span of 10 days, we built a working prototype that passes over 90% of our layout tests and renders most webpages correctly, including our original zooming test cases. There are still numerous rounding errors, but tracking these down and fixing them is beyond the scope of our proof of concept. We’ve uploaded the resulting patch on the meta bug [1] tracking our work. It’s been tested on the Mac and QT ports. To make this transition as painless as possible (read: to avoid landing one massive patch), we plan on first moving our current int values to an abstraction that will begin as a typedef to int and its progeny IntRect, IntPoint, and IntSize. We’ll also implement requisite rounding functionality behind a USE(FLOAT_OFFSETS) [or other name, pending discussion] flag. These steps are transitional only, and this abstraction and USE flag will both be removed once we successfully make the jump from int-float. -- Levi Emil 1: https://bugs.webkit.org/show_bug.cgi?id=60318 - Meta bug, has proof of concept patch and a couple of test cases. 2: https://bugs.webkit.org/show_bug.cgi?id=54018 - Convert offset* to float. ___ 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] Switching away from integers for layout
On Jun 23, 2011, at 11:46 AM, Levi Weintraub wrote: We’ve been getting an increasing number of complaints lately about the zooming support in webkit and how hard it is to correctly support zooming in complex web applications. To address this we plan to convert the rendering tree to float to allow for better zooming and scaling support. Furthermore this could be expanded to support sub-pixel layout and positioning which in turn would allow higher precision layout when zoomed. We’re the only rendering engine that hasn’t yet made this change. Changing rendering (and hit testing) to use floats does not necessarily mean that we need to expose floats through the dom api, however if we are to support sub-pixel layout (i.e. style=”left: 12.3px”) this would be required. Specifically we’d need to change the offsetLeft/Top/Width/Height properties to return floating point values [2]. We tried two strategies for building a proof of concept, one of which involved accumulating error when laying out with an applied zoom, and the other was a wholesale swap of integers for floats in the layout engine. Ultimately, we discovered that our hopes of the former being a less-invasive solution were lost when the patch grew to the size of the more-invasive latter, and we decided to focus our efforts there. In the span of 10 days, we built a working prototype that passes over 90% of our layout tests and renders most webpages correctly, including our original zooming test cases. There are still numerous rounding errors, but tracking these down and fixing them is beyond the scope of our proof of concept. We’ve uploaded the resulting patch on the meta bug [1] tracking our work. It’s been tested on the Mac and QT ports. To make this transition as painless as possible (read: to avoid landing one massive patch), we plan on first moving our current int values to an abstraction that will begin as a typedef to int and its progeny IntRect, IntPoint, and IntSize. We’ll also implement requisite rounding functionality behind a USE(FLOAT_OFFSETS) [or other name, pending discussion] flag. These steps are transitional only, and this abstraction and USE flag will both be removed once we successfully make the jump from int-float. While compact, the 32-bit float type has poor precision and doesn’t match some platforms’ graphics layers’ underlying floating-point type (such as CGFloat in 64-bit OS X). As long as you are using a typedef, it might be better to make the render tree floating-point type easily configurable, so that different ports can use (or at least experiment with) different types.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Inconsistency in logging approach
Hello All, I would like to know what do you think about Logging in Release build. Should WebKit allow it? Currently it is not possible because some features (like IconDatabase) use #ifndef NDEBUG for marking LOG macro related code. From the other hand in WebKit2 all logging is based on the #if !LOG_DISABLED macro. Ports approach to logging in Release builds is not consistent too: - GTK and EFL allows to use LOG in Release - Qt it is not possible Personally, I like approach of putting logging related code into #if !LOG_DISABLED macro instead of #ifndef NDEBUG. I prepared small patch to allow building WebKit in Release build and use logging. I'll open ticket in bugzilla, but first I would like to know your opinion about this idea. Regards Lukasz Slachciak ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inconsistency in logging approach
On Jun 23, 2011, at 1:12 PM, Łukasz Ślachciak wrote: Personally, I like approach of putting logging related code into #if !LOG_DISABLED macro instead of #ifndef NDEBUG. As I remember it, my original design for LOG was: 1) Control with LOG_DISABLED, not NDEBUG. 2) Turn off for releases. 3) Feel free to do logging that might make things too slow in a release. 4) Give engineers a way to compile with logging on but leaving, say, assertions off. Correcting the #if to use LOG_DISABLED would be going back to the original design. But I’m surprised that GTK and EFL chose to leave logging on in releases. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] API documentation in cpp files
W dniu 22.06.2011 18:27, Darin Adler pisze: For WebKit API header files, files intended to be used by the clients of WebKit outside the project, I think your proposal makes sense. For an example of a header file in WebKit that is done in this way, you could look at JavaScriptCore/API/JSObjectRef.h. I also think that for API files going to development packages should have some documentation. Maybe for WebKit2 we could use consistent approach and for external API write documentation in header files? Regards Lukasz Slachciak ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inconsistency in logging approach
On 23.06.2011 22:16, Darin Adler wrote: But I’m surprised that GTK and EFL chose to leave logging on in releases. -- Darin They warn user with messaage sth like: WEBKIT_DEBUG is not empty, but this is a release build. Notice that many log messages will only appear in a debug build. Of course to have logging working in GTK you need to turn off LOG_DISABLED macro in Assertions.h. Regards Lukasz Slachciak ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding Persistent Position
Hi, I think we need a PersistentPosition that auto-corrects itself and survives DOM mutations without being orphaned; similar to how Range is automatically updated. Why? 1. ReplaceSelectionCommand and DeleteSelectionCommand have wrapper for removeNode, deleteTextFromNode, etc... to update Positions they maintain. 2. InsertListCommand and IndentOutdentCommand crash all the time because Position get lost in moveParagraph, etc... 3. FrameSelection has a special function that gets called whenever Node is removed to update its end points but VisibleSelection doesn't so endingSelection() becomes stale very easily compared to FrameSelection. On the other hand, adding this new class and instantiating them as member variables of subclasses of CompositeEditCommand may impact performance because CompositeEditCommand stays on the memory even after it's pushed into undo stack. Also, maintaining a pointer (probably from Document) to stack object (although member variables of CompositeEditCommand will end up living in heap) seems like a dangerous design although we could make it ref-counted as well. To address the performance impact, we can modify CompositeEditCommand so that it won't be added to the undo stack. Instead, CompositeEditCommand will create an EditCommandComposition that stores a tree of SimpleEditCommands that inherits from EditCommand and will be added to the undo stack. Any thoughts? Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Persistent Position
On Jun 23, 2011, at 2:43 PM, Ryosuke Niwa wrote: I think we need a PersistentPosition that auto-corrects itself and survives DOM mutations without being orphaned; similar to how Range is automatically updated. I’m not sure that auto-correction has a simple unambiguous meaning. There are rules for what happens to Range objects when a document is modified, but I’m not sure they meet anyones expectations for “still representing the same position”. Why? • ReplaceSelectionCommand and DeleteSelectionCommand have wrapper for removeNode, deleteTextFromNode, etc... to update Positions they maintain. • InsertListCommand and IndentOutdentCommand crash all the time because Position get lost in moveParagraph, etc... • FrameSelection has a special function that gets called whenever Node is removed to update its end points but VisibleSelection doesn't so endingSelection() becomes stale very easily compared to FrameSelection. My main concern about this new class would be that it sounds a lot like Range and a lot like Position yet seems likely it won’t share much code with either. I think that “Persistent” is not the right name for this. A normal Position works just fine. It sticks to the node it’s pointing to. The difference in the new class is that it sticks to something other than the node. What does it stick to? The document? On the other hand, adding this new class and instantiating them as member variables of subclasses of CompositeEditCommand may impact performance because CompositeEditCommand stays on the memory even after it's pushed into undo stack. Doesn’t seem likely to be a practical problem, but I could be wrong. Also, maintaining a pointer (probably from Document) to stack object (although member variables of CompositeEditCommand will end up living in heap) seems like a dangerous design I don’t think that’s dangerous. It’s fine to have pointers into objects, whether on stack or heap, as long as they are maintained correctly, and disconnected when the objects are destroyed. To address the performance impact, we can modify CompositeEditCommand so that it won't be added to the undo stack. Instead, CompositeEditCommand will create an EditCommandComposition that stores a tree of SimpleEditCommands that inherits from EditCommand and will be added to the undo stack. This is a good change. As I see it, a CompositeEditCommand is the “smarts” to do a command the first time, and should be deallocated as soon as the command has been executed. What’s saved behind for undo should be just a string of undoable editing steps, along with things like the command name for the undo menu item. Long term I don’t think we need a tree of undoable editing steps. I suspect a vector of them will do fine. But as an incremental step, I think it would be great to get the smarts for doing commands out of the tree completely. Your specific proposal sounds like a step in the right direction. Later the CompositeEditCommand classes would stop inheriting from EditCommand at all. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing new WebSocket protocol
That said, I don't think the intent should be to support any old versions for any protracted amount of time. -00 has security vulnerabilities brought up by people on webkit-dev@ so from the Chrome side, we intend not to support -00 at all once we have -09 support available. All the makers of server-side code have already published versions compatibile with the latest draft, and IETF drafts are intended to expire after a fixed amount of time (-00 is already well past its expiration date). -Ian On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke julian.resc...@gmx.dewrote: On 2011-06-23 17:15, Simon Fraser wrote: I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? It does. http://tools.ietf.org/html/**draft-ietf-hybi-**thewebsocketprotocol-09#** section-11.11http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11 __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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] Some questions about adobe air version webkit
Hi Arno, I'd like to be included in any discussion as well! -Brent On Jun 16, 2011, at 9:53 PM, Arno Gourdol wrote: Hi Wang, We'll contact you off list and help you get sorted. If anyone else is interested in the discussion on this mailing list, let us know. – Arno On Jun 16, 2011, at 8:36 AM, wang chyz wrote: 1. I compiled adobe air webkit(http://download.macromedia.com/pub/opensource/webkit/webkit_dreamweavercs5_labs_01.zip) on Windows, but it’s size reach to 10m, and Adobe compiled it to 4m, can somebody give me any adives? 2. It seems the webkit version on above address is used in dreamwave and some funtions are missing . How to download other version of air webkit on http://webkit_view:webkit_v...@stlab.adobe.com:8080 ___ 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] Implementing new WebSocket protocol
That said, you're all lucky that the rest of us developers have no idea when the current round of specification flux will settle down. Security vulnerabilities will always trump the specs. Thanks for keeping on top of things. -Charles On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote: That said, I don't think the intent should be to support any old versions for any protracted amount of time. -00 has security vulnerabilities brought up by people on webkit-dev@ so from the Chrome side, we intend not to support -00 at all once we have -09 support available. All the makers of server-side code have already published versions compatibile with the latest draft, and IETF drafts are intended to expire after a fixed amount of time (-00 is already well past its expiration date). -Ian On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke julian.resc...@gmx.de mailto:julian.resc...@gmx.de wrote: On 2011-06-23 17:15, Simon Fraser wrote: I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? It does. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11 ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto: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] Implementing new WebSocket protocol
FWIW it has settled down. The spec is in last call and isn't changing, rather we're just arguing over wording, references in the spec, clarifying text based on implementation experiences and ambiguities implementers have found, etc. On Thu, Jun 23, 2011 at 6:29 PM, Charles Pritchard ch...@jumis.com wrote: ** That said, you're all lucky that the rest of us developers have no idea when the current round of specification flux will settle down. Security vulnerabilities will always trump the specs. Thanks for keeping on top of things. -Charles On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote: That said, I don't think the intent should be to support any old versions for any protracted amount of time. -00 has security vulnerabilities brought up by people on webkit-dev@ so from the Chrome side, we intend not to support -00 at all once we have -09 support available. All the makers of server-side code have already published versions compatibile with the latest draft, and IETF drafts are intended to expire after a fixed amount of time (-00 is already well past its expiration date). -Ian On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke julian.resc...@gmx.dewrote: On 2011-06-23 17:15, Simon Fraser wrote: I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? It does. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing listwebkit-dev@lists.webkit.orghttp://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
