META: extend the "generic" theme used by Chromium Win DRT to the other DRT ports

• Component: Tools / Tests
• Status: RESOLVED WONTFIX

[Dirk Pranke]

Currently the Chromium Win DRT port has a generic theme that it uses to draw controls (checkboxes, scroll bars, etc.) to overcome differences in how the native controls are rendered across XP, Vista, and Win 7. We should extend this to Mac and Linux so that we can share more baselines between ports; ideally, we could even extend this to the other webkit ports. One possible approach would be to render the controls using routines in the existing GraphicsContext, and then all of this code would be portable across ports. There is similar code in the Apple DRT port to manage scroll bars generically, for example.

We would then use the generic theme for "most" pixel tests, and provide a dedicated set of tests that would still use the native controls (so that we wouldn't lose coverage). 

As a stretch goal, we'd even figure out how to render text generically so that we wouldn't have pixel diffs on most tests caused by slight differences in font rendering, hinting, etc, between the platforms. Alternatively, we could make ImageDiff smart enough to fuzzy-match text.

The hope here is that we get much of the win of reftests without having to actually update all umpteen thousand tests (we'd still have to do a lot of rebaselining, of course).

[Tony Chang]

Did we ever write a separate test suite to just test native theme drawing on Chromium Win?  Seems like we should do that before converting more platforms to using a mock theme.

Would it be less churn to try to get ports to standardize on the Apple Mac theme? We already have lots of pixel results with Apple Mac as the main expected result (e.g., png results that are next to tests).  It's not clear to me how many png results Chromium Mac and Apple Mac share right now.  Getting an exact number would be helpful in deciding if we should try to use the Apple Mac theme or the Chromium Win theme.

Should this bug depend on bug 77368?

[James Robinson]

I don't think the "Apple mac theme" is a good target - it's different for Leopard vs Snow Leopard vs Lion, and even on one of these platforms it's been a ton of work for us to exactly match the Apple ports since we have to duplicate how the mac theming works (for example emulating the bubble pattern offset on mac).

[Dirk Pranke]

(In reply to comment #1)
> Did we ever write a separate test suite to just test native theme drawing on Chromium Win?

No. There is currently no way to toggle the theme except via command line args, so this would've been a bit difficult. Once I land the "virtual directory" stuff I'm doing so we can merge the gpu directory back in, this will be much easier to do.

>  Seems like we should do that before converting more platforms to using a mock theme.
> 

Yup, agreed.

> Would it be less churn to try to get ports to standardize on the Apple Mac theme?

Well, the generic theme has the virtual that (a) it's easy to render the controls because they're simple and ugly, and (b) it actually distinguishes between all of the different states (different native controls may map multiple states onto the same images), so rendering apple-style controls on windows might mask bugs that today would only show up on windows, for example.

That said, you certainly have a good point.

> We already have lots of pixel results with Apple Mac as the main expected result (e.g., png results that are next to tests).  It's not clear to me how many png results Chromium Mac and Apple Mac share right now.  Getting an exact number would be helpful in deciding if we should try to use the Apple Mac theme or the Chromium Win theme.
>

Yes. There's a bunch of feasibility work I need to do first to justify this before I do any real work to merge things.
 
> Should this bug depend on bug 77368?

Yup. I hadn't rolled in any of the dependent bugs yet.

[Dirk Pranke]

resetting the owner in case someone else wants to take a look, as these bugs aren't on my immediate to-do list.

[Stephen Chenney]

Unimplemented DRT features are being marked WontFix. If they cause tests to fail, we'll see it. If not, we're switching to ContentShell and don't want to put effort into DRT.