Support more flexibility in qcms output format

RESOLVED FIXED in mozilla18

Status

()

Core
GFX: Color Management
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jrmuizel, Assigned: jrmuizel)

Tracking

(Blocks: 1 bug)

unspecified
mozilla18
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
This will help support Chrome and should also let us output directly to a cairo compatible format.
(Assignee)

Comment 1

5 years ago
Created attachment 661445 [details] [diff] [review]
Support more flexibility in qcms output format
Attachment #661445 - Flags: review?(bgirard)
Yay for merging :)

Did a quick read-through and it looks good. I'll do a full re-through Monday and make sure it's not missing any sites.
I think this is O.K. in practice but supporting this feature will limit us when chaining transformation because we can only do swizzling at the end. We can get away with this patch now because we precache the entire transformation regardless of its size. I was hoping before enabling v4 support we would do some performance testing and only precache when transforming images large enough (~33k pixels for 33^3 precache) however if we take this change doing so will be harder.

I think we have 3 options here:
1) Make the swizzling work with a variable. This will likely make the generated code worse but by how much?
2) Make a swizzle+non swizzle copy as needed. This will yield code bloat.
3) Always precache chain transforms. This will give bad performance when decoding many small images with unique profiles.
(Assignee)

Comment 4

5 years ago
(In reply to Benoit Girard (:BenWa) from comment #3)
> I think this is O.K. in practice but supporting this feature will limit us
> when chaining transformation because we can only do swizzling at the end. We
> can get away with this patch now because we precache the entire
> transformation regardless of its size. I was hoping before enabling v4
> support we would do some performance testing and only precache when
> transforming images large enough (~33k pixels for 33^3 precache) however if
> we take this change doing so will be harder.
> 
> I think we have 3 options here:
> 1) Make the swizzling work with a variable. This will likely make the
> generated code worse but by how much?
> 2) Make a swizzle+non swizzle copy as needed. This will yield code bloat.
> 3) Always precache chain transforms. This will give bad performance when
> decoding many small images with unique profiles.

I don't think we'll need to duplicate much of the code because afaik all of the routines do full src->dest transformations and not the individual pieces that are needed for chaining.
Right. I'm fine landing this patch now and dealing with the problem once, if, we ever want to change this code.

Updated

5 years ago
Attachment #661445 - Flags: review?(bgirard) → review+
(Assignee)

Updated

5 years ago
Blocks: 584652
(Assignee)

Comment 6

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd16a5d51273
Assignee: nobody → jmuizelaar
https://hg.mozilla.org/mozilla-central/rev/bd16a5d51273
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Updated

5 years ago
Depends on: 798758

Comment 8

5 years ago
(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)
> This will help support Chrome and should also let us output directly to a cairo compatible format.

Jeff did you mean Google Chrome?
You need to log in before you can comment on or make changes to this bug.