Hi Steve,
I don't think that the current algo is completely wrong. I think it is better to start with the complete data and divide it into smaller parts as that algo keeps the information of the location of elements, while your approach is likely to compare many bboxes which are (too) far away from each other.
Yes, implementation speed might require some more complexity - but it seems that it should produce a division split where all of them are no bigger than required without further splitting the elements.
Maybe, but I don't think that this would be optimal, as we may get too many sub divs and thus a much larger img file. I don't know how the device determines the relevant sub divs, but even a good algo will suffer if we produce 10000 instead of 250 sub divs.
If that is the case, and it still makes no difference in speed, then maybe we are pretty much as good as we are going to get.
I thought about writing an algo to test this, but that seems to be even more complicated. I'd try to simulate the rendering for each element in a grid, and compare the number of rendered elements (caused by overlaps) which are not visible in the grid element. This could be done for each level, and maybe one has to take into account that a device has to render a rectangle which heads to north-west or west. Gerd