RESOLVED WONTFIX 86149
libjpeg_turbo doesn't properly set the alpha value to 0xFF on Android
https://bugs.webkit.org/show_bug.cgi?id=86149
Summary libjpeg_turbo doesn't properly set the alpha value to 0xFF on Android
Adam Barth
Reported 2012-05-10 15:10:54 PDT
libjpeg_turbo doesn't properly set the alpha value to 0xFF on Android
Attachments
Patch (1.77 KB, patch)
2012-05-10 15:11 PDT, Adam Barth
no flags
Adam Barth
Comment 1 2012-05-10 15:11:50 PDT
Adam Barth
Comment 2 2012-05-10 15:12:20 PDT
I'm not entirely sure what to do with this patch. Noel: Any thoughts?
Min Qin
Comment 3 2012-05-10 15:19:54 PDT
Hironori has a patch that fixed this in libjpeg_turbo: http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=810 But the change has't been merged into chromium yet. So I am wondering whether we should wait for that to happen or we can submit this change first and wait for that change to merge.
Adam Barth
Comment 4 2012-05-10 15:41:04 PDT
> Hironori has a patch that fixed this in libjpeg_turbo: > http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=810 > But the change has't been merged into chromium yet. Fri Mar 16 14:30:46 2012 UTC (7 weeks, 6 days ago) What's the ETA for merging that into Chromium? > So I am wondering whether we should wait for that to happen or we can submit this change first and wait for that change to merge. One possibility is to submit this change with a link to the fix so that folks will know when to remove it in the future.
Min Qin
Comment 5 2012-05-10 15:46:42 PDT
(In reply to comment #4) > > Hironori has a patch that fixed this in libjpeg_turbo: > > http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=810 > > But the change has't been merged into chromium yet. > > Fri Mar 16 14:30:46 2012 UTC (7 weeks, 6 days ago) > > What's the ETA for merging that into Chromium? Hironori san, any idea when this change will be merged into chromium? > > > So I am wondering whether we should wait for that to happen or we can submit this change first and wait for that change to merge. > > One possibility is to submit this change with a link to the fix so that folks will know when to remove it in the future. That should also work, let's see how long will that fix go into chromium first.
Hironori Bono
Comment 6 2012-05-10 17:30:41 PDT
Greetings Min, Thanks for your update. I will update our copy of libjpeg-turbo to the latest trunk next week. Regards, Hironori Bono (In reply to comment #5) > Hironori san, any idea when this change will be merged into chromium?
Adam Barth
Comment 7 2012-05-10 17:57:17 PDT
Comment on attachment 141275 [details] Patch Thanks! I'm going to leave this bug open for a bit to remind me to follow up.
noel gordon
Comment 8 2012-05-10 18:15:29 PDT
Sounds good, want hbono's fix for libjpeg-turbo in the chromium tree, http://crbug.com/106020
noel gordon
Comment 9 2012-05-14 20:23:02 PDT
Right, new libjpeg-turbo r829 is now in webkit and should obviate the need for this change. @qinmin could you build and test Android with webkit TOT libjpeg-turbo r829, and let us know here if it works without all the #if OS(ANDROID) in the current patch?
noel gordon
Comment 10 2012-05-14 20:27:16 PDT
The webkit revision to test should be http://trac.webkit.org/changeset/117020 (r117020) or above.
Min Qin
Comment 11 2012-05-14 20:33:14 PDT
Will do that tomorrow
Min Qin
Comment 12 2012-05-15 12:13:17 PDT
Yes, with libjpeg-turbo r829, the images now render correctly without this patch. I will remove the code from downstream android implementation after our next merge.
Adam Barth
Comment 13 2012-05-15 12:43:41 PDT
Thanks Min!
Note You need to log in before you can comment on or make changes to this bug.