FWD » Core Development » User Interface

• if the widget's BGCOLOR/FGCOLOR is already set by the business logic, use that. Otherwise, if its -RGB counterpart is set, use it.
• in ABL, it can receive hex values like 0xff0000 for color RED.

Support for WINDOW:BGCOLOR-RGB is not working yet - there is a problem in inheriting the GuiColorResolver from the WindowGuiImpl to WindowWorkspace.

3369a rebased from trunk 11201. new rev is 11207.

Greg, 3369a rev 11208 is ready for review.

Eric: Persistence.java needs a history entry.

Eric, I couldn't reproduce the iframe issue you've reported with 3369a. If you have any other details I can use to duplicate it, please let me know.

Constantin Asofiei wrote:

Eric: Persistence.java needs a history entry.

Done.

Constantin Asofiei wrote:

Eric, I couldn't reproduce the iframe issue you've reported with 3369a. If you have any other details I can use to duplicate it, please let me know.

I'm not seeing this anymore with the latest revision. Tried both FF and Chrome.

Code Review Task Branch 3369a Revision 11209

I'm fine with the changes. I checked in some minor changes to make it easier to see these are extension attributes.

Please put this through regression testing.

3355a was merged into 3369a rev. 11213.

Committed revision 11218 removed waste code due to the web client profiling done by Eric.

Revision 11219 contains a fix for unresponsive message boxes. Somebody please review.

Code Review Task Branch 3369a Revision 11219

I'm good with the change.

3369a 11220 improves performance of coordinate values rounding.

3369a rev 11225/11226 fixes class name collisions for converted external program names. Full conversion is required. If the configured OS in p2j.cfg.xml is a case-insensitive, then names will be checked case-insensitive. Otherwise, collisions are avoided on a case-sensitive basis.

Greg, please review.

Code Review Task Branch 3369a Revision 11226

I think the code is correct from a logical standpoint.

If we had time, I would prefer for checkClassName to be called disambiguateClassName and for the logic that follows the call to checkClassName to be moved into disambiguateClassName. Instead of editing the rule-set's state, I would prefer the logic and data access to be hidden inside disambiguateClassName. Moving the state inside there would make the result cleaner.

However, with our time constraints in mind, I'm OK with the code as is.

Greg Shah wrote:

Code Review Task Branch 3369a Revision 11226

I fixed a regression in 11227, I was not considering the package, only the class name... result was logically correct, but too broad.

Does it need to rebase 3369a?

Yes, but I want to wait for Hynek's update first.

Hynek Cihlar wrote:

3369a 11220 improves performance of coordinate values rounding.

There are still these cases which use BigDecimal:

Coordinate.chuiRound(double) (2 matches)
Coordinate.guiRound(double) (2 matches)
CoordinatesConversion.toChar(int, int, RoundingMode) (5 matches)
CoordinatesConversion.toPixels(double, int) (2 matches)

1. avoid logging overhead in the EmulatedWindowState and SwingEmulatedWindow
2. avoid unnecessary repaints

Eric, please check the impact.

Constantin Asofiei wrote:

3369a rev 11231 contains some performance fixes:

1. avoid unnecessary repaints

There is a regression here in the large GUI app... repaints are avoided too aggressively, some cases do not repaint (i.e. tabs or button 'bold' in the main menu window). Although it might be an issue more of 'repaints are not triggered when they should be', which is just uncovered because of my changes.

Can I rebase 3369a? I know the 3375a change is not yet available, but I think it is best to go ahead and pick up the trunk changes so that we can get a conversion run in tonight.

I will rebase in 15 minutes if there are no objections.

I'm rebasing now.

Branch 3369a rebased from trunk rev 11204. The latest revision is 11236.

This will require a full reconversion of the large GUI application.

Constantin Asofiei wrote:

Constantin Asofiei wrote:

3369a rev 11231 contains some performance fixes:

1. avoid unnecessary repaints

There is a regression here in the large GUI app... repaints are avoided too aggressively, some cases do not repaint (i.e. tabs or button 'bold' in the main menu window). Although it might be an issue more of 'repaints are not triggered when they should be', which is just uncovered because of my changes.

Fixed in 3369a 11237.

Constantin Asofiei wrote:

Constantin Asofiei wrote:

Constantin Asofiei wrote:

3369a rev 11231 contains some performance fixes:

1. avoid unnecessary repaints

There is a regression here in the large GUI app... repaints are avoided too aggressively, some cases do not repaint (i.e. tabs or button 'bold' in the main menu window). Although it might be an issue more of 'repaints are not triggered when they should be', which is just uncovered because of my changes.

Fixed in 3369a 11237.

I haven't yet tested with the larger app, as it's reconverting currently. I did test with the Hotel GUI demo and I can confirm that the calendar control is much faster (2x or better). Nice work!

1. bring up the Hotel GUI app and go to the "Rooms" item
2. click "Add Rooms..." to bring up the dialog with the tree control
3. expand the "Double" branch in the tree control
4. expand the "Single" branch

Notice how the "Single" branch expands in height and overpaints/corrupts the top of the "Double" branch. I tested with trunk revision 11204 and it does not do this (the "Double" branch part of the image moves down). I guess that whatever optimization you may be doing with clip regions must be adjusted to repaint more of the buffer when the clip region being repainted changes in size/position. Hopefully, this edge case can be accommodated without regressing the performance gains you've achieved.

Incidentally, I'm seeing the iframe scroll bars again the first time I enter the Hotel GUI embedded mode with 3369a/11237 (and not with trunk 11204), though that seems unrelated to the repaint changes.

I did some testing with the large app in Swing mode and in virtual desktop mode (converted with 3369a rev. 11237). It is definitely faster (particularly noticeable in the main menu).

There are some issues with repainting in the ADM screens: e.g., an old tab remains "selected" after selecting a new one; sometimes buttons from old screens are still visible when displaying a new one. I'm not sure if the button issue is a new regression or was already there -- I had seen some issues like this with previous versions. The ADM tab issue is new.

Eric Faulhaber wrote:

There are some issues with repainting in the ADM screens: e.g., an old tab remains "selected" after selecting a new one; sometimes buttons from old screens are still visible when displaying a new one. I'm not sure if the button issue is a new regression or was already there -- I had seen some issues like this with previous versions. The ADM tab issue is new.

Yes, I'm working on these now.

An observation: I've noticed that the embedded mode drawing seems much more "crisp" than virtual desktop mode or the Swing client.

By that, I mean, with Swing and virtual desktop mode, I tend to see a screen with multiple widgets painting progressively: the frame is drawn and you can see it visibly being populated with controls from top to bottom and left to right. A browse, then a column or row of buttons, etc. It doesn't all happen at once.

In embedded mode, the entire screen seems to be block transferred at once from an off-screen buffer; you don't see the widgets being drawn individually. It is much more pleasing to the eye. Also, I don't notice the same issue with buttons from one screen being painted incorrectly in another, as I described above for virtual desktop and Swing modes.

Eric Faulhaber wrote:

Also, I don't notice the same issue with buttons from one screen being painted incorrectly in another, as I described above for virtual desktop and Swing modes.

Actually, I did manage to hit this in embedded mode just now, but not as frequently as with the other modes. Haven't figured out a reliable way to recreate it yet.

Eric Faulhaber wrote:

There are some issues with repainting in the ADM screens: e.g., an old tab remains "selected" after selecting a new one;

This one is fixed in 3369a 11238.

sometimes buttons from old screens are still visible when displaying a new one. I'm not sure if the button issue is a new regression or was already there -- I had seen some issues like this with previous versions.

Can you send me an email with this one? Some recreate/screen-shots?

I am using 3369a to work on #3385 and it seems that the Login screen (Swing client) doesn't accept keys input.

Don't mind it works now, after external jconsole has been accessed to the client process. It is not a bug probably.

Another regression fixed, 3369a rev 11247 is in testing.

Constantin Asofiei wrote:

Another regression fixed, 3369a rev 11247 is in testing.

Rev 11247 passed main part of testing; ctrl-c is in progress.

There is a new #3377 rev 11248 change, which looks risky. Do we continue with 3369a as the cumulative branch?

No, I want to get the 3369a into the trunk.

Ovidiu: Would you please move the changes 11248 into a separate branch?

No problem. I am un-committing 3369a/ right now.

3369b replaces all UI coordinate roundings implemented by BigDecimal with more primitive constructs, like java.math, hopefully saving some CPU cycles. The changes passed GUI and ChUI regression tests. Please review.

Code Review Task Branch 3369b Revision 11211

It is not clear why we need both Coordinate.guiRound() and Coordinate.scale() when they essentially have the same algorithm. There is a missing test for infinity and NaN, but otherwise it is the same code.

Other than this, I'm fine with the changes.

This branch needs a rebase. Do you still believe it is safe to merge to trunk? Another option is to merge it into 3435a.

Also, please reply back to the questions in #3369-40.

I wasn't in the issue watch list and I missed the last two notes.

I resolved the point in note 40, rebased 3369b and merged it to 3435a as revision 11233. 3369b is archived.

Hynek Cihlar wrote:

I wasn't in the issue watch list and I missed the last two notes.

I resolved the point in note 40, rebased 3369b and merged it to 3435a as revision 11233. 3369b is archived.

I'm fine with the changes.

The fix for #3369-18 was put into 3435a. Branch 3435a was merged to trunk as revision 11217.