Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional fast parent tiles #1102

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@cpt1gl0
Copy link
Contributor

cpt1gl0 commented Feb 19, 2019

Maybe you could reconsider my pull request: I added another parameter FAST_PARENT_TILES_RENDERING to enable the fast rendering algorithm optionally. Modifications to TileLayer itself are minimal with just a small additional if-block for fast rendering.

@devemux86 devemux86 added this to the 0.11.0 milestone Feb 20, 2019

devemux86 added a commit that referenced this pull request Feb 20, 2019

@devemux86

This comment has been minimized.

Copy link
Collaborator

devemux86 commented Feb 20, 2019

Thanks, merged as simplified implementation via 291a31c.

Also no need for extra draw methods with less precision since play with rendering quality.

Note: for contributions please try to follow the conventions you already see in the code.

@devemux86 devemux86 closed this Feb 20, 2019

@cpt1gl0

This comment has been minimized.

Copy link
Contributor Author

cpt1gl0 commented Feb 20, 2019

This will speed up rendering, but not drastically reduce the amount of required memory which comes from scaling not only a region but the entire parent tile bitmap to the desired size, as is done with the matrix transformation.

@devemux86

This comment has been minimized.

Copy link
Collaborator

devemux86 commented Feb 20, 2019

Already over-solved parent tiles rendering without some evidence for either speed or memory.
If they are so much trouble for some devices, can always disable them with available options.

@devemux86

This comment has been minimized.

Copy link
Collaborator

devemux86 commented Feb 20, 2019

We can proceed with a different draw on speed rendering mode, but not with so many rectangle objects created for each and every tile continuously.
Can use instead detailed parameters like in Desktop native method (srcLeft, srcTop, srcRight, srcBottom, dstLeft, dstTop, dstRight, dstBottom).

devemux86 added a commit that referenced this pull request Feb 20, 2019

@devemux86

This comment has been minimized.

Copy link
Collaborator

devemux86 commented Feb 20, 2019

Merged an improved implementation via 8245d0f.

@cpt1gl0

This comment has been minimized.

Copy link
Contributor Author

cpt1gl0 commented Feb 20, 2019

Merged an improved implementation via 8245d0f.

That's perfect, thank you. I also prefer your modified implementation with passing single bitmap positions instead of src/dst rectangles to the draw method. It makes clear that positions are expected to be integers.

I am looking forward to the next release including "speed parent tile rendering". Are you planning to release any time soon?

@devemux86

This comment has been minimized.

Copy link
Collaborator

devemux86 commented Feb 20, 2019

Are you planning to release any time soon?

There is not currently any fixed date.
I usually release both Mapsforge + VTM simultaneously (as they share offline map progress).

It's easy to use the snapshot releases, always keeping them in good state.
(that's why I'm strict in PR reviews 🙂 )

@cpt1gl0

This comment has been minimized.

Copy link
Contributor Author

cpt1gl0 commented Feb 20, 2019

I see, but I would like to link against a specific version of mapsforge, so there are no surprises if the snapshot is updated. I think this is not possible with the provided snapshots.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.