This is an initial patch to start cleaning up how texture uploads are handled by CCTextureUpdater. It doesn't change the interaction with LayerTextureUpdater. It just creates a TextureUploader class that is similar to the current TextureCopier class and allows us to add persistent state to the upload machinery so that we can land: https://bugs.webkit.org/show_bug.cgi?id=81004 The plan is to follow up with patches that moves a lot of the upload logic from the LayerTextureUpdater and LayerTexureSubImage to this new TextureUploader class.
Created attachment 137197 [details] Patch
Comment on attachment 137197 [details] Patch Attachment 137197 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12405225
Created attachment 137229 [details] Patch
Comment on attachment 137229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=137229&action=review > Source/WebCore/platform/graphics/chromium/TextureUploader.h:40 > +class AcceleratedTextureUploader : public TextureUploader { What would a non-accelerated TextureUploader be, out of curiosity?
(In reply to comment #4) > (From update of attachment 137229 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=137229&action=review > > > Source/WebCore/platform/graphics/chromium/TextureUploader.h:40 > > +class AcceleratedTextureUploader : public TextureUploader { > > What would a non-accelerated TextureUploader be, out of curiosity? Heh, hard to say :) I think this will become SubImageTextureUploader as we move the LayerTexureSubImage logic into the uploader class.
Comment on attachment 137229 [details] Patch Clearing flags on attachment: 137229 Committed r114450: <http://trac.webkit.org/changeset/114450>
All reviewed patches have been landed. Closing bug.