User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060528 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060528 Minefield/3.0a1 ID:2006052804 [cairo] When styling an <input type="text"> with the opacity property, the border is not drawn. http://onfiar.com/~asztal/bugs/input-opacity.htm When the border is explicitly specified, it is then drawn (see second text box in above page). Reproducible: Always Steps to Reproduce: 1. Open the URL for this bug 2. Observe borderless text box Actual Results: The text field's border is not visible. Expected Results: The text field's border is visible.

Yes this is a cairo problem indeed.

The url is not there anymore. Could you make it available again? Preferably, could you attach the testcase to the bug?

My apologies.

Ok, I can see a border now in the attached testcase. It looks like this has been fixed somehow. I guess that this may have been fixed by bug 340452, or maybe bug 340517.

Not fixed for me, using 20061029 trunk build. I can still not see a border on this input, that has an opacity of 0.7.

Another testcase; there's something going on with native widgets and the text inside them specifically. I think we may be going through a different text rendering path in this case, but it needs to be tracked down some more.

Summary of Bug 362118: opacity is inherited so setting BODY {opacity: .99;} caused this border problem for all form controls on the page. Also, scroll bars (overflow: auto;) are affected as well.

Ok, here we go. Here's a patch for this, though it introduces some undesirable behaviour (see next attachment for screenshot). However, it does fix rendering windows native theme widgets with opacity, and also allows windows native widgets to be reproduced in PDF output (in theory, since as of now noone but stuart can actually test it :). But, I don't want to go with this patch, because I want to fix the issue in the next screenshot attachment.

So here's the problem with this patch. Win32 can draw most native theme elements with a transform, provided that only scaling is involved. What it does is just scale up the rectangle and renders as normal; it doesn't attempt to actually scale up the rendering (that is, button corners are still the exact same size in pixels at 10x scale as they are at 1x scale). This patch has it render the non-scaled-size rectangle, and then transforms the result. The problem is that widgets start to look ugly when scaled up, even though in some ways this is more "correct". Rotated widgets start to work, though they're still ugly. The real solution is to compute the scaling factors of the transformation matrix, render the widget scaled up but still axis-aligned, and then rotate that. That's coming up.

Is it really simpler to manage this state machine rather than use a callback?

Ok, updated version with all the scale factor goodness. We'll need to do some testing to get the right values for the flags per widget type, especially if it's different between classic and non-classic. As for the state machine, I think that it's simpler -- it requires less modification of calling code, and isn't all that complicated in any case. That is, the extra complexity is in the native drawing code, as opposed to requiring that all users pull out their drawing code into separate functions (and figure out how to get the right variables and all that there)...

Previous patch was missing a line, causing widgets to not be drawn in the right place in some cases.

Now nsRect and old-style-NSToCoordRound-free!

Attached wrong file

Comment on attachment 256966 [details] [diff] [review] patch for win32 native theme rendering, v1.3 can you please add some comments to your new gfxMatrix functions? please make the internal and external enums all be CAPS? add some comments on the ownership of the HDC handed back from BeginNativeDrawing? What is its lifetime? in gfxAlphaRecoveryResult instead of using alpha, r, g, b use a gfxRGBA struct? in _compute_alpha_values maybe pass in a gfxIntSize instead of int width, int height? in these spots: mWorldTransform.eM12 = 0.0; is a FLOAT a float or double? do you want 0.0f there? does it matter?

Updated with review comments.

Comment on attachment 257072 [details] [diff] [review] 256966: patch for win32 native theme rendering, v1.4 r=me with the enum changes we talked about on irc

Fix checked in.

Vladimir, you forgot to add bug number in the comment when you checked in the code to CVS. Without that it is hard in Bonsai to see relation between file changes and actual bug.

>+ /** >+ * Returns true if the matrix has any transform other >+ * than a translation or scale; this is, if there is >+ * no rotation. >+ */ >+ bool HasNonAxisAlignedTransform() const { >+ return ((xy != 0.0) || (yx != 0.0)); >+ } I think you meant "any rotation".