| | 46 | |
| | 47 | |
| | 48 | = Simon’s 5 year plan = |
| | 49 | |
| | 50 | == What have we done == |
| | 51 | |
| | 52 | * Hyatt did Optimizing layout |
| | 53 | * IndexedDB rewrite in progress |
| | 54 | |
| | 55 | == What now? == |
| | 56 | |
| | 57 | Every year we say we’re going to do these things. |
| | 58 | |
| | 59 | * Cleaning up the loading code |
| | 60 | * Page cache cleanup |
| | 61 | |
| | 62 | '''Chris''' worked on page cache and added sanity checks for holding on to cache. |
| | 63 | |
| | 64 | '''Antii''' We should get rid of page cache and replace it with something more robust. A WebKit2 level cache. |
| | 65 | |
| | 66 | Long term plan is to eliminate Page Cache. Let’s call it a 5-year plan. |
| | 67 | |
| | 68 | = Standards Things = |
| | 69 | |
| | 70 | * Maintains status on all the CSS properties |
| | 71 | * Should it be prefixed, iTunes-only flag, other flags |
| | 72 | * We need infrastructure here |
| | 73 | * Could add comments to css-properties.in |
| | 74 | * '''Chris''' We have tons of prefixed IDL attributes |
| | 75 | * Event Loop |
| | 76 | * DOM event loop spec for event timers, requestAnimationFrame, etc. These should all spawn out of the same code. We should organize our code into a more explicit concept of an event loop. |
| | 77 | * Long term we should see if we agree with the spec |
| | 78 | * Fetch API |
| | 79 | * We should do this. |
| | 80 | * '''Sam''' Attempt to define loading for the web platform. It has an XHR like API. This is really a pre-req for Service Workers. Sub resource integrity spec and others that are related. |
| | 81 | * Service Workers |
| | 82 | * People think they want it, some of them actually do want it. We should probably do it. |
| | 83 | * Event handler attributes |
| | 84 | * Avoid synchronous touch events. Trackers will do event handlers to track page usage, and it always falls into synchronous touch events. |
| | 85 | * Intersection observer |
| | 86 | * Ad vendors register event listeners when the ad is visible in the viewport |
| | 87 | * Listing for scroll events |
| | 88 | * Allows for detecting when ads are visible |
| | 89 | * don’t have to do forced layouts to give them the answer |
| | 90 | * Other use case: infinite scrolling lists |
| | 91 | * Scroll-linked effects |
| | 92 | * A proposal to allow fast scrolling while having things react on the page to the scroll. Think parallax or video scrubbing while scrolling |
| | 93 | * Houdini proposal |
| | 94 | * UI workers run little isolated scripts that gets scroll position things and can modify scroll position but doesn’t otherwise have access to the DOM |
| | 95 | |
| | 96 | == Page & friends == |
| | 97 | |
| | 98 | * Page/Frame/FrameView/FrameLoader disambiguation |
| | 99 | * '''Sam''' There are spec names that are really long and obnoxious. Curious about what people think? |
| | 100 | * '''Ted''' MainFrame is a good term from a retro perspective |
| | 101 | * '''Sam''' How this works and the split window makes this complicated |
| | 102 | * '''Beth''' Eliminating scroll view/merge it with scrollable area, or combining with FrameView |
| | 103 | * '''Sam''' I believe that FrameView isn’t necessary and could be RenderView owning the drawing. What is the value of having both RenderView and FrameView? |
| | 104 | * '''Simon''' disagrees. |
| | 105 | * '''Sam''' RenderLayer and FrameView knows about scrolling. Overflow scroll is handled separately. |
| | 106 | * RenderLayer should have a ScrollableArea; FrameView has a ScrollableArea. |
| | 107 | * Unify scrolling architecture |
| | 108 | * Four scrolling architectures WebKit1 NSScrollView, WK2 ScrollingTree, iOS WK1 uses UIScrollView, iOS WK2 uses UI side compositing. oh and GTK scrolling like WK2 Mac scrolling. ScrollingThread and the slow path. Hit the slow path when hitting the page-up/page-down keys. |
| | 109 | * Get WebKit1 scrolling out of WebCore |
| | 110 | * '''Sam''' Zero-benefit except for code cleanness |
| | 111 | * '''Simon''' may break apps as well |
| | 112 | |
| | 113 | == Code Org == |
| | 114 | |
| | 115 | * PAL |
| | 116 | * '''Myles''' Platform abstraction/library code bits implemented diff on diff platforms. It is the conceptual API between Platform folder and WebCore. This is really for code cleanliness. |
| | 117 | * '''Simon''' Benefit is strict layering. Allows unit testing library code that we can’t currently test. |
| | 118 | * '''Myles''' Most of the test code is in the platform directory. |
| | 119 | * '''Simon''' We’ll want it for Web Animations and Display List |
| | 120 | * '''Myles''' Intend to make it over Thanksgiving. |
| | 121 | |
| | 122 | == Layout & Rendering == |
| | 123 | |
| | 124 | * '''Simon''' Zalan thinking render tree immutable and read-only |
| | 125 | * '''Zalan''' Make it only for layout. We can control layout tree. Decouple as much as possible. Then optimize the layout. |
| | 126 | * '''Ryosuke''' We’ve had security bugs related to changing Render Tree. |
| | 127 | * '''Antii''' Generate another tree for box placement, painting operates on that. |
| | 128 | * '''Ryosuke''' A lot of ops that mutate the render tree. List markers, counters, etc. Problem is all these things are cause of crashes. |
| | 129 | * '''Antii''' We should organize our code for correctness and security. Solution is more trees. |
| | 130 | * '''Ryosuke''' There is nothing requiring a render object for style. |
| | 131 | * '''Antii''' Appears coupled for historic reasons. |
| | 132 | * '''Ryosuke''' You have DOM tree, Style tree and Layout tree. |
| | 133 | * '''Antii''' I am working on a refactoring that is |
| | 134 | * '''Ryosuke''' We should break the render layer block into smaller pieces. Clipping happens all over the place and shouldn’t have to call render layer |
| | 135 | * '''Antii''' RenderLayer, RenderLayerBacking, GraphicsLayer, RemotePlatformLayer. The layers are too damn high! |
| | 136 | * '''Ryosuke''' Bit of confusion with respect to SVG, MathML, are we doing top-down or bottom-up? It’s all a hot mess. The minimum width computation. We accommodate this is so many different places. Make that explicit: a bottom-up for intrinsic width, then top-down phase. |
| | 137 | * '''Simon''' It would be great, if we had two different read-only render trees you could diff them |
| | 138 | |
| | 139 | == Remove widgets == |
| | 140 | |
| | 141 | * '''Simon''' We can shift sub pixel; widget hierarchy is useless |
| | 142 | * '''Sam''' What happened with plugins? |
| | 143 | * '''Simon''' RenderTree could host plugins; doesn’t matter who owns them really. |
| | 144 | * '''Ryosuke''' DOM should own plugins. RenderObject positions them. Should be fairly easy. Only problem may be scrollable pseudo-elements |
| | 145 | |
| | 146 | == Continuations == |
| | 147 | |
| | 148 | * '''Simon''' One of Hyatt’s favorite things. |
| | 149 | * Hyatt removing continuations. |
| | 150 | |
| | 151 | == Compositing == |
| | 152 | |
| | 153 | * Forced Layout updates render tree every frame |
| | 154 | * Compositing should happen post-display lists |
| | 155 | |
| | 156 | == Debuggability == |
| | 157 | |
| | 158 | * Logging |
| | 159 | * Add more log channels; wish there was a style log channel |
| | 160 | * Different names for WK logging |
| | 161 | * '''Sam''' Would be nice if logging infrastructure could include channel names |
| | 162 | * More TextStream logging becomes very easy to dump hierarchical things with TextStream |
| | 163 | * Ideally we would share one logging mechanism instead of JSC PrintStreamer and WC TextStream |
| | 164 | * `LOG_RESULT()` and `LOG_WITH_STREAM()` We should do more of this. |
| | 165 | * '''Ryosuke''' Annoying to not know where the logging goes. |
| | 166 | * '''Simon''' It logs to syslog or stdout |
| | 167 | * '''Ryosuke''' We should show in stdout where the logging is going. |
| | 168 | * Long term goal: Unify PrintStream and TextStream |
| | 169 | |
| | 170 | == lldb Macros == |
| | 171 | |
| | 172 | * How to debug WebKit on webkit.org |
| | 173 | |
| | 174 | == `notifyutil -p com.apple.WebKit.showRenderTree` == |
| | 175 | |
| | 176 | Also, Hyatt should rewrite CSS Parser. |
| | 177 | |
| | 178 | '''Antoine''' WebCore could use more web technologies. Web Components for form controls. |
| | 179 | |
| | 180 | Shouldn’t be used for layout. Jumping between JS and `C++` would be bad. |
