Changes between Version 4 and Version 5 of FiveYearPlanFall2015

Nov 12, 2015 2:06:44 PM (7 years ago)
Jon Davis



  • FiveYearPlanFall2015

    v4 v5  
    4444* lldb macros
    4545* notifyutil -p
     48= Simon’s 5 year plan =
     50== What have we done ==
     52* Hyatt did Optimizing layout
     53* IndexedDB rewrite in progress
     55== What now? ==
     57Every year we say we’re going to do these things.
     59* Cleaning up the loading code
     60* Page cache cleanup
     62'''Chris''' worked on page cache and added sanity checks for holding on to cache.
     64'''Antii''' We should get rid of page cache and replace it with something more robust. A WebKit2 level cache.
     66Long term plan is to eliminate Page Cache. Let’s call it a 5-year plan.
     68= Standards Things =
     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
     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
     96== Page & friends ==
     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
     113== Code Org ==
     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.
     122== Layout & Rendering ==
     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
     139== Remove widgets ==
     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
     146== Continuations ==
     148* '''Simon''' One of Hyatt’s favorite things.
     149* Hyatt removing continuations.
     151== Compositing ==
     153* Forced Layout updates render tree every frame
     154* Compositing should happen post-display lists
     156== Debuggability ==
     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
     170== lldb Macros ==
     172* How to debug WebKit on
     174== `notifyutil -p` ==
     176Also, Hyatt should rewrite CSS Parser.
     178'''Antoine''' WebCore could use more web technologies. Web Components for form controls.
     180Shouldn’t be used for layout. Jumping between JS and `C++` would be bad.