FWD » Core Development » User Interface

See details in #2736 starting from the note 15.

Regarding 2736 note 15, 29, 28 and others: have you posted the attempts to implement what I explained in note 22 in some branch?

No. I have these changes in some of my zip updates (we was working in one branch as you remember). But it needs to be merged with all latest updates in trunk..

Please create a 2911a branch and commit the changes related to 2736 note 15 there.

Done. branch 2911a, revno 10962.

As soon as 2909b is merged to trunk, please rebase 2911a.

Greg Shah wrote:

As soon as 2909b is merged to trunk, please rebase 2911a.

The branch 2911a is rebased. Current revision is 10966.

Vadim, what is the state of the current solution? Do you still have problems?

Constantin Asofiei wrote:

Vadim, what is the state of the current solution? Do you still have problems?

Yes. The problem is still actual. I don't know the real reason, that leads to extra background drawing. I'd tried to debug generated PaintEvent's and I'd tried to rewrite sub-menus repainting as you advised earlier. Both tries was unsuccessful.

There is this code in SwingEmulatedWindow:973:

            if (false)
            {
               g2.setColor(Color.green);
               g2.drawRect(ps.x, ps.y, ps.width, ps.height);
            }

To debug the PaintEvent's being posted add some System.out.println code in TitledWindow.processEvent with the event's source and rectangle, and check the ones related to sub-menu (actually, you can limit these only for menu-related sources).

Vadim, another issue: PaintEvent's are posted also when the popup-up menu is made visible. This includes the entire submenu hierarchy, even for menu-items and sub-menu bodies which are not displayed on screen. This is not correct - PaintEvent's need to be raised only for widgets which affect the screen (i.e. a menu is made visible), and only for that area.

Another issue: this code in SubMenuGuiImpl.prepParentLocation is called on each step of the loop in AbsractWidget.repaint():

      if (!Menu.isMenubarElement(this))
      {
         p.x += c.widthToNative(this.titleWidthWithBorders());
      }

I've rebased the branch 2911a to current trunk revision. Now revision is 10968.

Vadim, when clipping (at the driver level), the clip rectangle will be "the smallest rectangle which contains all clipping rectangles".

When drawing a widget, it will not be allowed to draw outside this clipping rectangle. In your case, I think you might be posting PaintEvent's with incorrect coordinates (i.e. the paint event rectangle does not match the rectangle where drawing will be performed).

I've fixed PaintEvent's, but SubMenu's body still doesn't drawn. Constantin, could you have a look? Current branch revision is 10975 (rebased with the latest trunk revision).

Vadim, the problem is with the fact that the items in the sub-menu's body are drawn with incorrect coordinates (they do not match the posted PaintEvents boundary). I've added some logging where drawing is done in the sub-menu. Also, I've added a GuiDriver.getOrigin() API so you can see at the time of the drawing the screen origin where the widgets are being drawn. See rev 10976.

From this log(my comments are in paranthesis):

