717499 - "gfxWindowsPlatform.cpp(485) : error C2065: 'gfxDWriteFont' : undeclared identifier" when using "--with-windows-version=502"

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Serge Gautherie (:sgautherie)]

(Found while trying to reproduce bug 716449.)

https://tbpl.mozilla.org/?tree=Try&rev=790b578ddb7c
https://tbpl.mozilla.org/php/getParsedLog.php?id=8492165&tree=Try&full=1
WINNT 5.2 try build on 2012-01-11 15:22:30 PST for push 790b578ddb7c
https://tbpl.mozilla.org/php/getParsedLog.php?id=8491803&tree=Try&full=1
WINNT 5.2 try leak test build on 2012-01-11 15:22:30 PST for push 790b578ddb7c
{
.../gfx/thebes/gfxWindowsPlatform.cpp(485) : error C2065: 'gfxDWriteFont' : undeclared identifier
...
}

I see Neil already attached a (unreviewed) patch in bug 651858 6 months ago :-/
Code should be "fixed", or bug 629827 !

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Fix Direct2D related code compilation with Windows 2003R2/Vista SDKs

Bug 651858 patch 543379, unbitrotted.

Succeeded as https://tbpl.mozilla.org/?tree=Try&rev=ce1c31e55fe1 (12a1)


Bug 651858 comment 121:
{{
[e-mail]      2011-07-01 01:56:48 PDT

*_D2D_SURFACE are only defined if you are using the Windows 7 SDK, so they can replace the uses of XP_WIN. The only place I had to move things around was gfxWindowsPlatform, which I suspect is only compiled on Windows anyway...
}}

Bug 651858 comment 122:
{{
Bas Schouten (:bas) 2011-07-01 04:31:57 PDT

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

::: gfx/2d/Factory.cpp
@@ +40,5 @@
>  #ifdef USE_CAIRO
>  #include "DrawTargetCairo.h"
>  #endif
>  
> +#ifdef CAIRO_HAS_D2D_SURFACE

This is a bit of an issue since this isn't present in the Azure stand-alone build (and shouldn't be named that way). We should rename this #define to USE_DIRECT2D or something and then define that before including this file in gfxPlatform inside #ifdef CAIRO_HAS_D2D_SURFACE.
}}

I would be willing to fix that, though I would need more details about what is wanted precisely.

Comment 2

[Bas Schouten (:bas.schouten)]

(In reply to Serge Gautherie (:sgautherie) from comment #1)
> Created attachment 590649 [details] [diff] [review]
> (Av1) Fix Direct2D related code compilation with Windows 2003R2/Vista SDKs
> 
> Bug 651858 patch 543379, unbitrotted.
> 
> Succeeded as https://tbpl.mozilla.org/?tree=Try&rev=ce1c31e55fe1 (12a1)
> 
> 
> Bug 651858 comment 121:
> {{
> [e-mail]      2011-07-01 01:56:48 PDT
> 
> *_D2D_SURFACE are only defined if you are using the Windows 7 SDK, so they
> can replace the uses of XP_WIN. The only place I had to move things around
> was gfxWindowsPlatform, which I suspect is only compiled on Windows anyway...
> }}
> 
> Bug 651858 comment 122:
> {{
> Bas Schouten (:bas) 2011-07-01 04:31:57 PDT
> 
> Review of attachment 543379 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/2d/Factory.cpp
> @@ +40,5 @@
> >  #ifdef USE_CAIRO
> >  #include "DrawTargetCairo.h"
> >  #endif
> >  
> > +#ifdef CAIRO_HAS_D2D_SURFACE
> 
> This is a bit of an issue since this isn't present in the Azure stand-alone
> build (and shouldn't be named that way). We should rename this #define to
> USE_DIRECT2D or something and then define that before including this file in
> gfxPlatform inside #ifdef CAIRO_HAS_D2D_SURFACE.
> }}
> 
> I would be willing to fix that, though I would need more details about what
> is wanted precisely.

Basically we should make the Azure portion of the tree build with USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D to the Azure stand-alone build.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to Bas Schouten (:bas) from comment #2)
> Basically we should make the Azure portion of the tree build with
> USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D
> to the Azure stand-alone build.

Hum, I am willing to further maintain the patch (as need be), but I know little about Azure (especially what that "portion" is precisely).
Should what you are looking for be done (as) in a blocking bug?

Also, (how) could this bug be fixed for version 10 (especially LTS) and 11?

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Serge Gautherie (:sgautherie) from comment #3)
> (In reply to Bas Schouten (:bas) from comment #2)
> > Basically we should make the Azure portion of the tree build with
> > USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D
> > to the Azure stand-alone build.
> 
> Hum, I am willing to further maintain the patch (as need be), but I know
> little about Azure (especially what that "portion" is precisely).
> Should what you are looking for be done (as) in a blocking bug?
> 
> Also, (how) could this bug be fixed for version 10 (especially LTS) and 11?

I'd be ok with it landing there. Although, personally I'd -much- rather see old SDKs be deprecated since it causes less inconsistencies between builds and build environments. i.e. D2D is only a small example but a windows build without Direct2D simply isn't very realistic, our release builds have it and a significant portion of our Windows 7 users are using it.

Comment 5

[Rain [:rain1] (inactive)]

Why does this depend on bug 699385? That bug makes this one pointless instead.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to Siddharth Agarwal [:sid0] from comment #5)
> Why does this depend on bug 699385? That bug makes this one pointless
> instead.

Bug 699385 obsoleted this bug on Trunk only.

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to Bas Schouten (:bas) from comment #4)
> (In reply to Serge Gautherie (:sgautherie) from comment #3)
> > (In reply to Bas Schouten (:bas) from comment #2)
> > > Basically we should make the Azure portion of the tree build with
> > > USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D
> > > to the Azure stand-alone build.
> > 
> > Hum, I am willing to further maintain the patch (as need be), but I know
> > little about Azure (especially what that "portion" is precisely).
> > Should what you are looking for be done (as) in a blocking bug?
> > 
> > Also, (how) could this bug be fixed for version 10 (especially LTS) and 11?

PS: s/LTS/ESR/.

> I'd be ok with it landing there. Although, personally I'd -much- rather see
> old SDKs be deprecated

Older SDKs are now unsupported on mozilla13.
Would you accept this patch for (12) 11 (10)? (Assuming later approvals.)

Comment 8

[Alex Keybl [:akeybl]]

No need to track for 11, although we'd consider taking a low-risk fix early in the cycle.

Comment 9

[Bas Schouten (:bas.schouten)]

Is this still relevant?

Comment 10

[Rain [:rain1] (inactive)]

No.