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.

Sign up for GitHub

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

Jump to bottom

Bitmap recycling race #3

Closed
sjudd opened this issue Jul 16, 2013 · 1 comment
Closed

Bitmap recycling race #3

sjudd opened this issue Jul 16, 2013 · 1 comment
Labels
bug
Milestone
v2.0

Comments

@sjudd
Copy link
Collaborator

sjudd commented Jul 16, 2013

Bitmaps should be able to be marked pending for a specific view. Currently an ImageLoader can request an image, obtain it from the cache, and mark it not pending all before the original requester has responded to the image. This could cause the image to be added to the bitmap pool twice.
@sjudd
Copy link
Collaborator Author

sjudd commented Aug 8, 2013

fixed a967562

@sjudd sjudd closed this as completed Aug 8, 2013
@x2hokim x2hokim mentioned this issue Oct 24, 2014
Closed
@zhfnjust zhfnjust mentioned this issue Sep 16, 2015
Closed
@rbiggers rbiggers mentioned this issue Oct 25, 2016
Closed
@petrovichtim petrovichtim mentioned this issue Nov 10, 2016
Closed
@linyongsheng linyongsheng mentioned this issue Mar 13, 2017
Closed
@b0g8 b0g8 mentioned this issue Mar 31, 2017
Closed
@wss991 wss991 mentioned this issue Sep 20, 2017
Closed
@MKevin3 MKevin3 mentioned this issue Nov 1, 2017
Closed
This was referenced Nov 20, 2017
Closed
Closed
@yanchengdeng yanchengdeng mentioned this issue Dec 5, 2017
Closed
@he4330937 he4330937 mentioned this issue Dec 27, 2017
Open
@AllenVork AllenVork mentioned this issue Jul 12, 2018
Closed
@mushtaq99 mushtaq99 mentioned this issue Sep 5, 2018
Closed
@hellowwwwp hellowwwwp mentioned this issue Dec 28, 2018
Closed
@GarikKhachaturyan GarikKhachaturyan mentioned this issue Dec 2, 2019
Closed
@arbelkf arbelkf mentioned this issue Feb 26, 2020
Closed
@perracodex perracodex mentioned this issue Mar 30, 2020
Closed
@MarsToken MarsToken mentioned this issue Apr 20, 2020
Closed
@lyqaiym lyqaiym mentioned this issue May 31, 2020
Closed
@NewUniverseEntrop NewUniverseEntrop mentioned this issue Sep 13, 2020
Closed
@shenmaoqing shenmaoqing mentioned this issue Dec 9, 2020
Closed
@shaoguanglin shaoguanglin mentioned this issue Jul 9, 2021
Open
@xwjhlhc xwjhlhc mentioned this issue Aug 26, 2021
Open
@OneOfBillions OneOfBillions mentioned this issue Jan 11, 2022
Open
@Steven-Yao Steven-Yao mentioned this issue Apr 11, 2022
Open
sjudd referenced this issue in sjudd/glide Jul 6, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
7489bc0 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
@sjudd sjudd mentioned this issue Jul 6, 2022
Closed
sjudd referenced this issue in sjudd/glide Jul 6, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
9b7cf7f 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
sjudd referenced this issue in sjudd/glide Jul 6, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
1db1e62 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
sjudd referenced this issue in sjudd/glide Jul 7, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
fd32ad0 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
@copybara-service copybara-service bot mentioned this issue Jul 14, 2022
Merged
copybara-service bot pushed a commit that referenced this issue Jul 14, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
079ee9a 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 460850418
copybara-service bot pushed a commit that referenced this issue Jul 19, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
c9f9c8f 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 460850418
copybara-service bot pushed a commit that referenced this issue Jul 19, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
6469702 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 460850418
copybara-service bot pushed a commit that referenced this issue Jul 19, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
c35ad13 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 461943092
@sjudd sjudd mentioned this issue Dec 24, 2022
Closed
@mngzb339 mngzb339 mentioned this issue Dec 21, 2023
Open
@jackeysun6032 jackeysun6032 mentioned this issue Mar 11, 2024
Open
@Fossor Fossor mentioned this issue Mar 12, 2024
Open
@Softtanck Softtanck mentioned this issue May 9, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
v2.0
Development

No branches or pull requests
1 participant
@sjudd