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
No longer depends on: 333177
14 years ago
Depends on: 333177
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.
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.
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.
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.
Depends on: 336331
New patch, with updated toDataURL API.
Attachment #220710 - Flags: superreview+
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+
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.
(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.
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.)
(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. ***
Depends on: 338407
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.
Whiteboard: [checkin needed]
You need to log in before you can comment on or make changes to this bug.