Drawing pre-painted tiles that don't match the latest commit is going to cause bad visual artifacts. (e.g. video tearing at the tile boundary.) It is possible that this is done already (please say so). But if not it is a placeholder for me to come back to soon.
I don't think this is needed. During every commit, we toss every tile on the impl side and then only sync the valid and non-dirty ones over. Take a look at TiledLayerChromium::pushPropertiesTo.
(In reply to comment #1) > I don't think this is needed. > > During every commit, we toss every tile on the impl side and then only sync the valid and non-dirty ones over. Take a look at TiledLayerChromium::pushPropertiesTo. Also, if anything, we're too conservative. If a tile gets invalidated during paint, we won't sync it over even though its contents are technically valid for that frame.
(In reply to comment #1) > I don't think this is needed. > > During every commit, we toss every tile on the impl side and then only sync the valid and non-dirty ones over. Take a look at TiledLayerChromium::pushPropertiesTo. I am freshly confused what the purpose of layerTreeHost()->deleteTextureAfterCommit() is then. If we just allocated a new texture on paint side, the impl side should be deleted anyways?
(In reply to comment #3) > (In reply to comment #1) > > I don't think this is needed. > > > > During every commit, we toss every tile on the impl side and then only sync the valid and non-dirty ones over. Take a look at TiledLayerChromium::pushPropertiesTo. > > I am freshly confused what the purpose of layerTreeHost()->deleteTextureAfterCommit() is then. If we just allocated a new texture on paint side, the impl side should be deleted anyways? It's to support interleaved uploads. If a texture is currently in use on the impl side, you can't reuse that texture id if you're going to interleave drawing while you upload and before the commit is done. So, you allocate a new id and mark the old one as no longer needed once the commit completes.
(In reply to comment #1) > I don't think this is needed. > > During every commit, we toss every tile on the impl side and then only sync the valid and non-dirty ones over. Take a look at TiledLayerChromium::pushPropertiesTo. It shouldn't be possible to get artifacts from the current system. Dana and I talked about this yesterday. This isn't really a problem with the current system, it's just an observation: Dirty tile textures are not actually deleted (as in context3D->deleteTexture being called). That's part of the design and the texture manager's ability to reuse textures. Would we want some exceptions to this now that we we have pre-painting? I guess it could possibly be worth not deleting dirty non-visible tile textures but deleting dirty non-visible pre-painted tile textures. Basically having a different memory limit for pre-painted tiles. I'm not convinced but figured raising the question wouldn't hurt.
I get how this works now