It seems that CoordinatedDrawingArea is just a copy paste of DrawingAreaImpl with non-accelerated code path removed. There's actually nothing (or very little) specific to coordinated graphics in the CoordinatedDrawingArea implementation.
Created attachment 282340 [details] Patch
Comment on attachment 282340 [details] Patch If you could get rid of DrawingAreaImpl, that would be great. I sent out an e-mail telling people that I'd like to get rid of it a while back.
(In reply to comment #2) > Comment on attachment 282340 [details] > Patch > > If you could get rid of DrawingAreaImpl, that would be great. I sent out an > e-mail telling people that I'd like to get rid of it a while back. Not yet. The GTK+ port still enters/leaves AC mode when required, so we still need the non accelerated code path. We plan to switch to using the threaded compositor, which forces AC mode, but it's not really ready yet. Good thing is that after this patch, once we switch to threaded compositor, we can just remove DrawingAreaImpl and use AcceleratedDrawginArea. In the meantime, since Impl is only used by the GTK+ port, I can rename it to DrawingAreaGtk and move it to WebPage/gtk dir.
Created attachment 282750 [details] Updated patch This should apply now
Comment on attachment 282750 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=282750&action=review > Source/WebKit2/WebProcess/WebPage/AcceleratedDrawingArea.cpp:91 > +void AcceleratedDrawingArea::scroll(const IntRect& scrollRect, const IntSize& scrollDelta) > +{ > + if (!m_isPaintingEnabled) > + return; > + > + m_layerTreeHost->scrollNonCompositedContents(scrollRect); > +} > + > +void AcceleratedDrawingArea::pageBackgroundTransparencyChanged() > +{ > + if (m_layerTreeHost) > + m_layerTreeHost->pageBackgroundTransparencyChanged(); > +} These differences in null-checking m_layerTreeHost are annoying.
Committed r202855: <http://trac.webkit.org/changeset/202855>