If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Azure] Enable changing Azure backends

RESOLVED FIXED in mozilla19

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: nrc, Assigned: nrc)

Tracking

unspecified
mozilla19
x86_64
All
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

6 years ago
Apparently this is possible, but not available. It is necessary for using Azure canvas, but being able to fallback from hardware to software canvases.

Fonts might be an issue, in particular, Skia does not support Direct Write fonts at the moment.
(Assignee)

Comment 1

5 years ago
Try run: https://tbpl.mozilla.org/?tree=Try&rev=8bf70b4996ac
(Assignee)

Comment 2

5 years ago
Created attachment 622538 [details] [diff] [review]
patch
Attachment #622538 - Flags: review?(bas.schouten)
(Assignee)

Updated

5 years ago
Blocks: 748116
Could you explain a little about why it is necessary? Why couldn't we use an Azure-Thebes wrappers gfxContext or create a surface around underlying data?
(Assignee)

Comment 4

5 years ago
The problem I'm solving is, if (for some reason) we cannot create a canvas with the desired backend, then we fallback to a different backend. This is currently done when a canvas is created, if creating an Azure canvas fails, then a Thebes canvas is created instead. We want to get rid of Thebes canvas and only use Azure. But if creating an Azure canvas with the preferred backend fails, we want to fallback to something, probably Thebes. This patch adds support for that by changing the way that the gfxPlatform provides a DrawTarget (which required some refactoring of the way in which gfxPlatforms record their backend preferences).

I'm afraid I don't see where the wrappers you suggest help. Which part of this do you think can be replaced?
(Assignee)

Comment 5

5 years ago
Bas, I think we discussed on IRC why we need CreateDrawTargetForBackend. At the time I thought it was a refactoring that could be easily eliminated, but I'm trying to do that now, and it does not seem so easy. It is only used in CreateOffscreenDrawTarget, but either the preferred or fallback draw targets could be Cairo, and we need to go down a separate path if that is so. So we would have a fair bit of undesirable code duplication if we inline CreateDrawTargetForBackend. So, I think it is necessary, or at least desirable.
(Assignee)

Comment 6

5 years ago
Created attachment 624994 [details] [diff] [review]
patch

Added a comment to GfxPlatform.h
Attachment #622538 - Attachment is obsolete: true
Attachment #622538 - Flags: review?(bas.schouten)
Attachment #624994 - Flags: review?(bas.schouten)
Comment on attachment 624994 [details] [diff] [review]
patch

Review of attachment 624994 [details] [diff] [review]:
-----------------------------------------------------------------

I'm r+'ing this but with the very explicit mention that this -cannot- be landed yet until we have a place where Cairo-Azure canvas is being tested!
Attachment #624994 - Flags: review?(bas.schouten) → review+
(Assignee)

Updated

5 years ago
Blocks: 776802
(Assignee)

Comment 8

5 years ago
Created attachment 669448 [details]
patch

rebased, carrying r=Bas
Attachment #624994 - Attachment is obsolete: true
Attachment #669448 - Flags: review+
(Assignee)

Comment 9

5 years ago
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=d2b658828771
https://hg.mozilla.org/mozilla-central/rev/c153fd060cef
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.