- 08 9月, 2017 7 次提交
-
-
由 Sam Judd 提交于
Fixes #2331.
-
由 Sato Shun 提交于
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
The Key we’re given may have a different implementation for equals and hashCode than it does for updateDiskCacheKey. As a result, two different Key objects that are not equal to each other may produce the same disk cache key. To avoid simultaneous puts for the same disk cache key we need to lock on the disk cache key, not the original key object.
-
由 Alex Kalyukin 提交于
* Add prepend methods for EncoderRegistry and ResourceEncoderRegistry classes
-
由 Sam Judd 提交于
That way we will always close the stream in cleanup(). Prior to this change, when cancel was called, stream was never set to non-null and therefore never closed in cleanup. Because disconnecting the stream doesn’t seem to close the contained ResponseBody object, failing to obtain and then close the stream results in leaked objects. Progress towards #2352
-
由 Sam Judd 提交于
Progress towards #2352.
-
- 07 9月, 2017 2 次提交
-
-
由 Sam Judd 提交于
Progress towards #2347.
-
由 Roc Boronat 提交于
If not, Gradle doesn't succeed. And that doesn't help copypasting (the common way to get Glide :·) Progress toward #2347
-
- 06 9月, 2017 3 次提交
-
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 Alex Saveau 提交于
-
- 05 9月, 2017 3 次提交
- 04 9月, 2017 1 次提交
-
-
由 Róbert Papp 提交于
-
- 01 9月, 2017 3 次提交
-
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 judds 提交于
It's easier to just call a method than it is to set a component specific option and it looks like disabling hardware configs is going to be relatively common. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=167035799
-
- 30 8月, 2017 1 次提交
-
-
由 Tolriq 提交于
Ensure that restarted request use the updated model when failed/canceled as it can contains data to help the request to succeed. (#2293)
-
- 29 8月, 2017 2 次提交
-
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
Otherwise when our extension methods mutate the RequestOptions we pass them, the mutations create a new RequestOptions object that’s dropped at the end of the extension method, which causes any options applied in the extension method to be ignored. Cloning first matches the behavior of other RequestOptions methods and ensures that the RequestOptions object passed into the extension method is mutable.
-
- 26 8月, 2017 10 次提交
-
-
由 Sam Judd 提交于
-
由 judds 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166499393
-
由 judds 提交于
This allows us to apply scale transformations if we decode from a video but still use the hardware config if we decode from an image. Unfortunately it won't work for custom transformations that only scale. We'd probably have to extend the Transformation API to let transformations indicate that they only scale and I'm not sure that that's common enough to be useful. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166406311
-
由 judds 提交于
*** Reason for rollback *** b/64987553 *** Original change description *** Choose whether or not to use HARDWARE bitmaps based on transformations in Glide. Previously we were checking only against the requested and actual size of the image as a heuristic to see if we thought a transformation would be applied. That doesn't work well for certain types of transformations that don't necessarily change the size of the image but do change its shape (rounded corners, circle crop etc). Now we're explicitly checking to see if a transformation will be applied to the load and I... *** ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166268954
-
由 judds 提交于
Previously we were checking only against the requested and actual size of the image as a heuristic to see if we thought a transformation would be applied. That doesn't work well for certain types of transformations that don't necessarily change the size of the image but do change its shape (rounded corners, circle crop etc). Now we're explicitly checking to see if a transformation will be applied to the load and I've removed the heuristic. This should catch cases like CircleCrop and also allow us to use hardware bitmaps when doing scaling entirely within Downsampler. In addition, we're now not applying transformations to Bitmaps for scale only transformations that can be done with DownsampleStrategies alone. This is a change in behavior, but since the Transformations were no-ops previously, it should be low risk. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166253525
-
由 judds 提交于
If the RequestOptions object has auto clone enabled, apply() will leave the original object unmodified and return a new mutated copy. Right now RequestManage is ignoring the new mutated copy and retaining the old unmodified object which causes Glide to ignore the applied options. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166084541
-
由 judds 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165989169
-
由 judds 提交于
Previously we'd use RGB_565 in a couple of cases. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165976352
-
由 judds 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165778077
-
由 judds 提交于
*** Reason for rollback *** b/64845448 *** Original change description *** Support HARDWARE Bitmaps in Android O+ in Glide. From adb shell dumpsys meminfo com.google.android.apps.photos on a 2016 Pixel on OPM1.170816.001: Before: App Summary Pss(KB) ------ Java Heap: 20360 Native Heap: 66032 Code: 93336 Stack: 1192 Graphics: 85892 Private Other: 8956 System: 19944 TOTAL: 295712 TOTAL SWAP PSS... *** ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165772656
-
- 25 8月, 2017 2 次提交
-
-
由 Sam Judd 提交于
-
由 Jared Burrows 提交于
-
- 23 8月, 2017 1 次提交
-
-
由 Sam Judd 提交于
apply may return new object if autoClone() is enabled on a RequestOptions object that is passed into the builder via setDefaultRequestOptions.
-
- 22 8月, 2017 1 次提交
-
-
由 Sam Judd 提交于
Work toward #2193.
-
- 19 8月, 2017 4 次提交
-
-
由 Sam Judd 提交于
-
由 judds 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165717599
-
由 judds 提交于
From adb shell dumpsys meminfo com.google.android.apps.photos on a 2016 Pixel on OPM1.170816.001: Before: App Summary Pss(KB) ------ Java Heap: 20360 Native Heap: 66032 Code: 93336 Stack: 1192 Graphics: 85892 Private Other: 8956 System: 19944 TOTAL: 295712 TOTAL SWAP PSS: 82 After: App Summary Pss(KB) ------ Java Heap: 20456 Native Heap: 39756 Code: 93384 Stack: 1220 Graphics: 81460 Private Other: 9024 System: 11662 TOTAL: 256962 TOTAL SWAP PSS: 81 These numbers aren't super solid. Some extra invalidations can dump more Bitmaps into our Bitmap pool which will make it look like the steady state memory usage is increasing even though the maximum amount remains the same. That said, I see between a 33% and 50% improvement in native heap usage after this change. This was tested by flinging back and forth in the All grid in Photos. This change is limited to HARDWARE Bitmap support. We ought to also be able to reduce the bitmap pool size in O+ now that we only care about re-using Bitmaps for very small images or while generating thumbnails for the first time. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165717498
-
由 judds 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=165653043
-