Fix Texture load loop on memory warnings #11
Conversation
Solves 3 cases
1. when memory_warning happens very early, the value highest sometimes is 0.
This leads to a load loop because we are trying to ratchet down or increase
memory against 0, which would stay 0, because MEMORY_DROP_RATE and MEMORY_GAIN_RATE
are being multiplied against 0. So we set highest as 50MB (Please suggest a different value).
2. We are increasing the max_texture bytes on two conditions,
a. when it is overLimit
b. when highest > max_texture_bytes (this is already been doing right now)
3. overLimit calculation had a bug in texture_manager_clear_textures() function.
manager->approx_bytes_to_load will reduce when textures are cleared, but that was
not taken into account in the overLimit calculation.
|
This fixes 1 issue of play-co/devkit#240 |
|
Awesome, thanks for the PR! I'm going to test this out on our games |
|
Hi Jimmy, Did you get a chance to test this out ? |
|
I haven't yet but it's on my short list! It looks good to me, we just have On Tue, Aug 25, 2015 at 8:08 AM, ram [email protected] wrote:
Jimmy Griffith |
|
@rampr I've tested the changes on a range of phones, and I found some issues on the low-end (Samsung Galaxy Y). I've started a new pull request so I could more easily edit and merge the code as I test: #12 Per your fix for 1), that checks out and I'm starting the value at 1 MB. |
|
@rogueSkib, 2) was what actually fixed the flickering issue for us Once max_texture_bytes was increased to a safe value more than(epoch highest), what we saw was that What I felt was a mismatch because I have logs for the above. We also tinkered the value of MEMORY_GAIN_RATE and that did stop the flickering, but felt that may not work for all apps/devices. About 3), I think it is a bug, because overLimit depends on adjusted_max_texture_bytes and that is based on bytes_to_load, but this computation should happen after each texture clear, but is only being done before iterating through all the textures. |
|
@rogueSkib, :) I'll test out the branch today. |
|
I think this might be a misunderstanding. The comments are as follows: As you noticed, |
|
In our case, when flickering was happening, there were textures on screen and hence loaded, since overLimit was reached, some were cleared and again since they had to be be shown on screen, they had to be loaded leading to flickering. In this particular case, since texture was cleared, approx_bytes_to_load would get changed and hence the overLimit calculation would be wrong. Same output from logs, textures getting freed were present on screen since it was overLimit and again getting loaded because they had to be shown on screen: |
| @@ -750,7 +756,7 @@ void texture_manager_tick(texture_manager *manager) { | |||
|
|
|||
| // zero the epoch used bins | |||
| memset(m_epoch_used, 0, sizeof(m_epoch_used)); | |||
| } else if (highest > manager->max_texture_bytes) { | |||
| } else if (highest > manager->max_texture_bytes || overLimit) { | |||
There was a problem hiding this comment.
There is an issue in this change.
Trying to get more more memory when device has less memory available will kill the app.
|
Sending my PR separately since my changes are independent of the area that @rogueSkib is talking about. |
|
Closing this, since we moved it to #12 |
Solves 3 cases
This leads to a load loop because we are trying to ratchet down or increase
memory against 0, which would stay 0, because MEMORY_DROP_RATE and MEMORY_GAIN_RATE
are being multiplied against 0. So we set highest as 50MB (Please suggest a different value).
a. when it is overLimit
b. when highest > max_texture_bytes (this is already been doing right now)
manager->approx_bytes_to_load will reduce when textures are cleared, but that was
not taken into account in the overLimit calculation.