-
Notifications
You must be signed in to change notification settings - Fork 212
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
Fix map display #425
Fix map display #425
Conversation
It would be nice if the logging messages were made more self-explanatory:
The user doesn't know what a swatch is. Maybe the message should be something like "Preparing to render a 400x400 map as 1 swatch" |
@rotu Makes sense, I added it using your suggestion. |
This PR is working great for me. Why's it taking so long to get merged in? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe CI is failing because we need a rebase to get e37643f |
The test fails for the current implementation as the map is too big. This should not be the case though.
The API of loadRawData takes an Ogre ushort which is an unsigned short which is guaranteed to be 16 bit. Hence we should static_cast to a uint16_t instead of a uint8_t. This will result in the swatch being creatable for much larger textures
- Explain rationale behind maximum swatch split - Improve const correctness - Log better error if the map cannot be displayed - Move method updateDrawnUnder() to place where it can actually be executed
e8834d8
to
f610629
Compare
@jacobperron I think you're right. I did the rebase and now it builds and tests cleanly on my machine. I also took the liberty to retrigger CI (EDIT: new try by replacing It might be worth considering this also for a backport to dashing. |
* Improve test for large maps The test fails for the current implementation as the map is too big. This should not be the case though. * Fix swatches to store more data The API of loadRawData takes an Ogre ushort which is an unsigned short which is guaranteed to be 16 bit. Hence we should static_cast to a uint16_t instead of a uint8_t. This will result in the swatch being creatable for much larger textures * Minor refactoring of map display - Explain rationale behind maximum swatch split - Improve const correctness - Log better error if the map cannot be displayed - Move method updateDrawnUnder() to place where it can actually be executed * Improve log messages
* Improve test for large maps The test fails for the current implementation as the map is too big. This should not be the case though. * Fix swatches to store more data The API of loadRawData takes an Ogre ushort which is an unsigned short which is guaranteed to be 16 bit. Hence we should static_cast to a uint16_t instead of a uint8_t. This will result in the swatch being creatable for much larger textures * Minor refactoring of map display - Explain rationale behind maximum swatch split - Improve const correctness - Log better error if the map cannot be displayed - Move method updateDrawnUnder() to place where it can actually be executed * Improve log messages
Fixes #424
Fixes #401
This was a bug introduced during migration:
The Ogre API allows textures of size at most
unsigned short
number of bytes height or width. However, the current implementation only creates textures of at most 8 bit height or width. Since the number of swatches was capped at 8 in the original RViz and this limit has been kept, this means that maps of moderate size (e.g. 800 * 800 pixels) crashed.This PR fixes this bug by creating textures of 16 bit size.
I also improved the status quo: