FWD » Core Development » User Interface

After 2564b is merged to trunk, this task can be started.

For details, see #2513-141 (and 142), #2513-146 (and 147) and #2513-149 (through 153).

The color does seem to get picked using XOR depending on the widget's background and/or text. 2564b has XOR compositing support, which will work for the background color scenario. But for the color override based on the text color not being black, it might make sense to calculate the color directly and then temporarily just set that color. This is because to use the XOR compositing you would have to draw the selection highlight twice (first in the text color then then again after XOR compositing is turned on). That is inefficient and really doesn't make sense when we can just calculate the right color and draw once.

Correction: 2564 A

This can now be fixed using the XOR support that exists in the 1811s rev 10995 and later. Changes should go into 1811s.

XOR (192,192,192) does not suit. It seems XOR bgColor is good. I'm testing

It looks like there are to same rectangles: the first is just black and solid and the second - is dotted and colored. Am I right?

I think it is close, but not right.

The rules as I see them:

1. If no explicit BGCOLOR is set.

a) XOR the FGCOLOR and use that to draw a solid highlight rectangle.
b) Change the color to black and draw the dotted highlight over the same rectangle.

2. If BGCOLOR is explicitly set.

a) Change the color to black and draw the dotted highlight over the same rectangle.

My only question is whether in case 2 (BGCOLOR is set) if the dotted highlight is always drawn in black OR if it draws in the same color as the FGCOLOR. Your testcase doesn't show that.

It looks to me that the dotted highlight is always drawn in black, no matter what the FGCOLOR or BGCOLOR.

So the rule seems simple:

1. If no explicit BGCOLOR is set, XOR the FGCOLOR and use that to draw a solid highlight rectangle.
2. No matter what happened in step 1, draw a dotted highlight rectangle in black.

Please implement this and see if it matches.

It doesn't match. Have a look at tbx3 in previous images for example. It looks like in the case when both background and foreground colours are set - some ternary operation is needed. What do you think?

Vadim Gindin wrote:

It doesn't match. Have a look at tbx3 in previous images for example. It looks like in the case when both background and foreground colours are set - some ternary operation is needed. What do you think?

1. Please show screen capture of the P2J results from your test. I'd like to see how close we are.

2. For each of the failing cases, please post the following:

• FGCOLOR in RGB
• BGCOLOR in RGB
• "solid" portion of the highlight color in RGB

Based on this, hopefully some pattern will emerge.

Greg, I can find out FGCOLOR and BGCOLOR using PROGRESS functions GET-RED (GREEN | BLUE)-VALUE (index), where index=1..7 from my test procedure, but how would you propose to calculate solid highlight rectangle color. Do you mean to use for that the same technique, used to find component colors, i.e. using "special" program calling MSDN functions?

Do you mean to use for that the same technique, used to find component colors, i.e. using "special" program calling MSDN functions?

No.

Are the colors you are capturing in your screen-shots accurate? If so, you can use gimp (or any other image editor). Such tools have a "color picker" tool to use the mouse to select a pixel and it will report the exact RGB values.

The important thing is that the image it is working from must have the colors accurately captured. In other words, the pixels should not be interpolated or transformed in any way. The best way to ensure this is to use a Windows tool on windev01 for the screen capture. Then transfer it locally and look at the colors.

Solid highlight colors always matches to bgColor because in case when bgColor is specified we do not calculate and draw solid rectangle. Did I understand the note 8 correctly?

No, you are correct. The algorithm as described in note 8 is too simple.

...
fg - foreground color
bg - background color
H - solid part of Highlighted rectangle.

A pattern is starting to emerge but your data inputs are too regular for us to get the answer.

They are comparing the each separate color element (r, g and b) from fg and bg. If the red value from fg is the same as the red value from bg, then the result is 0. If they are different, then they will transform the existing red values in some way. They do the same thing for green (fg vs bg) and blue (fg vs bg) values.

From one of your examples:

The red values are different so the result is transformed. The green and blue values are the same and so the result is 0.

The problem here is that you have only used 128 and 0 for your colors. We can't tell how the transformation works because the data is too simple. Please use a wider set of variations (0, 31, 32, 63, 64, 95, 96, 127, 128, 159, 160, 191, 192, 223, 224, 255). Make sure that the values that are different are not always 0 and a positive number. Each of the above numbers should be checked against all the others (0 against 31, 32, 63... + 31 against 32, 63, 64, ... + 32 against 63, 64, 96... and so on).

Also, please post your data formatted as a table here in Redmine instead of hard coded into an image. Text in a table can be searched and read easily but the image requires someone to put their eyes on it.

Greg Shah wrote:

..
The problem here is that you have only used 128 and 0 for your colors. We can't tell how the transformation works because the data is too simple. Please use a wider set of variations (0, 31, 32, 63, 64, 95, 96, 127, 128, 159, 160, 191, 192, 223, 224, 255). Make sure that the values that are different are not always 0 and a positive number. Each of the above numbers should be checked against all the others (0 against 31, 32, 63... + 31 against 32, 63, 64, ... + 32 against 63, 64, 96... and so on).

1. not always 0 and a positive number - do you mean that color component (RED for example) can have a negative value?
2. Each of the above numbers should be checked against all the others (0 against 31, 32, 63... + 31 against 32, 63, 64, ... + 32 against 63, 64, 96... and so on) - do you mean, that in the formula i against j i < j always or any i and j from specified set?
3. @ There are a lot of variants: (3 * 16) ^ 2 = 2304 (any i and j) and I will need in every of them check the result manually using GIMP. Is there any other automated way to check resulting color?

Vadim Gindin wrote:

..

1. @ There are a lot of variants: (3 * 16) ^ 2 = 2304 (any i and j) and I will need in every of them check the result manually using GIMP. Is there any other automated way to check resulting color?

Sorry, there are even more variants: 16 ^ 6 = 16777216

I didn't check all numbers, but generally the code looks right.

but why did you selected exactly that colors components set: (0, 31, 32, 63, 64, 95, 96, 127, 128, 159, 160, 191, 192, 223, 224, 255)

I was trying to get a good range of bit patterns, without generating all possible bit patterns.

There is a good argument that we should add some values in the low end (1, 2, 3, 4, 15, 16), but I hope the already chosen values will do the job.

The reason for thinking about this in bit patterns is that there is likely to be some kind of bitwise operation that is applied consistently to the FB/BG colors. In browse, they XOR 192 to get the result. Here it is something different, but probably not too different.

Find out the resulting highlight colors and record the table here (it should include the FG:RGB, BG:RGB and HIGHLIGHT:RGB). Thenb analyze the bit patterns to see if it is clear what is happening. Try to find a single value that when applied with a bitwise operator like XOR, can duplicate all the results.

Here is the table of highlight rectangle colors depending on foreground and background toggle-box colors.

OK, well the algorithm is seems very simple. It is indeed XOR based. For all of the entries I tested (except for one, see below), the algorithm is this:

h:red = fg:red XOR bg:red
h:green = fg:green XOR bg:green
h:blue = fg:blue XOR bg:blue

The only exception is this entry:

(0, 31, 31)

(255, 0, 31)

(255, 0, 31)

Could the data entry on this one be wrong? It is the only one that I found which doesn't match.

Please check this one.

Also please use this algorithm to calculate the values and compare them with the results to confirm it is the same.

You're right:

(0, 31, 31)

(255, 0, 31)

(255, 0, 31)

That's incorrect data. Correct result color is (255, 31, 0). I've set your formula and checked result. It works. Thank you! I've committed this change with revno 10997.

You have visually tested the results in P2J, comparing side by side with the 4GL?

My primary concern with the use of the SET_XOR_COMPOSITE and RESET_COMPOSITE is that these are deeply coded into sensitive code in the drivers. In your case, it seems like we really don't need to do that. In the browse highlight usage, we don't know what we are overdrawing so making the windowing system do compositing is the best solution. But for toggle box, we don't care what has been drawn below the highlight, we can always calculate the right solid rectangle highlight color. In fact, we can calculate it in advance. The only time we have to change it is when the BGCOLOR or FGCOLOR change. Please change the code to:

1. Calculate and save off the highlight color, whenever the BGCOLOR or FGCOLOR change. The calculation is a simple use of the XOR bitwise operator on the RGB values.

2. Simply use the pre-calculated highlight color as the drawing color for the solid highlight rectangle. Remove the XOR compositing operations.

This approach is slightly faster at runtime. More importantly, it is less fragile since it doesn't depend on sensitive code at the driver level.

Greg Shah wrote:

You have visually tested the results in P2J, comparing side by side with the 4GL?

Not only visually, I've also picked rgb color values and compared them with the values in the table. They all match.

My primary concern with the use of the SET_XOR_COMPOSITE and RESET_COMPOSITE is that these are deeply coded into sensitive code in the drivers. In your case, it seems like we really don't need to do that. In the browse highlight usage, we don't know what we are overdrawing so making the windowing system do compositing is the best solution. But for toggle box, we don't care what has been drawn below the highlight, we can always calculate the right solid rectangle highlight color. In fact, we can calculate it in advance. The only time we have to change it is when the BGCOLOR or FGCOLOR change. Please change the code to:

1. Calculate and save off the highlight color, whenever the BGCOLOR or FGCOLOR change. The calculation is a simple use of the XOR bitwise operator on the RGB values.

2. Simply use the pre-calculated highlight color as the drawing color for the solid highlight rectangle. Remove the XOR compositing operations.

This approach is slightly faster at runtime. More importantly, it is less fragile since it doesn't depend on sensitive code at the driver level.

I'd seen that the testing window is opened with some delay. I hope it will speed it up.

Greg, I have some difficulty implementing initialization of highlightColor from afterConfigUpdate(..). I need to recall gc.colors() before highlight color calculation and there is NPE happen. I've thought may be it will be simpler not to store separate field and calculate highlight color each time in drawHighlight(..) just like that:

      int red = gc.fgColor.getRed() ^ gc.bgColor.getRed();
      int green = gc.fgColor.getGreen() ^ gc.bgColor.getGreen();
      int blue = gc.fgColor.getBlue() ^ gc.bgColor.getBlue();

      highlightColor = new ColorRgb(red, green, blue);

OK, I'm fine with that approach.

committed with revno 11002.

Code Review Task Branch 2677a Revision 11002

I'm good with the changes.

Have you tested the result and confirmed that it works like the 4GL?

Greg Shah wrote:

Code Review Task Branch 2677a Revision 11002

I'm good with the changes.

Have you tested the result and confirmed that it works like the 4GL?

Yes, I've tested it.