Keep in mind that Servo without WR doesn't do dirty rects and invalidation either. (I had patches to do it but they weren't complete and bitrotted.)
The question in my mind is whether it'd be better to build the CPU fallback on top of WebRender or whether it's best to build it on top of Skia. There are ways to build invalidation on top of WebRender, so I'm not sure we gain much by keeping the old painting code around. Furthermore, WebRender 2 has the potential to make invalidation and dirty rects easy. It's not clear whether WR2 will work, but signs are positive enough that there's a good chance that any invalidation work we did today would be obsoleted by the WR2 effort. The upshot to me is that it's likely that maintaining the existing painting code will not prove helpful for invalidation work anyhow. Patrick On Mar 28, 2016 1:50 PM, "Bobby Holley" <bobbyhol...@gmail.com> wrote: > In general, does the software-fallback path for WebRender mean "really > really slow"? If WebRender avoids dirty-rects on the grounds that painting > is free, then a GL-based software path is going to be a lot slower than a > classic software rendering path. > > On Mon, Mar 28, 2016 at 10:33 AM, <lbergst...@mozilla.com> wrote: > > > On Monday, March 21, 2016 at 11:45:06 AM UTC-5, Jack Moffitt wrote: > > > I propose the following straw man transition plan: > > > > > > 1. Keep -c, -g, -w command line options as they are, but switch the > > > default setting to WebRender. > > > 2. Remove -g. > > > 3. Add in an llvmpipe software-only fallback and replace -c with that. > > > > I like this plan, or at least the first two steps of it. Does #1 require > > getting any additional WPT/CSS tests working, or is WebRender basically > > already there? > > > > I think #3 might need some more thought to figure out what scenarios it > > will support (printing? X11 remoting? headless mode?) to see if llvmpipe > > will support all of those scenarios. But it'd be great if it did and > would > > let us reduce the number of rendering backends. > > - Lars > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
