UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.50 Safari/537.36 OPR/47.0.2631.23 (Edition beta)

Steps to reproduce the problem:
Move UIResourceLayer with a bitmap between different parent layers using InsertChild.

-- or --

Switch bitmap of a UIResourceLayer multiple times.

All that while not drawing LayerTreeHost, in which case the request queue does not get drained.

What is the expected behavior?
Ideally, only CREATE requests without corresponding DELETE requests in the queue would actually get handed over and incur the cost of creating the resource, like uploading the texture. Memory referred to by the redundant requests should be released in a timely fashion.

What went wrong?
UIResourceManager.DeleteUIResource only checks the known resource map (have we seen a CREATE request for this ID?), but not the queue (was the resource actually created?). As a result, in situations like the ones listed above, you will end up with a queue containing plethora of CREATE + DELETE pairs that are effectively no-ops, but because they are here in the queue:

- Bitmap resource requests keep the memory of a bitmap, growing the heap.
- After requests are handed over, when the drawing finally commences, they are processed in order, by which I mean that all the redundant CREATE requests seem to actually be processed, including any memory allocations and such, only to subsequently delete created resources within the same frame.

Did this work before? No 

Chrome version: 60.0.3112.50  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 26.0 r0

This was originally observed when developing Opera for Android, where we would prepare additional bitmap layers to render some transitions, and keep those up to date in the layer tree, even if the tab does not display a page, and so the web contents view is invisible.

I'm sure there is a way to better structure our code to avoid sending additional bitmaps to UIResourceManager, or at least to send fewer of those, but I have a simple patch here that seems to have little performance impact, given how short the queue is, typically, that makes it simply impossible to misuse the UIResourceManager in this way.

Request queue is always handed in bulk in post commit phase, associated with a tree, and then processed in its entirety when the tree gets activated. So any CREATE+DELETE pairs are just redunant work that is easily avoided, just like sending extra DELETE requests is being guarded against.