tiledquickplugin: only render visible tiles

[mitchcurtis]

Fixes #2769

[mitchcurtis]

Nice, thanks! All works great now.

I just noticed that I have some leftovers in src/tiledquick/qml/main.qml. Will these changes be squashed and so I should just do a fixup commit? Or should I rebase 9f2d7b0 (and I guess force push)?

[bjorn]

Yeah, that was a nice cleanup in Tiled Quick and now all orientations are supported. :-)

I wonder a bit about the impact on performance of adding a std::function call for each tile, but I did not measure it. A debug build is slow for big maps, but that was already the case. In release mode I did not notice any difference.

I just noticed that I have some leftovers in src/tiledquick/qml/main.qml. Will this changes be squashed and so I should just do a fixup commit? Or should I rebase 9f2d7b0 (and I guess force push)?

Let's squash this, so please push a cleanup commit. :-)

[mitchcurtis]

I wonder a bit about the impact on performance of adding a std::function call for each tile, but I did not measure it. A debug build is slow for big maps, but that was already the case. In release mode I did not notice any difference.

I figured it was the lesser of two evils, but that was because I was assuming that using an interface would require memory to be allocated... thinking about it a bit more now, passing a helper object thingy that was created on the stack should also work.

[bjorn]

I figured it was the lesser of two evils, but that was because I was assuming that using an interface would require memory to be allocated... thinking about it a bit more now, passing a helper object thingy that was created on the stack should also work.

The std::function wrapping a lambda likely takes pretty much the same amount of memory as the helper object would (though indeed it may be heap allocated rather than stack allocated, depending on how big it is). Also, the helper object would need a virtual member function, so it's likely to have similar overhead to the std::function. But would need to be measured to be sure. :-)

I think the only way to have really less overhead would be to use a template parameter, but it would mean moving the entire tile layer rendering code into the header as well as to remove the virtual dispatch for drawTileLayer.

[mitchcurtis]

I've noticed that maps are now shifted half a tile upwards. Do you have any idea which part of our recent changes could be causing this?

diff --git a/src/tiledquick/qml/main.qml b/src/tiledquick/qml/main.qml
index d67909ea..5ddfdff6 100644
--- a/src/tiledquick/qml/main.qml
+++ b/src/tiledquick/qml/main.qml
@@ -151,6 +151,12 @@ ApplicationWindow {
                             mapView.width / scale,
                             mapView.height / scale);
                 }
+
+                Rectangle {
+                    anchors.fill: parent
+                    color: "transparent"
+                    border.color: "darkorange"
+                }
             }
         }
     }

[bjorn]

I've noticed that maps are now shifted half a tile upwards. Do you have any idea which part of our recent changes could be causing this?

So, actually only maps using that particular tileset would appear shifted like that. And it's because the tiles are 64 pixels high and have a transparent region at the bottom. In addition, our tile rendering callback is not applying the drawing offset of the tileset. I'll fix that up now. :-)

[mitchcurtis]

Thank you Bjorn! Now I can start making some bigger maps! :D