Status

()

defect
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: vlad, Assigned: vlad)

Tracking

({fixed1.8.1})

1.8 Branch
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Two bits of functionality that we should give to web developers on the branch:

1. toDataURL bits
   - bug 245684 (add image encoder support)
   - bug 291218 (toDataURL)
   - bug 293244 (security checks)
2. canvas speedup and API fixes
   - bug 333177
Posted patch moz18-canvas-update.patch (obsolete) — Splinter Review
1.8 version of my patch from bug 333177; the only change outside of canvas bits is an API change in nsIRenderingContext.h -- we were returing "native graphic data" as a PRUint32, when in most cases the actual data was a pointer (this function was unused in most of the RC backends, but I needed to get at the underlying native thing for canvas).  This seems like a very bad thing to do on 64-bit platforms, so I changed this to return a |void *| instead.
Assignee: nobody → vladimir
Status: NEW → ASSIGNED
Attachment #220169 - Flags: superreview?(roc)
Attachment #220169 - Flags: review?(pavlov)
Attachment #220169 - Flags: approval-branch-1.8.1?(roc)
Oh, that patch does not have image encoders moved over, though the infrastructure is in the canvas code -- once they're moved over the bits can just be uncommented out.
1.8.1, boy howdy.
Flags: blocking1.8.1?
Do we really want all the MOZ_CAIRO_GFX code? Is it worth it to get more consistent diffs between branch and trunk?
I think branch/trunk sync is virtuous here, yeah.
I'm writing the exact same code for trunk/branch right now; I don't see any value to pulling out one or the other.  Sometime after Fx2 ships, I'll pull out the MOZILLA_1_8_* stuff from the trunk, because at that point it will be much harder to get simultaneous changes in; but for now, it seems easier to do a patch if it can apply directly to branch and trunk.
Comment on attachment 220169 [details] [diff] [review]
moz18-canvas-update.patch

sr+ with toDataURLAs disabled on branch.
Attachment #220169 - Flags: superreview?(roc)
Attachment #220169 - Flags: superreview+
Attachment #220169 - Flags: approval-branch-1.8.1?(roc)
Attachment #220169 - Flags: approval-branch-1.8.1+
Comment on attachment 220169 [details] [diff] [review]
moz18-canvas-update.patch

resetting requests since it looks like we'll want to make it toDataURL(format) as per the WHATWG spec.
Attachment #220169 - Flags: superreview?
Attachment #220169 - Flags: superreview+
Attachment #220169 - Flags: approval-branch-1.8.1?
Attachment #220169 - Flags: approval-branch-1.8.1+
New patch, with updated toDataURL API.
Attachment #220169 - Attachment is obsolete: true
Attachment #220169 - Flags: superreview?
Attachment #220169 - Flags: review?(pavlov)
Attachment #220169 - Flags: approval-branch-1.8.1?
Comment on attachment 220710 [details] [diff] [review]
new patch, with updated todataURL stuff

branch-approved, let's get this mother on.
Attachment #220710 - Flags: approval-branch-1.8.1+
Checked in 
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #11)
> Checked in 
> 

It breaks the gdiplus SVG rendering.

mozilla\layout\svg\renderer\src\gdiplus\nsSVGGDIPlusCanvas.cpp(140) : error C2664: 'nsIRenderingContext::RetrieveCurrentNativeGraphicData' : cannot convert parameter 1 from 'PRUint32 *' to 'void ** '
Can you file a bug on that breakage, and mark it as blocking this one?  Thanks.  It looks like the obvious fix (following the new pattern in nsCanvasRenderingContext2D::Render) would work, but I don't have an environment to test that in.
Depends on: 337214
(In reply to comment #13)
> Can you file a bug on that breakage, and mark it as blocking this one?  Thanks.
>  It looks like the obvious fix (following the new pattern in
> nsCanvasRenderingContext2D::Render) would work, but I don't have an environment
> to test that in.
> 

bug 337214 is filed.
Flags: blocking1.8.0.4?
Doesn't affect the 1.8.0.x branch, marking bug blocking appropriately.  (But do we use GDI SVG anywhere on the 1.8 branch?  I thought that was all cairo now.)
Blocks: 337214
No longer depends on: 337214
Flags: blocking1.8.0.4?
(In reply to comment #15)
> Doesn't affect the 1.8.0.x branch, marking bug blocking appropriately.  (But do
> we use GDI SVG anywhere on the 1.8 branch?  I thought that was all cairo now.)
> 

Sorry for mis-marking this. Originally I want to mark blocking Firefox 2.0a1 but there's no option for that.
(In reply to comment #15)
> Doesn't affect the 1.8.0.x branch, marking bug blocking appropriately.  (But do
> we use GDI SVG anywhere on the 1.8 branch?  I thought that was all cairo now.)

While we didn't end up shipping it, the GDI+ backend code is still in the 1.8 branches.
And we've already shipped alpha1 some weeks ago, so...

(More in the new bug.)
*** Bug 337319 has been marked as a duplicate of this bug. ***
Flags: blocking1.8.1? → blocking1.8.1+
Whiteboard: [checkin needed]
Er, wait - I just marked this [checkin needed] but vlad's comment 11 makes me think it might be checked in already. If it is, please mark fixed1.8.1 in the keywords.
BeOS branch builds have same bustage as OS/2.  Bug 343365 created.
Keywords: fixed1.8.1
Whiteboard: [checkin needed]
You need to log in before you can comment on or make changes to this bug.