> The name "compression" is unfortunate here. It took me some time to > understand what the real issue is.
Agreed. (Any ideas for a better word? For me 'supersede' comes to mind, as in a newer message supersedes an older one so the older one can be dropped, but I don't think that would be very clear either.) > That said, it seems like the "clean" architectural solution here is to > create a new actor for every combination of parameters that you do not > want to "compress" messages for, and leave as function parameters > every parameter that you do want to compress messages for. That may > not scale well, but in this case I think it would just mean creating > an actor for every (sub?)frame. Have we tried that? Is the > performance cost too high? Interesting idea. My intuition tells me that this would come with a lot of overhead, as right now we have a single TabChild per browser tab (persistent across loading new pages in the tab), while scrollable frames are specific to each page (and sometimes come and go while navigating a single page). It also seems like having to coordinate the creation and destruction of these actors would add complexity, but I'm not very familiar with IPDL so I could be wrong. My immediate interest in this has diminished somewhat as my other use case for conditional compression (PBrowser::RealTouchMoveEvent) has gone away due to a change in approach for bug 976605, and I don't think the overhead of not compressing multiple UpdateFrame messages for the same frame is enough to justify doing it just for that. I'll keep my eyes open for other uses cases, though, and keep your suggestion of creating more actors in mind. Cheers, Botond _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