W.processEvent [widget=MENU] NativeRectangle[top=79, left=22, bottom=124, right=118]       Rectangle[top=3.76, left=4.4, bottom=5.91, right=23.6]
TW.processEvent [widget=John] NativeRectangle[top=102, left=22, bottom=124, right=118]       Rectangle[top=4.86, left=4.4, bottom=5.91, right=23.6]
John drawing bitmap at: 22:102 with clip: NativeRectangle[top=0, left=0, bottom=22, right=96]
TW.processEvent [widget=MENU] NativeRectangle[top=79, left=22, bottom=124, right=118]       Rectangle[top=3.76, left=4.4, bottom=5.91, right=23.6]
John drawing bitmap at: 22:102 with clip: NativeRectangle[top=0, left=0, bottom=22, right=96]
TW.processEvent [widget=MENU] NativeRectangle[top=79, left=22, bottom=124, right=118]       Rectangle[top=3.76, left=4.4, bottom=5.91, right=23.6]
John drawing bitmap at: 22:102 with clip: NativeRectangle[top=0, left=0, bottom=22, right=96]
TW.processEvent [widget=John] NativeRectangle[top=102, left=22, bottom=124, right=118]       Rectangle[top=4.86, left=4.4, bottom=5.91, right=23.6]
TW.processEvent [widget=sm00] NativeRectangle[top=102, left=116, bottom=124, right=209]       Rectangle[top=4.86, left=23.2, bottom=5.91, right=41.8]
TW.processEvent [widget=sm0] NativeRectangle[top=171, left=116, bottom=193, right=209]       Rectangle[top=8.15, left=23.2, bottom=9.2, right=41.8]
TW.processEvent [widget=John] NativeRectangle[top=102, left=116, bottom=193, right=209]       Rectangle[top=4.86, left=23.2, bottom=9.21, right=41.8]
TW.processEvent [widget=MENU] NativeRectangle[top=79, left=22, bottom=124, right=118]       Rectangle[top=3.76, left=4.4, bottom=5.91, right=23.6]
John drawing bitmap at: 22:102 with clip: NativeRectangle[top=0, left=0, bottom=23, right=97]
John drawing body bitmap at: 116:125
John drawing body widgets at: 116:125 (CA: I've made a change in @SubMenuGuiImpl.draw:526@, to draw the items at the body location, not at the sub-menu location - otherwise the body rectangle and the containing widgets are drawn at different coordinates)
sm00 drawing bitmap at: 210:125 with clip: NativeRectangle[top=0, left=0, bottom=23, right=93] (CA: see how these are drawn to the right-side of the corresponding  posted PaintEvent above, which has left=116 and right = 209)
sm0 drawing bitmap at: 210:194 with clip: NativeRectangle[top=0, left=0, bottom=22, right=93] (CA: see how these are drawn to the right-side of the corresponding posted PaintEvent above, which has left=116 and right = 209)

Hope this helps.

I've fixed bodyLoc translation in SubMenuGuiImpl.draw(). It was translated twice, that was wrong and coordinates looks correct. Could you point incorrect case please?

Vadim Gindin wrote:

I've fixed bodyLoc translation in SubMenuGuiImpl.draw(). It was translated twice, that was wrong and coordinates looks correct. Could you point incorrect case please?

What does your client log show for X in the message sm00 drawing bitmap at: ? On my side I still see X coordinate in the ~200px range, and the John sub-menu body is not being drawn.

John drawing bitmap at: 25:104 with clip: NativeRectangle[top=0, left=0, bottom=23, right=100]
John drawing body bitmap at: 122:104
John drawing body widgets at: 122:104
sm00 drawing bitmap at: 219:104 with clip: NativeRectangle[top=0, left=0, bottom=23, right=94]
sm0 drawing bitmap at: 219:173 with clip: NativeRectangle[top=0, left=0, bottom=23, right=94]

It looks like sm00 drawing bitmap points to body location, not the title..

It means that Origin of sm00 is 219:104. What does AbstractGuiDriver.translatedOrigin contain? Is it a location that is set during layouting?

It means that Origin of sm00 is 219:104. What does AbstractGuiDriver.translatedOrigin contain? Is it a location that is set during layouting?

AbstractGuiDriver.translatedOrigin is a point (on the window canvas) relative to which GuiDriver.draw will perform all drawing.

This is needed to help when you have nested GuiDriver.draw calls: the outer (i.e. frame) draw call will set AbstractGuiDriver.translatedOrigin to the frame's top-left corner. Before each of the frame's widget is drawn, AbstractGuiDriver.translatedOrigin will be changed so that it points to the widget's top-left corner. Once the inner widget has finished drawing, AbstractGuiDriver.translatedOrigin will be changed back to that widget's parent top-left corner.

So, when you are executing nested GuiDriver.draw calls, before drawing a widget, the relative origin will be translated so that the widget drawing primitives will be done as if the widget was positioned in a (0,0) coordinate.

So I thought so and I'd tried to fix this changing the point used to call the body from bodyLoc to this.physicalLocation(). I got:

sm00 drawing bitmap at: 134:100 with clip: NativeRectangle[top=0, left=0, bottom=23, right=94]

Sub-menu body background looks drawn in a correct point, but it is also cut (clipped), so it is hardly depends on items coordinates only.

Vadim Gindin wrote:

So I thought so and I'd tried to fix this changing the point used to call the body from bodyLoc to this.physicalLocation(). I got:
[...]
But it didn't helped: sub-menu "John"s body hadn't shown.

The problem is the clipping region at the driver level: at the time the body is being drawn, the clip doesn't include its boundaries. I have an idea how to fix it, will let you know if it works.

Some more info for note 25; the main problem with menu and popup-menu is this: these widgets behave differently than the other P2J widgets. For normal widgets, their boundaries (for example, a frame or a container) contains all its child widgets, and the widgets can not be drawn outside this boundary.

1. if we use the "smallest rectangle which contains the entire expanded menu", it solves issues like processing events, but is problematic because, during drawing, P2J assumes this rectangle is fully used by the menu, and clears it. This is not correct, because an expanded sub-menu uses only some sub-rectangles for drawing.
2. if we make each menu-related container (sub-menu or menu) to have their boundaries set only to where they are actually being drawn, then this conflicts with the previous point. But anyway, is better for each menu/sub-menu/sub-menu body to have an equivalence between its boundary and its actually drawn area; the problems which result from this can be easier explicitly fixed i.e. when finding the widget for a certain position or when drawing.

As a result, the sub-menus "title" and its body can't be drawn in the same GuiDriver.draw call (as there will be different PaintEvent's for the body and the title). I have some WIP code related to this, where I separate the title and body drawing, but its not fully working yet.

Also, there is another issue: considering that we will have to make each sub-menu body (and the popup menu) to be drawn in their own overlay window at some point, I don't know how easily this can be accomplished using the current sub-menu implementation. I think we will need a way to separate the sub-menu "title" and its body, so the body is a different widget... but after we will use overlay windows, the problems pointed above will no longer be valid, as the sub-menu's will no longer be drawn on the same canvas.

I'm not sure yet what approach we should take... I'm inclined to go ahead and just rework the code to use overlay windows for the sub-menu body, as I think trying to improve/fix the current code will just be followed by reworking it to use the overlay windows, anyways.

This bug is not recreated for trunk revision 11073 (after menus refactoring).