Open Bug 996512 Opened 11 years ago Updated 2 years ago

Do not store local image source in memory

Categories

(Core :: Graphics: ImageLib, defect, P3)

All
Gonk (Firefox OS)
defect

Tracking

()

tracking-b2g backlog

People

(Reporter: kanru, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=memory p= s= u=tarako] [MemShrink:P3][demo])

Attachments

(7 files)

+++ This bug was initially created as a clone of Bug #983050 +++ If the image is a local resource (resource://, file://, jar://, blob://, etc) we know we could read it back anytime so don't need to store the image source data for decode-on-draw or discardable surface. We could mark if the resource is local when creating a request and add a method to imgIContainer to re-request image data when needed.
Whiteboard: [c=memory p= s= u=tarako] [MemShrink:P2][demo] → [c=memory p= s= u=tarako] [MemShrink][demo]
Blocks: 996516
blocking-b2g: --- → 1.3T?
We might take this if we have data to prove this helps with performance. Placing in backlog.
blocking-b2g: 1.3T? → backlog
app:// works too Not sure for blob: because it can be revoked.
app:// could be especially important because nearly all our image data comes from this scheme...
We could keep a reference of blob in cache. Is it work?
note that the discussion in [1] is definitely related. [1] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/81lxhZQgevM
Whiteboard: [c=memory p= s= u=tarako] [MemShrink][demo] → [c=memory p= s= u=tarako] [MemShrink:P3][demo]
Priority: -- → P3
Assignee: nobody → kchen
blocking-b2g: backlog → 1.3T?
triage: let's put this to backlog
blocking-b2g: 1.3T? → backlog
Attached patch Part 7. WIP Reload Image Source (deleted) — Splinter Review
blocking-b2g: backlog → ---
Assignee: kchen → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: