Closed
Bug 790673
Opened 12 years ago
Closed 11 years ago
Figure out how native drawing should work with Azure
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla25
People
(Reporter: jrmuizel, Assigned: jrmuizel)
References
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
bas.schouten
:
review+
|
Details | Diff | Splinter Review |
We probably want an API like the gfxNativeDrawing. Where you start and end drawing. We probably want the draw target to make sure this clip is set it can probably take a transform parameter to set as well.
We'll need this for CoreGraphics, cairo_t and perhaps GDI.
Updated•12 years ago
|
Assignee: nobody → ajones
Assignee | ||
Comment 1•12 years ago
|
||
How about something like:
cairo_t DrawTarget::StartNativeDrawing()
DrawTarget::FinishNativeDrawing()
I think for now it may make sense to only support a single native drawer.
Comment 2•12 years ago
|
||
Assignee | ||
Comment 3•12 years ago
|
||
(In reply to Anthony Jones (:kentuckyfriedtakahe) from comment #2)
> Created attachment 672153 [details] [diff] [review]
> Borrowed context
Having this be a base class with virtual functions is basically useless because to use the Context the caller needs to know what type it is. I can't think of a scenario where a user will need to deal with arbitrary BorrowedContexts. I expect that it might be better to have the users call a method on the concrete DrawTarget type (DrawTargetCairo) and get back a concrete BorrowedContextCairo.
I also don't think the object should be reference counted. I can't think of any reason that the ownership of BorrowedContextCairo should be shared. i.e I don't think that we should support long lived BorrowedContexts. The DrawTarget should not be used while we're lending the context, which means that the BorrowedContext should probably only be allowed to be used on the stack.
Comment 4•12 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> Having this be a base class with virtual functions is basically useless
> because to use the Context the caller needs to know what type it is. I can't
> think of a scenario where a user will need to deal with arbitrary
> BorrowedContexts. I expect that it might be better to have the users call a
> method on the concrete DrawTarget type (DrawTargetCairo) and get back a
> concrete BorrowedContextCairo.
BorrowedContext<DrawTargetCairo> perhaps?
> I also don't think the object should be reference counted. I can't think of
> any reason that the ownership of BorrowedContextCairo should be shared. i.e
> I don't think that we should support long lived BorrowedContexts. The
> DrawTarget should not be used while we're lending the context, which means
> that the BorrowedContext should probably only be allowed to be used on the
> stack.
I agree. Stack only would be ideal.
Assignee | ||
Comment 5•12 years ago
|
||
Comment 6•12 years ago
|
||
Comment on attachment 758214 [details] [diff] [review]
BorrowedCGContext
Review of attachment 758214 [details] [diff] [review]:
-----------------------------------------------------------------
That should work :-)
Assignee | ||
Updated•12 years ago
|
Assignee: ajones → jmuizelaar
Assignee | ||
Comment 7•12 years ago
|
||
Attachment #758214 -
Attachment is obsolete: true
Attachment #759462 -
Flags: review?
Assignee | ||
Updated•12 years ago
|
Attachment #759462 -
Flags: review? → review?(bas)
Updated•12 years ago
|
Attachment #759462 -
Flags: review?(bas) → review+
Assignee | ||
Comment 8•11 years ago
|
||
Comment 9•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in
before you can comment on or make changes to this bug.
Description
•